Is this a dead thread? Can anyone please give me some ideas as to what I might be doing wrong with these fsid numbers.
I'm trying to extract shows from a s1 dtivo. I have sucessfully extracted a 1kb file using mfs export. But I read that if I got only a 1kb file I used the wrong fsid number wich was the main number.
I tried ./mfs_dumpobj <fsid> and I got a bunch of stuff. I tring to determine what fsid numbers I should be using. I read that I should look at the "RecordingPart." but I'm still confussed.
I thought I got it going because when I extracted a file, it would have a percentage countdown and then there wouldn't be a *.ty file in my destination directory.
Can someone please explain to me what fsid numbers I should be looking at?
Is this a dead thread? Can anyone please give me some ideas as to what I might be doing wrong with these fsid numbers.
I'm trying to pull streams off a drive that is stuck in a reboot loop. I was able to use the mfstools boot floppy to mount partitions and see the contents of the drive and try to backup the drive (which failed btw). I have since got a hold of knoppix 3.3 mini to run the mfs_tmfstream files. I get "llseek failed" when ever i run mfs_ls vplay in order to get a list fsid's. I am trying to figure out if the drive is totaly hosed now or what.
Series 1 DTivo 3.01b dual WD 120's
Knoppix 3.3 mini boot cd
with the tivo drives in Secondary Master and Slave.
Knoppix would't auto mount the 2 tivo drives but it does see them.
Ran this command.. "vplayer -l" and recieved "llseek failed"
Ran this also "mls_ls /Recordings/NowShowingByTitle" and recieved "llseek failed"
and.. "mfs_info" with "llseek failed" response.
Been doing a lot of reading and did a search on llseek and was only two items with only 1 pertinant and he didn't get a response on his question about it.
btw ran wd utilities and it returned error code of a failing drive. Already have the replacement from them but still have 20 days to return the rma drive.
The llseek error probably means you're not root.
I just spent the better part of a weekend repairing my Tivo from a dead drive, and Since I see other unanswered questions in this thread about it, and because it was hell getting all the info from various places I figured I'd collect my experiences with this together into a post. Hopefully somebody will find this helpful.
First a little background. I have a DVR7000 that I had upgraded to 120GB. I dnd no other modifications. It's been running great for over a year (The S1 sitting underneath it has been going great for 4.5 years with 2 disks. Damn you samsung!) but recently it didn't come back from a brief power outage. I popped the backup drive in and everything worked fine, so I figured it was the disk. A quick scan turned up the dreaded error 0x40 on several sectors... So with a new 120GB drive in hand (seagate this time. 5 year warranty, .2db louder than the samsung) I loaded my backup, expanded the image, forced a call to get to 3.1.1c and felt very empty... Most of the old disk was good, so I was able to get almost every show off my old drive and import it to the new one. As an added bonus I'm now mfs_ftp and tivoweb enabled. Here's how it worked:
This all assumes you have a working linux box. If you don't, get a debian nework installer, and run 'apt-get install build-essential' after you're up and running. That will give you everything you need, and you'll like it.
First you need a way to run commands on your tivo. That means you want a shell of some sort. I opted for bash through telnet. I picked up a linksys USB200M ($29.95 at CompUSA) and set about getting it to work. You'll want to set up two kernel monte to load your 2.4.4-tivo kernel with no initrd. I did this manually, though I pilfered files off of Sleeper's ISO that I couldn't find elsewhere. I recommend the instructions by Cobelli at http://generationtivo.com/monteguide.html. There are other guides, but this one will give you the best idea of what's going on, and why. I recommend running tivoftpd by hand at the telnet prompt instead of in the rc.sysinit.author though for a variety of reasons. If your network doesn't come up, running tivoftpd will reboot your tivo, if you run it by hand it will exit when you exit your shell and you won't forget you have a gaping security hole on your hands, and there's also no point in leaving stuff you're not using running and eating up resources.
Tips you'll be interested in while following that guide:
- There's a 3.1U5 kernel and Filesystem image on Sleeper's ISO in /cdrom/tivoutils/kernel
- You can use 'dd' to copy that filesystem image onto your root partition ('D' partition in the guide) just like you did with the kernel. Ignore what it says about tar.
- You don't have to make a romfs. Use the one in /cdrom/romfs on Sleeper's ISO. It's the same as what you'd make by hand.
[*]Get the networking modules from the first post in this thread.
Once you can telnet in you can put the screws in and be done with the drive swapping. Everything else you'll ever need to do can be done with the bash prompt.
Telnet in and run tivoftpd, ftp in and upload the mfs_ftp tarball from the first post in this thread. You'll need tar to uncompress it, and it contains file types you can't transfer over ftp, so you *must* untar it on the running tivo. There is no 'tar' on the tivo by default. (Or 'ls'. Grrr.) You should upload the 'busybox' binary from the tivoutils/busybox directory on Sleeper's ISO into /bin on the tivo. Then you can run 'ln -s /bin/busybox /bin/tar' to have a working 'tar' command. If you'd like you can repeat that command with 'ls' and 'ps' instead of tar for your own sanity.
Now that you have tar, and the mfs_ftp tarball you need to do the following:
- 'cd /var/local'
- 'tar xvf /path/to/mfs_ftp.tar'
Now with your ftp client upload s2bins.tar from the first post in this thread and do the same thing you just did with mfs_ftp.tar.
Finally, unzip the other archive from that post, unzip, and upload the enclosed mfs_extract and mfs_streams into the newly created /var/local/mfs_ftp directory. (Yes this is getting rediculous. It's still faster than building a cross compiler. Trust me.)
Type 'cd /var/local/mfs_ftp; mfs_ftp.tcl' and you're running. Everything else happens on your linux box in the extraction of shows and uploading.
The rest of the instructions will be in the next post down. This one is getting too long.
Last edited by Ivan; 08-02-2004 at 01:47 AM.
... continued from the previous post.
Now that you've got remote access to your tivo, and a way to insert shows via ftp, you need to extract the shows from the old drive. With 3.x you'll need the version of tridge's vplay that has been modified and posted in this thread. I got the source and built it ('make clean all' in the uncompressed directory if you have a linux system configured as I described above), but the binaries should work just fine.
You also need your linux box to be able to see the tivo partition table. The tivo partition table is a mac partition table with a different magic number and a fixed block size. You could modify fs/partitions/mac.c in your kernel tree and build a new kernel, or you could just grab one of the bootable hack discs out there and use the kernel from that. A list of mfs partitions will get printed out at boot, and you'll need to put those into an environment variable in order to run the mfs_* commands. You'll want to do 'export MFS_DEVICE="/dev/hdX"' where X is the letter that corresponds to your tivo drive, and then 'export MFS_DEVLIST="/dev/hdx10 /dev/hdx11..."' but with the list of all your mfs partitions. This is conviently documented in the readme that came with the vplay code.
Now for the least explained part of the entire process. To extract shows with mfs_tmfstream you need "fsids". The way to get these correctly from your unhacked and dying drive is to run './mfs_ls /Recording/NowShowingByTitle'. This will give you a list of shows. The first column is the fsid you want for the extraction. mfs_streams will give you better show details, but the fsids it prints are *incorrect*.
Now that you've got the fsids you can extract and upload. Extract with './mfs_tmfstream -o show.tmf <fsid>' (you'll use just about 512MB for each half hour). Upload them by ftping to port 3105 on your tivo ('ftp <tivo ipaddress> 3105'), and typing 'cd /tmf', then 'put show.tmf'.
You can automate this, but since your drive is dying, this will likely break when it gets to the parts of the drive that are bad. I used a hacked copy of Roderick Schertler's 'ftp-upload' perl script with the login section commented out and the port number changed in a bash for loop. To do this, make a text file with one fsid per line and then run the following as one command:
'for i in `cat fsids.txt`; do mfs_tmfstream -o $i.tmf $i; ftp-upload -h <tivo ip-address> -d /tmf $i.tmf; rm $i.tmf; done'
Then wait a long time... I've been seeing about 2MB/sec transfers. It's a 120GB drive...
Hopefully this helps somebody... Good luck!
Ivan,Originally Posted by Ivan
I could not get this working to save my life. What exactly did you hack in the perlscript (I'm not an PERL expert but I fiddled around commenting out lines related to password)? I'm not sure why it shouldn't be sending USERNAME and PASSWD since when I use the command line FTP it asks for same. Anyway, neither commandline FTP or ftp-upload work for me. Commandline will start but always creates a file of size 0 and I've already mentioned my problem with ftp-upload.
In frustration I looked around for another batch FTP program and came up with NcFTP. Works like champ.
Here is my version of your comand "FOR" loop.
Even barfs out stats as it is transfering.for i in `cat fsids.txt` ; do ./mfs_tmfstream -o $i.tmf $i; ./ncftpput -u anyname -p anypass -P 3105 -DD -F 192.168.2.30 "/tmf" "$i.tmf" ; done
Is that really what you are getting for throughput? I am seeing about 450 kB/s using WS-FTP from WINDOZE and about 560 kB/s using the above method.Originally Posted by Ivan
I just started the command line and am trying to transfer files from a failing MAXTOR drive. We'll see where it craps out.
Last edited by flynmoose; 09-01-2004 at 01:38 AM.
Well after a faf with having to create an EXT3 partition to temporarily hold the file before ncftp took over (I had some movies that were over 2.0G which a FAT32 partition should be able to handle but wasn't when mounted from Knoppix), I'm having great success and should have full transfer sometime tomorrow evening if the old MAXTOR doesn't crap out by then.
Seeing averages of almost 620kB/s - sure would be nice to get that higher - must go do some more reading on mfs_ftp. Using a Linky USB200M with the 2.0 driver (ax8817-something).
Regarding what happens when it hits a bad spot on the drive (twice now after about 8 hours) - mfs_tmfstream craps, ncftp transfers whatever was outputed and the FOR loop keeps running. Haven't yet had a fatal disk error but I imagine that will cause the loop to just transfer a bunch of files FSID.TMF that will need to be deleted later.
Last edited by flynmoose; 09-01-2004 at 11:46 AM.
Actually, no. FAT32 won't handle files larger than 2GB. I've learned this the hard way when writing some custom backup software.Originally Posted by flynmoose
funny, I have a couple of hundred files here > 2 gig stored in fat32
it's a 4 gig limit, allthough a lot of windows programs choke at 2 due to poor design
Originally Posted by rc3105
That's what it says in the spec and I also have some files that are greater than 2GB that work fine under WINDOZE.
Evidently this is either a Knoppix issue or possibly a mfs_tmfstream issue because everything works fine if I have mfs_tmfstream output to a file on an EXT3 mount but using the same shell/config, it craps out if I output to a FAT32 mount.
I'm using Knoppix because the other Tivo Boot disks out there have the wrong GLIBC.so.6 library and the MFS utilities won't run.
Transfer went well - all but 2 movies out of >70 hours of video transfered over to my Western Digital drive. Over that entire transfer, I averaged a little over 600 KB/s. Took a lot longer than I thought!
WD drive working like a champ but it is considerably louder than the MAXTOR - lots of clunking that reverberates inside the media cabinet. I've got the drive in a drive bay on the outside of the case, so I'm going to put a mouse pad under and see if that helps.
I am about to run out of space on my series 2 tivo. I upgraded it to a 120gb drive long ago. I was hoping for an easy way to get files off without having to hack the tivo but it looks like thats not the case. I'm not technical and to be honest I'm having some difficulty with the various HOW-TO's out there.
I have another 120gb drive, the exact same model as the installed drive. Can I connect both, boot from a linux cd, and DD the tivo drive to the free drive? If that will make an identical backup, then I could attempt to hack one of the drives without fear of losing everything.
Also, if I have the second drive and am successful at modifying the first, can I transfer the streams across the network to the tivo to decrypt them? Or would it be better to use one of hte other methods?
Can anyone tell me if that will work before I take apart the tivo?
If you can expand your system to a larger drive, it's not that much harder to do the more serious hacks. Yes, you can dd the drives. But you can forget about extracting your existing streams, sorry -- you have to have disabled encryption before the stream is recorded.
Clarification: If your TiVo streams are encrypted, you *can* extract them and then reinsert them back on the same TiVo successfully. You just can't view them to another TiVo or use a non-TiVo player to view them.
Thx guys or gals....
I'll do a DD backup of my drive tonight using the mfstools cd. I have an old Dell pIII 500 with no HD and a cdrom drive that should do nicely.
Right now I'm not too concerned with being able to play my recordings elsewhere, I'd just like to be able to pull some off to make room for the rest of the series. I normally just play back and record using a capture card. Unfortunatly 88 episodes in 10 days doesn't leave me a lot of time to clear off the recordings.
It's a SA S2 running 4.01b-02-2-230 and I'd like to try out some of the hacks, web access and ftp would be nice. I think I'll give it a go witht he backup drive.