PDA

View Full Version : problems with mips tserver



amiller
06-25-2003, 03:35 AM
I've got a prom-hacked Series 2 SA running 4.0, and I found a mips version of tserver (tserver_mfs_mips6), but when I run it,
I get:

bash-2.02# ./tserver_mfs_mips6
failed to open []
Not a TiVo super block! (magic=0x00000000)

Have other people run tserver successfully on series 2 SA?
I don't have my cross compiling suite set up yet, because there were some problems in the make that I haven't debugged yet.
Can anyone point me to a precompiled mips tserver that works for them?

Thanks a lot.

BlueKloud
08-27-2003, 12:35 PM
I too am having this problem. I am on a Monte'd S2 SA, on 4.0

David Bought
08-27-2003, 02:29 PM
Originally posted by amiller
I've got a prom-hacked Series 2 SA running 4.0, and I found a mips version of tserver (tserver_mfs_mips6), but when I run it,
I get:

bash-2.02# ./tserver_mfs_mips6
failed to open []
Not a TiVo super block! (magic=0x00000000)

Have other people run tserver successfully on series 2 SA?
I don't have my cross compiling suite set up yet, because there were some problems in the make that I haven't debugged yet.
Can anyone point me to a precompiled mips tserver that works for them?

Thanks a lot.

So what file(s) is it trying to open?

For God's sake at least post strace output. We can't diagnose your problems unless you start giving us some useful information.

BlueKloud
08-27-2003, 07:35 PM
strace output


execve("./tserver", ["./tserver"], [/* 32 vars */]) = 0
uname({sys="Linux", node="(none)", ...}) = 0
brk(0) = 0x1001c700
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\10\0\0\0\1\0\1\26"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=1606890, ...}) = 0
old_mmap(NULL, 1675968, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x2ab04000
mprotect(0x2ac52000, 307904, PROT_NONE) = 0
old_mmap(0x2ac91000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x14d000) = 0x2ac91000
old_mmap(0x2ac99000, 17088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ac99000
close(3) = 0
getpid() = 361
open("/dev/hda10", O_RDONLY|O_DIRECT) = 3
syscall(0x102c, 0x3, 0, 0, 0x7fff7298) = 0
read(3, 0x100008e4, 512) = -1 EINVAL (Invalid argument)
close(3) = 0
brk(0) = 0x1001c700
brk(0x1001c720) = 0x1001c720
brk(0x1001d000) = 0x1001d000
open("", O_RDWR|O_DIRECT) = -1 ENOENT (No such file or directory)
write(2, "failed to open []\n", 18) = 18
write(2, "Not a TiVo super block! (magic=0"..., 43) = 43
exit(1)


Output of Export:



declare -x DEBUG_BOARD="false"
declare -x EMERGENCY_REINSTALL="0"
declare -x HDA_ID="WD-WMACD1035068"
declare -x HDB_ID="Unknown"
declare -x HOME="/"
declare -x HOSTNAME="(none)"
declare -x HOSTTYPE="i686"
declare -x IGNOREEOF="1000"
declare -x IrdSerialNumber="CHANGED"
declare -x MACHTYPE="i686-pc-linux-gnu"
declare -x MFS_DEVICE="/dev/hda10"
declare -x MODEM_DEVICE="/dev/cua1"
declare -x MODEM_REV=""
declare -x MODEM_TYPE="P2109-V90"
declare -x OSTYPE="linux-gnu"
declare -x PATH="/bin:/sbin:/tvbin"
declare -x PROMVERSION="


Taken from tserver source code mfs.c


static void load_super(void)
{
int fd;

if (io_vserver() != -1) {
mfs_read_partial(&super, 0, sizeof(super));
} else {
if (!mfs_dev) mfs_dev = getenv("MFS_DEVICE");
if (!mfs_dev) {
mfs_dev = "/dev/hda10";
fprintf(stderr, "Assuming MFS_DEVICE=%s\n", mfs_dev);
}

fd = open(mfs_dev, O_RDONLY|O_LARGEFILE);
read_sectors(fd, &super, 0, 1);
close(fd);
}

load_devs(super.devlist);

if (*(u16 *)&super == 0x1492 || *(u16 *)&super == 0x9214) {
if (*(u16 *)&super == 0x1492) io_need_bswap(1);
partition_parse();
mfs_read_partial(&super, 0, sizeof(super));
}

switch (super.magic) {
case 0xabbafeed: /* normal tivo access */
break;
case 0xbaabedfe:
io_need_bswap(1);
break;
case 0xedfebaab:
little_endian = 1;
break;
case 0xfeedabba:
little_endian = 1;
io_need_bswap(1);
break;
default:
fprintf(stderr,"Not a TiVo super block! (magic=0x%08x)\n",
super.magic);
exit(1);
}


Now from what I can tell (from the source), it is attempting to get MFS_DEVICE from the Environment. Acording to my output of "export", that variable is set to "/dev/hda10". According to the strace it is trying to open "", which means it is not getting the environment variable. I am no programmer, and would appreciate any help!

BlueKloud
08-27-2003, 07:49 PM
I could also tell from the source that if the Enviro MFS_DEVICE was set to "" then tserver will sub in "/dev/hda10" automatically. So I set MFS_DEVICE="" and reran strace on tserver



execve("./tserver", ["./tserver"], [/* 32 vars */]) = 0
uname({sys="Linux", node="(none)", ...}) = 0
brk(0) = 0x1001c700
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\10\0\0\0\1\0\1\26"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=1606890, ...}) = 0
old_mmap(NULL, 1675968, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x2ab04000
mprotect(0x2ac52000, 307904, PROT_NONE) = 0
old_mmap(0x2ac91000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x14d000) = 0x2ac91000
old_mmap(0x2ac99000, 17088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ac99000
close(3) = 0
getpid() = 371
open("", O_RDONLY|O_DIRECT) = -1 ENOENT (No such file or directory)
syscall(0x102c, 0xffffffff, 0, 0, 0x7fff72a8) = -1 EBADF (Bad file descriptor)
write(2, "llseek failed\n", 14) = 14
exit(1) = ?

Again, I see that open("", O_RDONLY|O_DIRECT) , so that isn't working...

So i removed MFS_DEVICE from the Environment and reran strace;



execve("./tserver", ["./tserver"], [/* 31 vars */]) = 0
uname({sys="Linux", node="(none)", ...}) = 0
brk(0) = 0x1001c700
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\10\0\0\0\1\0\1\26"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=1606890, ...}) = 0
old_mmap(NULL, 1675968, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x2ab04000
mprotect(0x2ac52000, 307904, PROT_NONE) = 0
old_mmap(0x2ac91000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x14d000) = 0x2ac91000
old_mmap(0x2ac99000, 17088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ac99000
close(3) = 0
getpid() = 376
write(2, "Assuming MFS_DEVICE=/dev/hda10\n", 31) = 31
open("/dev/hda10", O_RDONLY|O_DIRECT) = 3
syscall(0x102c, 0x3, 0, 0, 0x7fff72a8) = 0
read(3, 0x100008e4, 512) = -1 EINVAL (Invalid argument)
close(3) = 0
brk(0) = 0x1001c700
brk(0x1001c720) = 0x1001c720
brk(0x1001d000) = 0x1001d000
open("", O_RDWR|O_DIRECT) = -1 ENOENT (No such file or directory)
write(2, "failed to open []\n", 18) = 18
write(2, "Not a TiVo super block! (magic=0"..., 43) = 43
exit(1)


Still no go, even though the proggie subbed in "/dev/hda10".
Any thoughts?

David Bought
08-27-2003, 08:13 PM
Originally posted by BlueKloud
Still no go, even though the proggie subbed in "/dev/hda10".
Any thoughts?

Yes, it looks like a bad build.

Somebody out there has a borked cross compiler setup that produces binaries which "loop" on themselves like this. (Note the second open call which is inconsistent with the source code, and the questionable EINVAL returned by read.) There was another recent thread in which an mfs_ftp support program had the same problem, and a helpful user fixed the problem by posting a recompiled binary.

Note to whoever keeps distributing these shit binaries: STOP NOW, YOU ARE WASTING EVERYBODY'S TIME. Fix your setup or use -static.

BlueKloud
08-27-2003, 08:35 PM
In that case, if someone would be kind enough to point me to a "known tested good" MIPS tserver binary, I would appreciate it.

cobelli
08-29-2003, 06:58 PM
Ya, I included one in my tivo hacking instructions pack. Can't remember where I originally snagged it from, though. It works fine for me, and I haven't heard any complaints from others. I've attached it here for ease. Enjoy!

BTW, can you trace back to who initially compliled this bad build? Bought is right on this issue. Clearly the person doesn't know his setup is hosed, and his mis-works have spawned some frustrating threads. If you know where you initially got it from, just give the guy a heads up about his x-compiler.

- Cobelli

EDIT: removed broken attachment

MuscleNerd
09-01-2003, 05:15 AM
Originally posted by cobelli
Ya, I included one in my tivo hacking instructions pack. Can't remember where I originally snagged it from, though. It works fine for me, and I haven't heard any complaints from others. I've attached it here for ease. Enjoy!
You may want to reconsider distributing those. They're broken for a subset of TiVo users.

The binaries in that package were not compiled with LARGEFILE support. The reason the open("/dev/hda10") call isn't adequate is that its using O_DIRECT instead of O_LARGEFILE. This is due to a misconfigured *.h file in the source package.

If I try to use your mfs_stream, I get:

open("/dev/hda10", O_RDONLY|O_DIRECT) = 3
syscall(0x102c, 0x3, 0, 0, 0x7fff75c8) = 0
read(3, 0x10000824, 512) = -1 EINVAL (Invalid argument)


Whereas the correct mfs_stream will do:

sched_setscheduler(0x159, 0x1, 0x7fff7668) = 0
open("/dev/hda10", O_RDONLY|O_LARGEFILE) = 3
syscall(0x102c, 0x3, 0, 0, 0x7ffeade8) = 0
read(3, "\0\0\0\0\253\272\376\355\374,\310\201\0\0\0\20\0\0\0\1"..., 512) = 512


The reason not everyone sees the errors is that it depends on how big the drive is.

I also noticed that your version doesn't make a call to sched_setscheduler(), so it will compete with other processes with normal priority, not reduced.

abierce
09-01-2003, 11:09 AM
Is there a fix yet available? I am in the same boat with a 120Gig Drive.

cobelli
09-01-2003, 11:36 AM
Sorry about that guys, didn't realize they were bum. When we get fixed versions, I will include those instead.
- Cobelli

DjPK
09-01-2003, 06:05 PM
anyone care to post info on how to compile them correctly and where to get the source? I would have no problem compliling and testing them and then giving the compiled version back.
I have a sas2 and have the same superblock issue. I have used both of the bin that you posted.

mfs_ftp works to download tmf files but if i extract them tmf to ty using winrar the tystudio can't open the tv files. Also the mfs_ftp fails everytime i try to download anything other then the full tmf.

Would really like some info on ways to work around this. I have read alot of the posts on this topic but none really seem to be based on the mips versions.

As always i am willing te help just let me know.

Paul

cobelli
09-04-2003, 07:11 PM
Stange, because the files I originally posted work fine on my hdvr2 and I have a 160gb drive. Anyway, please test out these. They were posted by snoopy and appear to be the most recent compile. Please let me know if you encounter the same problem, otherwise I will include these in my guide.

Thanks
- Cobelli

DjPK
09-04-2003, 07:32 PM
same issue. below is the output i get when i run tserver also is the output of my export. This is using your new binaries.

tserver
failed to open []
Not a TiVo super block! (magic=0x00000000)

export
declare -x DEBUG_BOARD="false"
declare -x EMERGENCY_REINSTALL="0"
declare -x HDA_ID="WD-WMA8C2041477"
declare -x HDB_ID="Unknown"
declare -x HOME="/"
declare -x HOSTNAME="(none)"
declare -x HOSTTYPE="i686"
declare -x IGNOREEOF="1000"
declare -x IrdSerialNumber="53263A63"
declare -x MACHTYPE="i686-pc-linux-gnu"
declare -x MFS_DEVICE="/dev/hda10"
declare -x MODEM_DEVICE="/dev/cua1"
declare -x MODEM_REV=""
declare -x MODEM_TYPE="P2109-V90"
declare -x OSTYPE="linux-gnu"
declare -x PATH="/bin/hack/bin:/sbin:/bin:/tivobin:/tvbin:."
declare -x PROMVERSION="

TiVo p0 version 1.6"
declare -x PWD="/bin/hack/tserver"
declare -x SHELL="/bin/sh"
declare -x SHLVL="2"
declare -x SerialNumber="140000080263A63"
declare -x SwSystem="4.0-01-2"
declare -x TERM="linux"
declare -x TIVO_REMOTE="TIVO"
declare -x TIVO_ROOT=""
declare -x TIVO_SVR_ADDR="192.168.50.1:80"
declare -x TV_STD="NTSC"
declare -x dsscon="true"
declare -x root="/dev/hda7"
declare -x upgradesoftware="false"
declare -x varpartition="/dev/hda9"

cobelli
09-05-2003, 12:23 AM
well, if you can handle the cross compile, the source can be found in snoopy's thread entitled "where are the files." If you get it working, that would be a great help. Thanks
Cobelli

TiVOBell
09-05-2003, 09:07 AM
I have the same problem.

Unfortunately I don't think I will be able to personally do a new compile of the binaries due to lack of *NIX skills and dedicated Linux HW.

I will offer to be a tester for any kind soul who is willing to properly compile the binaries though. :)

thanks

David Bought
09-05-2003, 10:50 AM
Originally posted by TiVOBell
I have the same problem.

Unfortunately I don't think I will be able to personally do a new compile of the binaries due to lack of *NIX skills

You misspelled "due to laziness." Guess what, nobody here was born with *NIX skills either.

Call a spade a spade.


and dedicated Linux HW.

What's wrong, can't your system dualboot or run VMware? Why can't you run Cygwin? Are you using an 80286?

TiVOBell
09-05-2003, 11:57 AM
I somehow knew I would incurr your wrath with my post....

I was unaware that CYGWIN could help me with this. Thanks for the pointer. I will post the results if I have any success.

As for my reasons for not doing this myself, it is pretty damned presumptuous for you to assume that laziness is my driver. I have a long-hours job with a 2 hour commute each way. I have three young children who I would like to spend time with. I time-split between at least five hobbies -Amateur Radio, Golf, TiVo, Computers, and PDAs. Lazy I am not.

I made a simple offer to test software. I did not imply I am entitled to anything, nor did I imply that I expected someone else to do the work. I offered to test if someone decided to compile the code.

You, on the other hand, behave like some self-appointed Nazi, trolling the forums and spanking those who don't fit your definition of a model hacker. It sure must be nice to have nothing better to do than that.

You really ought to back off. Your obnoxious tone is polluting this place. * (http://www.amishrakefight.org/gfy/)

David Bought
09-05-2003, 01:39 PM
Originally posted by TiVOBell
I somehow knew I would incurr your wrath with my post....

You knew this because you know that I do not tolerate those who make it a point to brag in public about how lazy they are.

If you want to silently lurk and wait for somebody to post the fix, more power to you. But if you want to bitch and moan and clutter the forums with useless "offers to test the fixed version", we have no need for your posts here. FYI, I built a working binary, and I have not needed anybody's help "testing" it. It worked the first time and every time thereafter.

<snipped tripe about why your other time commitments make it OK to threadcrap here>


Your obnoxious tone is polluting this place.

Not a single one of my criticisms has applied to the people who actually contribute to this hobby: guys and gals like mrblack51, RC3105, embeem, and MuscleNerd. They can and do ignore most of my "corrective" posts because the posts are not directed at people like them.

Now, to get this thread back on track: please compile tserver with a correctly configured MIPS cross compiler setup and post the new binary here. You may wish to include descriptions of each step you took so as to help new members learn to set up their own TiVo build environment. Thanks in advance for your contributions.

tivomaster
09-05-2003, 02:43 PM
Originally posted by David Bought
<Snip>
FYI, I built a working binary, and I have not needed anybody's help "testing" it. It worked the first time and every time thereafter.
<Snip>
Now, to get this thread back on track: please compile tserver with a correctly configured MIPS cross compiler setup and post the new binary here. You may wish to include descriptions of each step you took so as to help new members learn to set up their own TiVo build environment. Thanks in advance for your contributions.

David, If you already have a "working binary" why don't you simply post it instead of telling people to compile it and post it themselves? That would really put this thread to bed where it belongs......

MuscleNerd
09-05-2003, 02:50 PM
As my strace output showed, I also have working binaries. Personally, I'd *really* love to see more people get their cross-compilers working. If Christmas rolls around and people still haven't done that, then I'd post my binaries :) But seriously...more people need to get involved with this, or it just loses its appeal all around.

tivomaster
09-05-2003, 03:07 PM
Originally posted by MuscleNerd
As my strace output showed, I also have working binaries. Personally, I'd *really* love to see more people get their cross-compilers working. If Christmas rolls around and people still haven't done that, then I'd post my binaries :) But seriously...more people need to get involved with this, or it just loses its appeal all around.

Such is true... I am firing up a vmware linux installation as we speak. Shoulda did it earlier.. Any hints (other than search) as to the tricks and traps to getting a cross-compiler installation up and running?

cobelli
09-05-2003, 03:24 PM
Seems to be alot of info over at alt.org about setting up a mips x-compiler properly. I too will be setting up a compiler eventually.

Cobelli

MuscleNerd
09-05-2003, 04:03 PM
Originally posted by tivomaster
Any hints (other than search) as to the tricks and traps to getting a cross-compiler installation up and running?
The "mips cross compiler?" thread on the alt forum is a good read.

DjPK
09-05-2003, 05:22 PM
Seems counter productive to have everyone compile everything themselves. Especially when you are dealing with large base of people who don't even know what a complier is. Just because someone wants to extract video does not mean they want to devote 12 hours a day to learning linux.

I have a linux machine right next to me so for me its not an issue but to suggest that everyone on this board learn *nix (cygwin) to compile every biniary so that each of us can do the exact same steps as everyone else over and over again is a little pointless.

Why not have those that know what they are doing compile and those that don't do some testing.

Seems alot better then having to deal with 1000 bad binaries floating around are 200 threads on what a makefile is.

There is alot of hostitly on this forum towards anyone that asks a question in plain english. Would it be more fitting and more fun if we sent all of the forum messages in hex then we could make sure to weed out those that aren't "smart" enough or those that are to "lazy" to spend there free time learning computer science.

I will set up cross complier and I will try to help but to suggest to someone who doesn't even know how or never has compiled anything that they should start learning and making crap binaries is ludicrous.

I am not starting a flame war and this is the last message i will post to touch on heat that comes from alot of really simple questions. If it gets you so mad that someone doesn't know how to do something why do you bother to even remark?

PK

MuscleNerd
09-05-2003, 05:33 PM
Originally posted by DjPK
Seems counter productive to have everyone compile everything themselves.
...
Why not have those that know what they are doing compile and those that don't do some testing.
As far as I can tell, there is *nobody* compiling anything themselves -- with the exception of DB. All I'm saying is that I'd be more enthusiastic about contributing things if more people jumped onboard.

DjPK
09-05-2003, 05:39 PM
You know what we need. A simple cross-compile How to with cygwin (free). Maybe thats what i will do this weekend....


PK

tmesis
09-05-2003, 05:51 PM
Has anybody ever built MIPS cross-compiler with cygwin?

I already spent two weeks trying to do that, unsuccessfully. I started with the standard build_mips_x_compiler.sh script and tweaked it whenever it failed. No matter what, linking against the compiled glibc fails with lots of "duplicate symbol xxx" and "undefined symbol xxx" errors.

I am a developer in my day job (Java), so I hope I know what I am doing. I don't have much experience with gcc/glibc though.

Here is what I tried:
-- binutils versions 2.11, 2.13, 2.14.90.0.6 (H.J.Lu's patches), 2.15;
-- gcc versions 3.0, 3.2-7.1 (H.J.Lu's patches), 3.3;
-- glibc versions 2.2.3 (with and without H.J.Lu's patches), 2.2.5

I am out of ideas what else to try.

BTW, I do have a cross-compiler running on Linux, works fine. I want to have it on my main computer to avoid ftp-ing stuff around.

Xanthio
09-05-2003, 06:06 PM
Originally posted by MuscleNerd
As far as I can tell, there is *nobody* compiling anything themselves -- with the exception of DB. All I'm saying is that I'd be more enthusiastic about contributing things if more people jumped onboard.

The primary reason I haven't tried setting up to build these utils is that I've yet to see any detailed explanation as to what leads anyone to believe this might be the problem. There's a variety of things I want to build my own binaries for that I'd never bother asking for binaries of because it just doesn't make sense ... but in this case binaries of the extraction tools are available on these very forums and apparently (by virtue of the forums themselves) established as good builds. I have yet to see anyone asserting why this might be the problem.

These problems seem oddly consistant between a number of recent SAS2 posters who just started getting their extraction on courtesy of MuscleNerd's information. Most have gotten their binaries from the extraction forum here. Just by virtue of logic this seems to suggest that the build isn't the issue, the problems are too consistant across numerous builds established as working. The mfs_ftp and tytools problems seem to be linked to the same "Not a TiVo super block! (magic=0x00000000)" error.

Could anyone comment as to what, then, the error might mean in more detail than "bad build" which sounds a lot like "I don't know". If something about the error lends heavily towards that conclusion, perhaps sharing what that is so that people who don't understand where the conclusion stems from can wouldn't be outlandish.

-X

TiVOBell
09-05-2003, 06:24 PM
MuscleNerd alluded to the problem Here (http://www.dealdatabase.com/forum/showthread.php?s=&threadid=25437) about halfway down. He seems pretty confident in his answer.

MuscleNerd
09-05-2003, 06:37 PM
Originally posted by Xanthio
Could anyone comment as to what, then, the error might mean in more detail than "bad build" which sounds a lot like "I don't know". If something about the error lends heavily towards that conclusion, perhaps sharing what that is so that people who don't understand where the conclusion stems from can wouldn't be outlandish.
I believe the crux of the problem is that "util.c" file in the vplay distribution is a little out of date (mfs_stream is meant to be built within the vplay distro). There are a few places in that file that say:

#ifdef TIVO

Those lines should be changed to:

#if defined(TIVO) && defined(__powerpc__)

David Bought
09-05-2003, 07:46 PM
Originally posted by DjPK
Seems counter productive to have everyone compile everything themselves. Especially when you are dealing with large base of people who don't even know what a complier is.

People who don't even know what a compiler is have NOTHING to contribute here. They need to shut up and move their posts out of the development forum, into the newbie area, where they will not get in the way of progress.


Just because someone wants to extract video does not mean they want to devote 12 hours a day to learning linux.

You left out the part where you explain why that's my problem.


I have a linux machine right next to me so for me its not an issue but to suggest that everyone on this board learn *nix (cygwin) to compile every biniary so that each of us can do the exact same steps as everyone else over and over again is a little pointless.

How are they going to hack a Linux based device if they can't use a command line? Hint: there's no pretty hacker GUI like in the movies.


I will set up cross complier and I will try to help but to suggest to someone who doesn't even know how or never has compiled anything that they should start learning and making crap binaries is ludicrous.

Where do you get your sense of entitlement? WE OWE YOU NOTHING. GET OVER IT.

Lurking and contributing are your two options here at Dealdatabase. Loudly defending your right to sit on your &#97;ss is not covered. If you don't want to bother learning anything, that's your prerogative - but shut the hell up about it already.

Xanthio
09-05-2003, 09:36 PM
Originally posted by MuscleNerd
I believe the crux of the problem is that "util.c" file in the vplay distribution is a little out of date (mfs_stream is meant to be built within the vplay distro). There are a few places in that file that say:

#ifdef TIVO

Those lines should be changed to:

#if defined(TIVO) && defined(__powerpc__)

Actual information! Thanks for the what to look for... if I had a crosscompile setup I'd start tinkering with it and see what I wind up with. I'm going to look into cygwin I guess, though since I'm unfamiliar with it I'm not sure about anything there. Unfortunately I just lost a hard drive to old age and can't afford to buy a new one to set up a system to build on ... though if I become desperate enough I might have to go digging through the old closet and see if I can't find a working 1-gigger or something. I've got a 700 meg drive in there that's held together with duct tape ... think I'll stay away from that one.

If anyone having these problems manages to get this working at least keep the rest of us informed as to your results. I'd hate to waste time doing all this for something that's been tried and failed already.

-X

MuscleNerd
09-06-2003, 12:00 AM
Partly because I'm curious whether my guess was right, here's my "fixed" version of one of the two binaries in question: mfs_stream. Someone who had problems before should try this version out, and if it fails, please provide your strace output. I'm predicting this will work, and if so, then the above #ifdef thing should also fix your tserver (which I don't actually use, so I don't even know where the latest source for that is).

Also...it would be better if people for whom cobelli's mfs_stream worked tried this version out too.

MuscleNerd
09-06-2003, 12:05 AM
To whomever tries that out..please simplify things by just trying the executable on its own, outside of mfs_ftp. Choose a fake fsid to make it even simpler:

./mfs_stream -s 999999 > /tmp/foo
ERROR: Didn't find fsid=999999!


If you get that error instead of "Not a TiVo super block!", then the overall binary should be good to go for you.

Xanthio
09-06-2003, 02:31 AM
Originally posted by MuscleNerd
To whomever tries that out..please simplify things by just trying the executable on its own, outside of mfs_ftp. Choose a fake fsid to make it even simpler:

./mfs_stream -s 999999 > /tmp/foo
ERROR: Didn't find fsid=999999!


If you get that error instead of "Not a TiVo super block!", then the overall binary should be good to go for you.

bash-2.02# ./mfs_stream -s 999999 > /tmp/foo
failed to open []
Not a TiVo super block! (magic=0x00000000)

No luck. I'm ever curious about that "failed to open []"...

Okay, now you're stoking my curiousity. I think I'm going to be reading source code over breakfast instead of the paper. Might still have a 2 gig drive that's been dropped a few times that still works (hopefully). I can set up to cross compile on that (hopefully). Figuring this out is likely a couple notches over my head but that's never stopped me before.

Thank you MuscleNerd for your efforts on this subject, like I said before I'm not allergic to learning but this is quite possibly over the heads of people without your level of mastery.

-X

tivomaster
09-06-2003, 08:47 AM
Originally posted by MuscleNerd
Also...it would be better if people for whom cobelli's mfs_stream worked tried this version out too.

I created a temp directory on my /var/hack and put both your compile and the cobelli version on there named them msf_streamm (yours) and mfs_streamc (cobelli). I executed them and they both report exactly the same thing...

bash-2.02# ./mfs_streamc -s 999999 > /tmp/foo
ERROR: Didn't find fsid=999999!
bash-2.02# ./mfs_streamm -s 999999 > /tmp/foo
ERROR: Didn't find fsid=999999!

No problem with tivo superblock, so it looks like the problem that Xanthio has could possibly be not code related.

I have one question. The compile you did is a lot larger than the cobelli (compiler unknown) code. Over double the size. What could be the reason for this?

bash-2.02# ls -l
total 149
-rwxrwxrwx 1 0 0 44380 Sep 6 12:33 mfs_streamc
-rwxrwxrwx 1 0 0 104736 Sep 6 12:33 mfs_streamm

They both report the same result from doing a file command....

mfs_streamc: ELF 32-bit MSB MIPS-I executable, MIPS, version 1 (SYSV), for GNU/Linux 2.2.15, dynamically linked (uses shared libs), stripped

mfs_streamm: ELF 32-bit MSB MIPS-I executable, MIPS, version 1 (SYSV), for GNU/Linux 2.2.15, dynamically linked (uses shared libs), stripped

TiVOBell
09-06-2003, 10:19 AM
Same here.

bash-2.02# ./mfs_stream -s 999999 > /tmp/foo
ERROR: Didn't find fsid=999999!

And, drumroll, I can now extract TY files with MFS_FTP for the first time ever. :D

Thanks for helping out here MusclenNerd! :cool:

Xanthio
09-06-2003, 01:58 PM
Originally posted by tivomaster
No problem with tivo superblock, so it looks like the problem that Xanthio has could possibly be not code related.

Wow the problem Xanthio has seems to be sleep related.

ERROR: Didn't find fsid=999999!

This is what I get for reading posts when the dog wakes me up in the middle of the night.

edit - MuscleNerd, was the only change the #ifdef issue you mentioned previously? I find tserver is giving me the same error still so I'm guessing it's the same problem (looking through the sources it would seem the whole thing needs to be rebuilt, just making sure that's an accurate assumption).

-X

MuscleNerd
09-07-2003, 01:57 PM
Originally posted by tivomaster
I have one question. The compile you did is a lot larger than the cobelli (compiler unknown) code. Over double the size. What could be the reason for this?
Looks like the build I made includes a bunch of the schema attribute definitions. I just dropped jdiner's version of mfs_stream.c into the vplay directory and built it....not sure how to exclude the schema stuff.

Also, the version I supplied adjusts its priority down in the scheduler, so as not to compete for resources as much.

MuscleNerd
09-07-2003, 01:58 PM
Originally posted by Xanthio
MuscleNerd, was the only change the #ifdef issue you mentioned previously?
Yep.

MuscleNerd
09-07-2003, 05:22 PM
Here is my take on the tserver_mfs program, and its companion script "NowShowing.tcl".

I *seriously* trimmed away all the extra stuff in NowShowing.tcl that wasn't being used by tserver_mfs. I also added compatibility for 4.0 TiVos (in case anyone is running without encryption enabled).

Also, I added a simple option to tserver_mfs to allow you to specify the path for whatever version of NowShowing.tcl you want to run. It defaults to "./NowShowing.tcl", but you can set it using the "-s <path>" command line option.

I included the binaries for both ppc and mips, and tried them out with the version of NowShowing.tcl that I included. Everything seems to work.

jdiner
09-07-2003, 07:47 PM
Originally posted by MuscleNerd
Here is my take on the tserver_mfs program, and its companion script "NowShowing.tcl".

I *seriously* trimmed away all the extra stuff in NowShowing.tcl that wasn't being used by tserver_mfs. I also added compatibility for 4.0 TiVos (in case anyone is running without encryption enabled).

Also, I added a simple option to tserver_mfs to allow you to specify the path for whatever version of NowShowing.tcl you want to run. It defaults to "./NowShowing.tcl", but you can set it using the "-s <path>" command line option.

I included the binaries for both ppc and mips, and tried them out with the version of NowShowing.tcl that I included. Everything seems to work.
Humm. The -s option is in my latest version...

Oh... It never got released. Well. Alrighty then. I will look at the changes and possibly merge them into the main stream release.

Thanks for the help. I am sure the S2 peoples appriciate it.

--jdiner

TiVOBell
09-08-2003, 11:50 AM
Trust me, the S2 people really appreciate it.

Thanks again, M.N. :)

jdiner
09-12-2003, 04:15 PM
Ok. From my own source trees I have vesion 7 for the tserver_mfs program. But I have no way to test it right now. I don't have access to a hacked HDVr2 anymore.

You can either wait while I try to get access to one or someone can volunteer to test this thing for me knowing full well it might crash the machine. Not permanently just mean some rebooting...

Your call.

--jdiner

ronnythunder
09-12-2003, 08:27 PM
josh, i can test it for you. i have a dsr7000 running monte with my own kernel, so i can do whatever's needed.

let me know,

ronny

jdiner
09-12-2003, 11:06 PM
Early testing looked good. So you will find the server bin in the new TyTool7r10 release zips.

If you have any troubles please let me know.

--jdiner

defaults
09-21-2003, 12:13 AM
bash-2.02# ./tserver_mfs
Switching to low priority...
Assuming MFS_DEVICE=/dev/hda10
Waiting for an incoming connection!
SERVER: We got a message! buf = 'SHOWING'
Tmk Assertion Failure:
FsStartFunction, line 141 ()
Tmk Fatal Error: Thread tivosh <193> died due to signal -2
ccfde8 cd031c bd3c50 bc7bf8 bbf014 c1fa98 bf6d78 c41a00 c4522c bbd270 400778 d75
3d0

after clicking refresh on the tytool on pc i get this and my tivo auto reboots .. any suggestions?

jdiner
09-21-2003, 10:14 PM
Under any of the mips based tivos certain env variables are required. They are clearly listed in the "how to hack" docs by Mr. Black51 and others.

YOU MUST HAVE THESE! If you do not you will see problems like the one you list. Check them out, add them and try again.

--jdiner

ronnythunder
02-07-2004, 04:52 PM
Here is my take on the tserver_mfs program, and its companion script "NowShowing.tcl".sorry to bump an old thread, but i was wondering if you might be willing to release your entire source tarball for this version of tserver? the "delete" function in tserver has changed since your version was built, and i was hoping to build an updated version.

thanks!

ronny

MuscleNerd
02-07-2004, 06:16 PM
sorry to bump an old thread, but i was wondering if you might be willing to release your entire source tarball for this version of tserver?
That zip file I provided had the source in it too.

ronnythunder
02-07-2004, 07:31 PM
That zip file I provided had the source in it too.it has the tserver_mfs.c source, but not the rest of the mfs utils source. when i try to build with my mfs utils and your tserver_mfs.c, i still get the "not a tivo superblock" errors. i suspect that some changes were made in the mfs utils, because the binary you provided works fine.

sorry to be a pest...

ronny

ronnythunder
02-07-2004, 08:34 PM
update: this may be of some interest to folks who are building tools with a cross compiler. i discovered that the file i/o flag "O_LARGEFILE" was defined as "0x8000" under the ppc (series 1) architecture, but it's "0x2000" on mips (series 2). the mfs.h file (part of tridge's vserver and the basis of pretty much all mfs-related code) has this:
#ifndef O_LARGEFILE
#define O_LARGEFILE 0x8000
#endifi changed it to this:
#ifndef O_LARGEFILE
#ifdef __powerpc__
#define O_LARGEFILE 0x8000
#else
#define O_LARGEFILE 0x2000
#endif
#endifafter rebuilding, the program works. this may have been the basis of many of those "not a tivo superblock" things.

ronny

MuscleNerd
02-07-2004, 11:47 PM
after rebuilding, the program works. this may have been the basis of many of those "not a tivo superblock" things.
You got it. That is indeed the root cause of the "not a tivo superblock" errors. Now where were you last September when there was all that confusion over this problem :)

BTW, I wasn't holding this info back (and I think some of my earlier posts in this thread pointed this issue out)...I was about to post the diffs you were looking for but you beat me to it :).

ronnythunder
02-07-2004, 11:56 PM
You got it. That is indeed the root cause of the "not a tivo superblock" errors. Now where were you last September when there was all that confusion over this problem :)it seems that some of the mips binaries will work on a 3.x box (e.g. hdvr2), but not on 4.0, so i'd been working ok until i started working on this sa series 2 box.

oh well, at least it's all working! thanks for taking a look.

ronny

biggulp
02-22-2004, 11:37 PM
it seems that some of the mips binaries will work on a 3.x box (e.g. hdvr2), but not on 4.0, so i'd been working ok until i started working on this sa series 2 box.

oh well, at least it's all working! thanks for taking a look.

ronny

Is this fixed now? I am running an hdvr2 with 4.0b and I get the error. Could you please post the bin?

LazLong
02-24-2004, 07:15 AM
Is this fixed now? I am running an hdvr2 with 4.0b and I get the error. Could you please post the bin?


This fixed it for me:

tserver:
http://www.dealdatabase.com/forum/showpost.php?p=115317

mfs_steam:
http://www.dealdatabase.com/forum/showpost.php?p=115129

From read/searching I found that apparently there was a change in the file i/o flag "O_LARGEFILE" when moving from ppc to mips.

Iago
02-28-2004, 01:24 PM
This fixed it for me:

Thanks LazLong. This fixed it for me too.

Are we losing anything by not using the latest tserver_mfs7_mips file?

LazLong
02-28-2004, 09:41 PM
Thanks LazLong. This fixed it for me too.

Are we losing anything by not using the latest tserver_mfs7_mips file?

I'm a n00b, and I have no idea....I was more interested in getting it working at all. Sorry....

ertyu
03-09-2004, 06:42 PM
My dates are all screwed up in Tytool, anyone else see this?

monstermurph
04-28-2004, 03:51 PM
been searching for an answer all day have been running into dead end after dead end it seems. I have HDVR2 with version 4.0 which I can telnet and ftp into.

When I try running tserver via telnet on the S2 with extracted files from tserver_mnerd (was gettting "Not a Tivo super block! magic=0x00000000" with tserver_mfs7_mips, thus searched for upgraded binary for s2 version 4). Ftp'd extracted files to tivo and I try running the tserver app using the following command from telnet prompt

tserver_mfs -s /var/hack/tserver/NowShowing.tcl

I get the following

Switching to low priority...
crc mismatch len=17408 0x5c3d83d6 0x532cd95a
crc mismatch len=17408 0x7faa3e2f 0xfcaf9d95
Bad binding in the server: Address already in use

I get this error with no PC client running, rebooted Tivo multiple times and still get the same error. It is my guess that there is no process running already for this program, put I do not have ps loaded on my tivo, still looking for file to install it as well.

Anyone have any suggestions?

Waruwaru
04-28-2004, 04:03 PM
It's weird, I get those when I try to start tserver using TyTools. But I never see those CRC errors when I use Telnet (maybe it's piped to a log?). Or maybe it's because I start tserver without using the -s NowShowing.tcl... The CRC errors seem to change from time to time as well. I usually just ignore them, and TyTools still work great for me.

malfunct
04-28-2004, 04:19 PM
It's weird, I get those when I try to start tserver using TyTools. But I never see those CRC errors when I use Telnet (maybe it's piped to a log?). Or maybe it's because I start tserver without using the -s NowShowing.tcl... The CRC errors seem to change from time to time as well. I usually just ignore them, and TyTools still work great for me.

The errors are completely safe to ignore, they are a result of a consistency check on MFS. In series one the value they checked never changed, in series 2 it changes.

monstermurph
04-28-2004, 05:35 PM
what about the "bad timing in the server: Address already in use" ? Does this mean that it is already loaded? How do I check for processes running if the command ps returns "ps: command not found", assume I have to upload ps as well?

When I run tytool9r14 on my 2000 box, put in the correct Tivo address and select "Server", then select "start tserver" with the correct "Set execute string" I get (below is string I use)

/var/hack/tserver_mfs -s /var/hack/NowShowing.tcl

with tserver_mfs and NowShowing.tcl in /var/hack directory.


TyTool tserver error Starting the server failed. Never received the telnet prompt. Please check you Settings and try again."

Seems I am missing something, that is why I tried to manually load tserver via telnet myself to see if produced any errors.

sebgood
04-29-2004, 05:19 PM
Has anyone had the problem where Tivo can no longer change channels after the mnerd tserver is started? I installed it on a friend's Tivo last night and that's what happened. If we reboot the Tivo, it works. As soon as we start tserver, no more channel changing.

Mnerd's tserver has worked great for me (9r14 doesn't work). But I use the IR interface to the cable box instead of serial.

Any ideas?

dna
05-02-2004, 02:16 PM
You have to specify the expected string (which the telnet prompt) from your tivo.
Ex "tivo:/var/tmp$"


what about the "bad timing in the server: Address already in use" ? Does this mean that it is already loaded? How do I check for processes running if the command ps returns "ps: command not found", assume I have to upload ps as well?

When I run tytool9r14 on my 2000 box, put in the correct Tivo address and select "Server", then select "start tserver" with the correct "Set execute string" I get (below is string I use)

/var/hack/tserver_mfs -s /var/hack/NowShowing.tcl

with tserver_mfs and NowShowing.tcl in /var/hack directory.


TyTool tserver error Starting the server failed. Never received the telnet prompt. Please check you Settings and try again."

Seems I am missing something, that is why I tried to manually load tserver via telnet myself to see if produced any errors.