Direct extraction from a tivo drive in a pc (not networked)

[jerrymc]

I have a SAT-T60 that started rebooting continuously and I want to save some of the shows by extracting them on my RedHat 8 system for reinsertion later on the new drive. The old drive runs xPlusz on v3.0 and all shows are descrambled. I probably have close to 200 hours of shows on this puppy that I'd really like to save.

The methods described in this thread are sound, but I believe they pre-date the unified mfs_* package I released. That package incorporates JonBig's package for PC exporting of tmf files.

So here's what I'd suggest:

Grab the mfs_bin.i386 package here.

Boot linux, unpack the package, and make sure it is on your path.

Export this environment variable to set the device where your tivo disk is installed:

 export MFS_DEVICE=/dev/hdX

hdX should be hda for primary master, hdb for primary slave, hdc for secondary master, hdd for secondary slave. I'm assuming a single disk setup, but you can do dual disks too (export MFS_DEVICE="/dev/hdX /dev/hdY").

Run mfs_streams to list all the streams available. The left most number is the FSID of the recording object for each stream. The title string is next. Make a note of the FSID's you want.

For each FSID you want to extract, do one of the following:

• For .tmf format:

  mfs_uberexport -txv -R FSID -o NAME.tmf

• For .ty+ format:

  mfs_uberexport -xv -R FSID -o NAME.ty+

• For .ty format (no metadata):

  mfs_uberexport -v -R FSID -o NAME.ty

where FSID is the desired FSID and NAME is name of the file you want to dump it in.

I suggest .tmf if you plan on reinserting these shows with mfs_ftp.

I followed Jaimie's instructions and read most of this thread looking for all the info I needed, but I clearly missed something. I loaded the mfs_bin package (3-26-05 version) onto my Linux box, and also tivopart. I ran "tivopart r /dev/hdc", then tried to run mfs_streams to get a list of the FSIDs with the following result:

> mfs_streams /dev/hdc
crc mismatch len=232 0x3ef3aebf 0x7c656b11
Failed to byte swap correctly

What am I missing? I currently have Tiger's mfstools2 loaded on this very machine and use them routinely without any problems. Any help or pointers is greatly appreciated!

Regards,
Jerry

[mikeaco]

Jerry,

I would just find a tivo-based linux boot disc (CD) that supports byte-swapping. You won't have to mess with tivopart that way. Make sure that you have a partition setup on your RedHat setup so that, after you mount to it, you can copy the shows over using the mfs_* utilities.

Mike

[jerrymc]

Jerry,

I would just find a tivo-based linux boot disc (CD) that supports byte-swapping. You won't have to mess with tivopart that way. Make sure that you have a partition setup on your RedHat setup so that, after you mount to it, you can copy the shows over using the mfs_* utilities.

Mike

Mike,

Thanks for the reply. The problem with the CD solution is that I have a second EIDE controller card in my PC and most of the boot CD's that I've run accross don't support it. I only have hdc and hdd available on the main controller and large disks don't cohabitate on the same cable happily. Something about the DMA settings on this old (Pentium-233MMX) PC makes a simple mfsinfo take 20 minutes. Never did figure out how to fix that so I just put the drives on different cables.

Will the latest PTVUpgrade LBA48 CD do the trick and support the extra controller? BTW, the emergency is over. A "clear guide data and to-do list" fixed my reboot issue. Now I just want to learn something new since I've started researching it anyway.

Regards,
Jerry

[oakwcj]

That's the error message reported by mfs_uberexport when I tried to extract recordings from my SD-DVR40, which had been running 6.2 until yesterday when tivosh "strayed" and suffered a fatal error while moviesort.tcl was running. Mfs_streams provided me with a nice list of FSIDs, but it appears that the recordings are unrecoverable. If anyone can provide me any documentation with respect to the error message, I'd appreciate it.

[Jamie]

That's the error message reported by mfs_uberexport when I tried to extract recordings from my SD-DVR40, which had been running 6.2 until yesterday when tivosh "strayed" and suffered a fatal error while moviesort.tcl was running. Mfs_streams provided me with a nice list of FSIDs, but it appears that the recordings are unrecoverable. If anyone can provide me any documentation with respect to the error message, I'd appreciate it.

This error occurs when generating the showing.xml file for ty+ or tmf format output. It's trying to add the tivo software version to the xml. It probably shouldn't be a fatal error if it can't find it. The code is looking for the Name attribute in the /SwSystem/ACTIVE TyDB object. What does 'mfs_dumpobj /SwSystem/ACTIVE' tell you?

In the meantime, if you extract in ty format (no xml), you shouldn't get the error.

{Edit: I've attached a version that doesn't exit if it can't find the tivo software version, returning "UNKNOWN" instead. I'll include this in the next published build too.}

[oakwcj]

Thanks, Jamie. The new version of mfs_uberexport still returns the error, but it then does its job.

The output from 'mfs_dumpobj /SwSystem/ACTIVE is NOT 6.2-01-2-351 or any other intelligible response. it's a right brace } . I'm thinking that's not good.

BTW, I was getting the error while attempting .ty exports. I don't want to try insertion with 6.2, given the reports of problems, so I'm just going to burn these recordings to DVD with TyTool.

[Jamie]

The output from 'mfs_dumpobj /SwSystem/ACTIVE is NOT 6.2-01-2-351 or any other intelligible response. it's a right brace } . I'm thinking that's not good.

Hum. 'mfs_ls /SwSystem' might tell us something. I wonder if the ACTIVE entry was lost for some reason.

BTW, I was getting the error while attempting .ty exports.

I guess it goes through the xml generation code even for .ty exports.

[oakwcj]

Originally posted by Jamie:

Hum. 'mfs_ls /SwSystem' might tell us something. I wonder if the
ACTIVE entry was lost for some reason.

SwSystem has entries for 6.2 and 3.1. [I was running 4.0.1 before 6.2. During a daily call, 3.1 was downloaded. It was marked as an unsafe upgrade, though, because of the database change. And I do have the "uprgradesoftware=false" boot parameter.] Based on a post from ADH, I even dbloaded the swsystem slice for 6.2. I couldn't set it to active, though, because tivosh errors out and causes a reboot every time. My uneducated guess is that moviesort.tcl is very processor-intensive and was hogging the processor when the TiVo wanted to perform another operation. I didn't think to set it to low priority before I ran it. Then, again, I'd never had a problem with it before, although I've since seen other posts reporting non-fatal GSODs.

[fredfillis]

I have an unhacked S1 Dtivo (DSR6000) and am trying to extract recordings for insertion on my now hacked DSR7000.

Have tried to follow AW's quickie how too here and also zobetron's post here. As far as vplay binaries, I have Jamies unified MFS tools from here on my fat32 partition (bin.linux.i686). I am using the PTV universal boot disk and have also tried the "kazymyr" boot disk that zobetron mentions. I have my tivo disk hooked up to my PC as Primary slave. I have been able to determine from MFStools-2.0 on the boot disk that my MFS partitions are hdb10 through hdb13.

If I follow AW's how-to and run mfs_info I get an error that basically says "4 MFS Partitions" next line says CRC Mismatch (detail omitted) and next "Sector in Wrong Zone (33197056 0).

I have previously had a wrong magic number 4d50 in partition 0 but I don't recall the context.

This S1 is a totally clean unit that was working perfectly for 3+ years.

Can anyone point me in the right direction?

[Jamie]

If I follow AW's how-to and run mfs_info I get an error that basically says "4 MFS Partitions" next line says CRC Mismatch (detail omitted) and next "Sector in Wrong Zone (33197056 0).

AW's instructions pre-date the current tools. I'd recommend following the instructions here.

If you are getting crc errors, I'd guess that either your PC is getting errors reading from the ide device (check dmesg for errors), or your MFS file system is corrupted. There are backup inodes, and the tivo will use them when it encounters an MFS inode with a bad crc. The mfs-utils don't do that, though it could be added if you are so inclined.

So, one option might be to put the drive back in the tivo and force a GSOD and hope that cleans up any bad crcs. Another option might be to enhance mfs-utils to go to the backup inode on crc failiures. A third option might be to backup and restore the disk with mfstools. I don't know for sure if that would work, but I remember seeing some backup inode handling in the mfstools source.

[fredfillis]

So, one option might be to put the drive back in the tivo and force a GSOD and hope that cleans up any bad crcs.

Thanks for the tip Jamie. I believe the basic process I have followed to date is pretty close to what you referred me to so it seems like I have some "corruption" going on.

I think I'll do a backup first and try the forced GSOD route with a restore as my Plan B.

In terms of forcing GSOD, I have not done that before but I found the following information.

While booting the power light will change from green to yellow as the line 'checkpanic' in the rc.sysinit gets executed. This happens a few seconds before the screen changes from the startup image to "almost there" and it's your cue to hold down a button (use pause) on the remote to trigger a panic. When the record light changes yellow, key in one of the following sequences:

Snip ...

End Snip ...

57 - mfs check
58 - perform mfs cleanup
-- both of these will cause the green screen and various mfs checks

Is that still good info for Dtivos?

[Jamie]

Is that still good info for Dtivos?

I assume so, but I don't really know.

Another thing you can try is running a ppc mfs_info on the tivo itself. If that *doesn't* get the crc errors, than it tells you that MFS is ok and is something about the PC setup that's messing things up.

There's also a remote possibility that the mfs-utsils tools are broken for series 1 disks. I don't have a series 1, so I can't test anything on that platform myself.

[fredfillis]

Jamie, thanks for your help.

Since I was doing a backup anyway I figured I would just go ahead and restore. That fixed my CRC issues and I was able to get a list of FSIDs via mfs_streams and have successfully uberexported to my PC.

[Jamie]

Jamie, thanks for your help.

Since I was doing a backup anyway I figured I would just go ahead and restore. That fixed my CRC issues and I was able to get a list of FSIDs via mfs_streams and have successfully uberexported to my PC.

Good. Eventually I should look at dealing with the backup inodes, I guess. It's nice to know that a backup/restore will fix it though.

[fredfillis]

Now that I can theoretically insert to my s2 I need to tackle the next part.

The drive from my virgin S1 Dtivo is hooked up to my PC. I can extract recordings from the S1 drive to my PC. However, these recordings are scrambled. I have run mfs_dumpobj and got the output in the form of a text file. Based on reading up on MFS_FTP unscrambles, my DiskConfigurationKey information needs to be in XML format. I can probably figure that out. However, I'm not sure that inserting my S1 recordings to my hacked S2 unit is going to be successful. Based on posts I have read, there are three things required.

Limitations: currently 3 things must match to play or decrypt a scrambled recording

1) CommercialSkipOffset keys (stored in ty+ or tmf archives)

2) tivo hard drive DiskConfigurationKey

3) tivo motherboard crypto chip

if the DiskConfigurationKey has changed for any reason (re-imaged the drive - sw update - clear & delete) the correct DiskConfigurationKey (DC_key.xml) must be restored

Firstly, I'm a little unclear about the first item, CSO. I have seen what I think is conflicting information about CSO keys, do they need to be in or out?

Secondly, am I dead in the water due to the crypto chip issue?

Lastly, I've also read about "compability problems" when transferring S1 ty files to S2. ty1to2 is available here. Do I need to run that or have unified MFS tools brought us beyond that issue?

I'm not interested in hacking my S1, I would just like to get the shows off it and onto my S2. Is this even possible?