# TiVo Volume Header Format



## Marconi (Sep 8, 2001)

TiVo drives use a "modified Apple partition map." It appears to me that only the volume header block (block zero) is modified from what Apple uses for their APM (Apple Partition Map) format. The rest of the partition map seems indistinguishable from a standard APM format disk. So, I'm trying to figure out block zero. 

Here's what I have been able to figure out about block 0 on TiVo drives:

TiVo volume header, one block of 512 bytes.
Bytes 0-1:	("14 92") Unknown. On APM volumes, these bytes are the signature "ER" so perhaps the bytes "14 92" are a TiVo signature. These bytes are the same on all the drives I've checked so far. 

Bytes 2-3: "03 06" or "06 03" indicating the boot partition, either 4 or 7 (zero-based). 

Byte 4 starts the string: "root=/dev/hda7" or "root=/dev/hda4" which is null terminated. This string matches the order indicated by bytes 2-3. 

Byte 19 starts the string: "runfactorydiag=true dsscon=true brev=0x1031" and is null terminated. I've seen other strings including: "runfinaltest=2 brev=0x10 contigmem8=16M=16M" and partially overwritten strings like: "unfinaltest=tru" so I'm not convinced these bytes are all that important. 

Bytes 63 through 131, all nulls

Byte 132 starts the string: "unnamed" and is null terminated. This seems to be the same on every drive I've checked. 

Bytes 140 through 163, all nulls.

Bytes 164 through 174 unknown, These vary from one drive to another.

40 GB drive:
0A 54 8F 49 B2 32 31 60 75 92 3C

60 GB drive:
0A E8 E1 80 8F 9D 03 B0 0B E8 3C

80 GB drive:
0A 8D 2F 4C D2 3D 9C 58 7B 16 3C

another 80 GB drive:
0A 6E 00 85 01 7A DC 72 7E 4D 3C

As shown above, byte 164 is always "0A" and byte 174 is always "3C" on each drive I've checked. I have no idea what these bytes indicate. 

Bytes 175 through 511, all nulls.

If any of you can identify the purpose of bytes 0-1 and/or bytes 164-174, please enlighten me.

FYI, the reason I'm interested in this is that I have, on multiple occasions, lost all my recordings when a TiVo became unbootable. Subsequent efforts to rescue data using Linux-based tools gave the error that the volume header was corrupted. Hence, I want to know more about the volume header so that I can effect repairs, should I ever have another corrupted volume header.


----------



## wmcbrine (Aug 2, 2003)

Presumably Linux didn't recognize the format, which is not the same as it actually being corrupted. There's a small kernel patch for Linux that enables it to handle TiVo partition tables, which I used to use back in my DirecTiVo days. I don't know where one might find it now, but there's probably some deal in a database somewhere.

Alternatively, one can obtain a pre-patched Linux boot disk from (among other places) one of the forum sponsors, I believe.


----------



## Marconi (Sep 8, 2001)

wmcbrine said:


> Presumably Linux didn't recognize the format, which is not the same as it actually being corrupted.


When the backup tool (MFSLive boot CD) says it's corrupted, I'll take it at its word. I'm not the only one this has happened to.

Seems a shame to lose an entire drive of recordings because one 512-byte block is corrupted. I think I'll press on with trying to figure out what those bytes mean.


----------



## wmcbrine (Aug 2, 2003)

Ah, you didn't say that you'd actually used a TiVo-oriented boot disc, just "Linux". In that case, yes, probably it is.


----------



## Marconi (Sep 8, 2001)

wmcbrine said:


> Ah, you didn't say that you'd actually used a TiVo-oriented boot disc, just "Linux". In that case, yes, probably it is.


I specified "Linux-based tools" so as to differentiate my situation from those using Windows-based TiVo recovery tools. That the tools were for rescue of TiVo data was only implied. I probably should have been more clear.


----------



## unitron (Apr 28, 2006)

Marconi said:


> ...
> 
> FYI, the reason I'm interested in this is that I have, on multiple occasions, lost all my recordings when a TiVo became unbootable. Subsequent efforts to rescue data using Linux-based tools gave the error that the volume header was corrupted. Hence, I want to know more about the volume header so that I can effect repairs, should I ever have another corrupted volume header.


I feel ya, brother.

Just to be clear, you are talking about the stuff on the disk that comes before the very first partition, said partition being the Apple Partition Map, said Map being the one which lists itself as the first partition of itself, correct?

I'm pretty sure that 14 92 is a TiVo-specific thing. Somewhere in the past when booting a Series 1 and watching the process via HyperTerminal and the serial port I think I remember that being what it complained about if the drive wasn't properly byte-swapped (it came up as being read as 92 14 or 41 29 or something like that).

One of these days I'm going to get enough working machines to be able to devote one to examining old failed TiVo drives with a hex editor and be able to use something else for computer stuff.

Are you looking at S1 byte swapped drives as well as newer, non-swapped ones?

You might not want to be so quick to dismiss the importance of the byte 19 string. Apparently it controls, among other stuff, whether the serial port works or not.


----------



## bsdimp (Oct 30, 2009)

I added the necessary glue to FreeBSD's APM definition to make it grok tivo partitions.

see FreeBSD's src/sys/geom/part/g_part_apm.c for the minimal changes necessary to recognize S1 TiVos. Look at apm_read_ent to see how to read the table in, as well as g_par_apm_probe.


----------



## Marconi (Sep 8, 2001)

unitron said:


> I feel ya, brother.
> 
> Just to be clear, you are talking about the stuff on the disk that comes before the very first partition, said partition being the Apple Partition Map, said Map being the one which lists itself as the first partition of itself, correct?


Correct, though I may be "barking up the wrong tree" as they say. See http://www.tivocommunity.com/tivo-vb/showthread.php?p=4999269#post4999269 There you can see the error messages:
_Primary volume header corrupt, trying backup.
Secondary volume header corrupt, giving up.
mfs_load_volume_header: Bad checksum.
Segmentation fault
_​I'm pretty sure that's the same error message I get when my THDs go bad. I suspect that when the TiVo tools, like MFSTools, mention "volume headers" they are not talking about sector zero on the drive, there being no "backup" of that sector (to my knowledge). That and the error message leads me to believe that a routine called "mfs_load_volume_header" is failing.

So, while corrupted "volume header" is the reason I started investigating this, I don't think I'm investigating the right volume header. Perhaps one of the authors of the tool sets can comment on just what it is that is corrupted when corrupted "volume headers" are reported. Nonetheless, I'm curious to know what all the byte ranges in sector zero of TiVo drives do.

BTW, to snoop around the drives I'm using iBored: <http://apps.tempel.org/iBored/> iBored (free and available for Mac, Windows, Linux) uses a template system to identify sector types and I'm hoping to contribute a template for TiVo drives. The actual partition map of TiVo drives seems to be just like an Apple Partition Map, with the exception of sector zero. So, figuring out sector zero will allow creation of a template for iBored.



unitron said:


> I'm pretty sure that 14 92 is a TiVo-specific thing. Somewhere in the past when booting a Series 1 and watching the process via HyperTerminal and the serial port I think I remember that being what it complained about if the drive wasn't properly byte-swapped (it came up as being read as 92 14 or 41 29 or something like that).
> 
> ...
> 
> Are you looking at S1 byte swapped drives as well as newer, non-swapped ones?


No, my own S1 is retired and I have only been working with the drives from S2 and THD units.



> You might not want to be so quick to dismiss the importance of the byte 19 string. Apparently it controls, among other stuff, whether the serial port works or not.


I suspect that on the S3 and later units, that part has been deprecated, inasmuch as there are no serial ports. As noted previously, the string beginning there is often partially overwritten. (Probably on S3 and later.)


----------



## classicsat (Feb 18, 2004)

The Series 3s do have a serial console port. It is just not on the back, rather a 4 pin header inside. You need a TTL to RS232 level converter, or USB serial adapter without the level driver (such as a hobbyist FTDI cable), or a Bluetooth serial device.


----------



## oldsyd (Apr 6, 2009)

Marconi said:


> Correct, though I may be "barking up the wrong tree" as they say. See http://www.tivocommunity.com/tivo-vb/showthread.php?p=4999269#post4999269 There you can see the error messages:
> _Primary volume header corrupt, trying backup.
> Secondary volume header corrupt, giving up.
> mfs_load_volume_header: Bad checksum.
> ...


Marconi, did you ever find the key to recovering/restoring/repairing the corrupt volume header? I'm asking because I think I'm having the same issue with my TCD652160 and I'm trying to recover the recordings I have which are not replaceable otherwise.

If you want to see what we have tried, the thread is here:

http://is.gd/hrILUh

thx
jay


----------



## ejonesss (Aug 13, 2007)

is this mean there is a driver that could even make mac read the box?


----------



## oldsyd (Apr 6, 2009)

ejonesss said:


> is this mean there is a driver that could even make mac read the box?


If you boot from a UNIX based Live CD, you can use Linux based tools on almost any computer.

I'm still learning on how to repair a damaged superblock.


----------



## unitron (Apr 28, 2006)

ejonesss said:


> is this mean there is a driver that could even make mac read the box?


If you're looking for a way to take a hard drive out of a TiVo, hook it to a computer, PC or Apple, and see what's on the drive as far as recorded shows and such, much less copy the shows from that hard drive, no one has come up with anything that will do that, and I wouldn't expect anyone to do so any time soon.


----------



## wmcbrine (Aug 2, 2003)

It's been a long time since I did it, but there _are_ tools that can list and copy individual shows off a connected TiVo drive. However, at the time, there was no way to decrypt them, so it didn't do much good unless you'd disabled encryption before making the recording.


----------



## unitron (Apr 28, 2006)

wmcbrine said:


> It's been a long time since I did it, but there _are_ tools that can list and copy individual shows off a connected TiVo drive. However, at the time, there was no way to decrypt them, so it didn't do much good unless you'd disabled encryption before making the recording.


Could they be copied and saved as .tivo files that Desktop could handle?


----------



## wmcbrine (Aug 2, 2003)

They're in a different format, and they're encrypted differently. If you disable the encryption, there are tools to convert them to plain MPG files.


----------



## Marconi (Sep 8, 2001)

One of my series 3 THDs has just lost all its recordings - again. This is the fourth or fifth time that I can recall. Each time it happens, it goes into a reboot loop and trying to recover anything using the MFSLive CD results in the copy error: "volume header corrupt". Each time it has happened, I have put in a new drive cloned from a 1 TB image of the original factory drive. That is, to create the backup drive/image, I configured the original drive, setting up the CableCARD, etc. then copied and expanded the original drive to a 1 TB drive which became my permanent, bootable backup. I've compared to ensure that the partition sizes are identical between the backup disk and the corrupted one. This is why I thought dd would work. 

Either something in this TiVo is corrupting the volume header of every drive I put in it or there's something wrong with the factory image on my stored 1 TB drive -- something that takes its time to finally manifest after being copied to a new drive. I wish I knew which. Sometimes the new drive works for months before becoming corrupted, sometimes only weeks. Whenever I give up trying to salvage a drive with a corrupted volume header, disk diagnostics always show that the drive is functioning properly. I just erase it and use it elsewhere. 

I also wish I knew what, exactly, the "volume header" is that is being corrupted. 

This most recent time it happened, I decided to try something different. Assuming the "volume header" to be the first block on the drive -- the one before the partition map begins -- I decided to just dd the first block from the 1 TB backup to (a dd clone of) the corrupted drive. No help. 

Then I did a dd copy from the backup drive of everything that is not recordings. That is, I used dd to copy everything starting at the beginning of the disk up to, but not including, the swap partition. All the bootstrap stuff, the OS, etc. was copied to (a dd clone of) the corrupted disk. This did not result in a bootable drive. 

So, what "volume header" is corrupted? It must be in the media areas of the drive as it does not appear to be in the booting /OS areas (even though failure to boot is the primary symptom), which were dd'd but which did not fix the corrupted disk.

If I knew just what is corrupt, I could dd just that from the backup to the corrupted disk and save my recordings. 

So, where IS this "volume header" that is corrupt?


----------



## telemark (Nov 12, 2013)

That sounds alot like the MFS header. There are many people here who know more about MFS, so I'll only cover the Linux bases.

You should view your logs, unless you have already overwrote them. If the only problem is in MFS, that gets configured late in the boot process. The rest of the OS has plenty of opportunity to log complaints about MFS or something else.

What's the Software version you're using to image from? If it's old, you might be going through a software update at some point. if so, you can NOT go through and recopy pieces from the old image. There's lots of opportunity for mismatch which would make the situation worse.

If you think this happens consistently, next time it happens, concentrate on analysis rather than fixing it.
View the logs.
Binary Compare each of the small partitions.
(block0 and partitions 1-7 (apm, kernel1, kernel2, root1, root2))

Someone confirm this (I'm not an S3 person):
If you have multiple THD, you can reimage then C&DE from another working unit. Then if it happens again, you've isolated it to the hardware instead of the image.

Is there any hardware modifications or other unusual history to this unit?


----------



## squint (Jun 15, 2008)

Marconi said:


> So, where IS this "volume header" that is corrupt?


I dealt with this before but my memory's hazy. I should have taken better notes...

I believe it's where the magic number (typically EBBAFEED) is located. I have a 2 tb TiVo HD drive that got stuck in a green screen of death loop and was giving me a corrupt volume header error.

It should be in partition 10 and a partition map of the drive provided by WinMFS indicates it's in sector 311662658 on my drive. I go to that sector using a hex editor capable of editing drives (iBored or HxD) and see:


```
00 00 00 00 EB BA FE ED 1C F9 D6 33 00 00 00 10
00 00 00 01 00 00 00 40 00 00 02 40 00 00 00 01
00 00 00 01 2F 64 65 76 2F 68 64 61 31 30 20 2F
64 65 76 2F 68 64 61 31 31 20 2F 64 65 76 2F 68
64 61 31 32 20 2F 64 65 76 2F 68 64 61 31 33 20
2F 64 65 76 2F 68 64 61 31 34 20 2F 64 65 76 2F
68 64 61 31 35 00 00 00 00 00 00 00 00 00 00 00
```
When the drive was stuck in a GSOD loop, the EBBAFEED was overwritten with something else. I changed it back (perhaps making some other changes using a working drive's header as reference). Afterwards, I was getting checksum errors which I corrected that using mfs_info -f from the MFSLiveCD.

If you're losing your recordings anyway you might want to download a fresh image and use that the next time around. That might prevent this problem from reoccurring.


----------



## telemark (Nov 12, 2013)

There's enough information in the linked threads to check it by hand if not repair it.

Could you run these commands on the disk you were cloning from and the damaged disk?

# pdisk -l /dev/sdX
# dd if=/dev/sdX10 bs=512 count=1 | hexdump -C

Edit:
per ggieseke's request add:
# dd if=/dev/sdX bs=512 count=17 | hexdump -C
# dd if=/dev/sdX10 bs=512 skip=($TOTAL-1) | hexdump -C


----------



## jmbach (Jan 1, 2009)

I had an OLED S3 that it happened to after a power blip. (Also had bad capacitors in the power supply). Fix was similar to squints. Also replaced the caps and place it on a APC power backup. Have not had an issue since. BTW the magic number is 0xABBAFEED in 32 bit MFS header in the OLED S3 (and I think earlier models as well). In the TiVo HD and later have a 64 bit MFS and magic number 0xEBBAFEED


----------



## ggieseke (May 30, 2008)

In MFSLive, WinMFS or DvrBARS lingo the volume header is the MFS volume header, not the drive header. Many people call it the MFS superheader.

It's the first sector of the first MFS application partition (usually partition 10). There is also a backup copy in the last sector of that partition.

Fixing it should be fairly easy if you provide the hex dump that telemark requested. Dumping the first 17 sectors on the drive so we can look at Block0 and the APM would also help.


----------



## Marconi (Sep 8, 2001)

telemark said:


> That sounds alot like the MFS header. There are many people here who know more about MFS, so I'll only cover the Linux bases.
> 
> You should view your logs, unless you have already overwrote them.


Where are these logs? Path?


> ...
> 
> What's the Software version you're using to image from?


11.0m01-2-652.


> If it's old, you might be going through a software update at some point. if so, you can NOT go through and recopy pieces from the old image. There's lots of opportunity for mismatch which would make the situation worse.


I would never do that. The backup image is current, version-wise with the installed version. The original drive, however, has not been back in the THD since I first removed it. Should I ever have to resort to using it, s/w updates will almost certainly be required. I think I may install that drive and update its s/w version just to have it current. Still, I would never copy parts from it since it's a 160 GB drive. The original drive was used only to create a backup image, expanded, and then put on the shelf.

All backups since then have been to an identical drive to the one in service. All partition sizes match.



> If you think this happens consistently, next time it happens, concentrate on analysis rather than fixing it.
> View the logs.


They are where?


> Binary Compare each of the small partitions.
> (block0 and partitions 1-7 (apm, kernel1, kernel2, root1, root2))
> 
> Someone confirm this (I'm not an S3 person):
> If you have multiple THD, you can reimage then C&DE from another working unit. Then if it happens again, you've isolated it to the hardware instead of the image.


Probably a good idea for the next time this happens.


> Is there any hardware modifications or other unusual history to this unit?


No mods beyond the larger drive. The only unusual history is that these "volume header corrupt" incidents seem to be more frequent now.


----------



## Marconi (Sep 8, 2001)

telemark said:


> There's enough information in the linked threads to check it by hand if not repair it.
> 
> Could you run these commands on the disk you were cloning from and the damaged disk?
> 
> ...


My generic PC hardware is down for repair just now. (The hinge of the hot swap drive bay broke.) Is it safe to put a TiVo drive in a Mac? I'm always afraid OS X will start adding all the files a Mac uses, or start indexing, or "repair" the modified APM that TiVo uses.

Do I dare put a TiVo drive into a hot swap drive bay connected to my Mac?


----------



## telemark (Nov 12, 2013)

Tivo logs are like a linux box:
/var/log/

/var should be sda9 (hda9) for a Tivo drive... ext2, I think.

I made a guide once, but if you use a Tivo Boot CD most of it can be skipped.
http://www.tivocommunity.com/tivo-vb/showthread.php?t=517410

I'm not sure what kind of drive bay you can connect to Mac, but I've connected S4 and Roamio drives to OS X many times without issue via USB (to SATA).

The S4 (should be similar to S3) drive's Partition Map gets recognized, but nothing beyond that...unless you have a ext2 Mac somehow (FUSE). That may be the bigger point, once connected to a Mac, the number of actions that can be taken from there is slightly more limited.

pdisk, dd, and hexdump should work on OS X. The devices names would change to be /dev/diskX and /dev/diskXs10


----------

