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

[rc3105]

by clean I meant uncorrupted - not degraded during extraction

from tridges readme

use vplay to "play" with that fsid to a file or device

use vplayer to play files remotely

vplay default usage msg

/var# vplay
optind=1 argc=1

vplay <fsid> <vidfile>
OR vplay -p <fsid>

options:
-s <start> starting chunk
-c <count> number of chunks to play
-v be verbose

use the 2nd form for direct playback on a TiVo

vplay takes a fsid for stream files. See liststreams

so a little experimenting will generate something like this

vplay 1400984 temp1.ty
mfs_export 1400984 temp2.ty
mfs_stream 1400984 temp3.ty

/var# ll *ty
-rw-r--r-- 1 0 0 7208960 Oct 18 07:43 temp1.ty
-rw-r--r-- 1 0 0 7340032 Oct 18 07:43 temp2.ty
-rw-r--r-- 1 0 0 7340032 Oct 18 07:43 temp3.ty

vplay grabs just video, export & stream get the entire fsid

[ice5]

How can one get the FSIDs without a serial connection?

Originally posted by Fugg
If you do have a serial connection:

Before you power down your tivo and take your drive out, transfer (using your existing serial connection/bash prompt) NowShowing.tcl to a directory in /var, set it executable and run:

./NowShowing.tcl > fsids.txt

when it completes (it can take a few min if you have a full tivo), you will have a file called "fsids.txt" in that directory containing a list of what's on the tivo with the fsids!

Good Luck!!!

[FredThompson]

I've just found myself in a situation similar to that which blasted bill mentions earlier in this thread. One of the 2 drives which were installed in my T60 with xtreme 2.5.2 and xupgrade started acting up and the TiVo won't boot with them. You know the screen, critical error, connect the phone cord, wait 24 hours... Yeah, well, that would probably screw everything up.

The drives are removed and I'm wondering how to extract the data given there's no way to get the fsids using the TiVo itself.

It certainly seems part of the data on the drives is toast but, considering they WILL spin and seem to act ok for now, it should be possible to pull from them.

Would someone please give me guidance on how to do this?

[rc3105]

if you were running mfs_ftp prior to the crash the fsid numbers will be in /dev/hda9 /mfs_ftp/cache/recname.pts

if not, your next best bet is to connect both drives to the pc & make a divorced mfstools 2 backup, restore it to a third drive & if the restore will boot, let it run through the gsod repair (without the phone line attached). if it recovers you can use mfs_ftp or nowshowing.tcl (or whatever) to get the fsid numbers you need. lotta if's there, but SO much easier than...

if those fail, follow the mls & dumpobj steps outlined in tridge's readme & AW's post


--
Riley

[FredThompson]

no mfs_ftp, just vserver but not on boot, only by demand. Don't remember if it was running when things crapped out.

yes, a lot of "ifs" but it's certainly worth a shot to try your first suggestion. I just printed the first page from this thread and was reading AlphaWolf's post about using the tridge binaries. zobetron's post is interesting, also.

Thanks for the suggestion. I think you're absolutely correct, best to try MFSTools to combine the 2 "old" drives onto a single "new" drive and boot the TiVo with it only to see how things go.

Sure would be nice if it "heals" the problems during the last recording and the other stuff is fine.

[TheWickedPriest]

vserver on a PC will sometimes (as in my case) work with a drive that the Tivo can't boot from. I was getting the green screen of death, but I was able to extract nearly all my recordings once I put the drive in my PC.

In this case, you can get the FSIDs as described above:

mplayer-tivo tivo://localhost/list

and to extract:

mplayer-tivo -dumpstream -dumpfile whatever.ty tivo://localhost/12345

IMHO much easier (and faster) than trying to recover the drives; not that you shouldn't do that, too.

[FredThompson]

Unfortunately, I'm not running a Linux box so this isn't an option. Sure would be nice, though. It would allow the TiVo to do it's thing while I mess with the drives.

Oh, what about booting a Linux CD then running? That just might work.

(Sure wish Linux and NTFS got along or Windows could run Linux binaries. It would make things a heck of a lot easier.)

In this particular case, the drives aren't critical, there are already new drives in the TiVo. I'd far prefer to pull the stored content and low-level the drives to see if they fail. Also, I guess there's a chance of corruption but wouldn't it be a good idea to combine the 2 source dirves onto one drive via MFSTools before anything? It would certainly reduce the complexity.

[moe1766]

I'm trying to extract some streams off a SVR2000. Its been upgraded to a dual drive 110 hour unit. The unit is NOT networked. I'm selling it and I'd like to retrieve the streams without added cost.

Are the vplay tools from tivo.samba.org working or just outdated. I find that after setting my MFS_DEVLIST to "/dev/hda /dev/hdb" and trying any of the mfs_* or vplay programs I get an warning that the superblock and actual sizes don't match. It doesn't look like its reading or mapping the second drive.

Has anyone else had this problem?

Using mfs_ls or mfs_streams I can get the directory information to see the names and fsids of the streams listed in /Recordings/NowPlayingByTitle. Extracting the streams gets part way through and exits with an error about not finding the next part of the stream (presumably on the scond drive).

Thanks.

[gobsmack]

EDITED:

Ok, take notes on your drive partitions when they boot and follow Z's DEVLIST command thematically, adding additional /dev/hdxN partitions as needed.

In my case, I have gotten close, but now have an error: the MFS filesystem size doesn't match the expected size (difference is 1024).

I already know the FSIDs I need -- is there a way to supress the errors and grab the fsids directly?

Thanks

[keithc]

I get the same errors as gobsmack and moe1766 - it does seem to be ignoring the MFS partitions on the second drive.

The mfs_export that comes with mfs_ftp must come from a different source but I can't find it anywhere.

I came up with the following patch to the CVS code and can now mfs_export FSIDs that previously errored. Just reinserting the ty now to test (airnet's a bit slow) but if anyone wants to try it out...

btw my disks are from a UK TiVo.

edit:

attachment deleted as it doesn't work properly.

[keithc]

Hold fire on the patch as although it extracted and inserted, it didn't play back properly but I think I'm close.

I don't think this is a compiler version issue.

Running on tivo, the list of mfs partitions is taken straight from the superblock on $MFS_DEVICE.

On i386, you have to set $MFS_DEVLIST and it parses the partition tables looking for MFS types. The CVS code only scans the first device.

[keithc]

Found the problem.

The attached patch now produces streams identical to those extracted using mfs_ftp.

[rich2940]

I would like to try this procedure. But, I would like to duplicate my tivo drive before starting. Would backing up my Tivo dirve with "Backup up your TiVo drive(s) with Mfs Tools", give me a drvie I can extract video files from?

[rc3105]

yes, if you use the -a backup option to include recordings

[KalTorak]

Problem: The file that I extracted expecting a .Ty stream isn't loading into TyStudio Editor.

My hardware: S2 SA, Tivo-branded, originally 40 hours, upgraded with a 200GB disk as described at Hinsdale, running system software 4.0.1 (when the recordings were made) and 4.0.1a now.

--------------------------------------------------
I used one of the MFS Tools boot disks and the vplay binaries from lmurray's server to boot up with my TiVo drive attached, exported MFS_DEVLIST="/dev/hda", and ran mfs_info to get MFS_DEVLIST set properly (I wanna say it came back with /dev/hda10 through 15)

Used mfs_ls to get the filenames and FSIDs in /Recording/NowShowingByClassic, and found that the FSID for the stream I wanted was 39593.

Ran mfs_dumpobj to get a list of FSIDs for the parts of the stream 39593; had lots of parts - RecordingParts, Showings, and I think a Recording at the end. It seemed that only the RecordingParts had FSIDs associated with 'em, and they ran from 39540 to 39559.

I finally used mfs_export to send the first RecordingPart (FSID = 39540) to a DOS (er, Win95 FAT32 LBA) partition that was mounted, and it came out around 500MB (kinda reasonable, the whole stream's 4:20 at best quality). I renamed it 39540.ty, detached my Tivo drive, and rebooted into Windows.

Started up TyStudio Editor, opened the local 39540.ty file, and... nothing. Says "failed to load the selected Ty file", and that's that.

So... Did I, in fact, grab a Ty file? Do I need to somehow connect the pieces before I use TyStudio to see them? Could I have a scrambling Tivo (how do I know??)

Help - thanks!