Making TiVo Big

The TiVo is frighteningly cool for numerous reasons. Not the least of those reasons is that it's built around off-the-shelf parts and an open source Operating System (Linux) - this makes the whole thing highly hackable.

While many hacks are possible with varying degrees of difficulty (Ethernet, drive expansion, kernel hacking, video stream extraction, etc) by far the most common, easy to do, and certainly least controversial, is drive expansion. By adding extra drive space to a TiVo you're able to expand the amount of recorded material the unit can store.

Here's how I upgraded my DirecTV/TiVo combo box from 35 hours recording capacity to 108 hours.

NOTE: You can destroy your TiVo and incur great personal injury in any one of several exotic ways by doing this. Unless you're comfortable with upgrading PC hardware, working near unshielded power supplies, understand how hard drives work, and are not afraid to render $500+ of equipment useless, do not try this.

You will VOID your warranty if you do this.

People will laugh at you if you break your equipment.

Starting Equipment:
I've got a Philips Digital Satellite Receiver/Recorder, AKA DSR6000. This unit is a combined DirecTV receiver and TiVo recorder. This hardware does not have an analog to digital converter so it is unable to record from any source other than the DirecTV signal. This unit comes with a single Quantum 40.0 GB AT Fireball lct 20 (Quantum PN QML40000LD-A) drive in it.

The computer that was used for all the data shuffling is a HP Kayak XAs with a 500MHz PIII and 380MB RAM. This machine caused some difficulties for me since I'm using only SCSI drives rather than IDE.

Software Needed:
I initially used Dylan's Boot Disk for backup purposes, but then decided that I didn't like loosing my computer for the duration of the copy. I ended up simply using my normal Linux environment for backups and restores (dd is the same in both environments) and used Dylan's Boot Disk only to bless (i.e. partition) the new drive once I reached that stage.

Stuff to Read:
You should be familiar with the whole process before you start. You should read:

  1. The TiVo Hack FAQ
  2. The TiVo Underground Forum
  3. The TiVo Upgrade Article on C|Net

There are other places out there that will have usefull information, but these are the best to start at.

Stuff to Buy:
While it is possible that you can simply add a single new drive to your system, this is greatly discouraged. Adding a drive causes the TiVo to perform a non-reversible software change on your master drive. For this and other reasons it's much better to work with a duplicate drive. You should buy:

(1) Quantum 40.0 GB AT Fireball lct 20 (5400 RPM)
(1) 60+ GB slave drive. Each GB will provide just under 1 hour of recording time. I used a Maxtor Diamond Max 80 (5400RPM), 81.9 GB capacity as measured by Maxtor with GD, not G (i.e. 1 GB = 1,000,000,000 bytes, not 1,073,741,824 bytes).

The Process:
After several false starts this is the proceedure I ended up using successfully:

  1. Install the new big drive into the host machine. I installed mine as the secondary slave drive (my CDROM is my secondary IDE master) on the IDE bus.
  2. Install the original TiVo drive into the host machine. I installed it as the master drive on the primary IDE bus.
  3. Create a backup of the original TiVo drive:
    1. Boot into standard Linux environment (i.e. off of your Linux install, not the boot disk with its subset of utilities)
    2. Create the appropriate ext2 file system on the larger drive:
      cfdisk /dev/hdd
      This will get you to the point that you can create file systems, etc. Use the arrow keys to select [New] and hit [Return]. Accept whatever is offered for Size (i.e. hit [Return] again). Use the arrow keys to select [Write] and then [Quit]. You are now the proud owner of a huge ext2fs file system.
    3. Mount the file system:
      mkdir /tmp/space
      [return] mount /dev/hdd
    4. Copy the TiVo drive to an image on the new file system:
      conv=noerror if=/dev/hda
      This process will take a long time. Total time will vary depending on CPU speed, etc, but it will be several hours at a minimum. On my system (see above) the copy took 5.5 hours. dd will not provide any status information until it's finished. If dd reports any errors then the backup may not be good. You may want to repeat the process.
    5. Remove the TiVo drive and replace it with the new backup drive.
    6. Copy the image onto the new backup drive:
      dd conv=noerror
      of=/dev/hda [return]
      On my system this "restore" took nearly twelve hours, more than twice as long as the original backup. Be patient and let it go.
    7. Install backup TiVo drive into TiVo and verify that everything works as expected. Make sure you have the drive set for master (it should be if you installed the same way I did above). If you have problems (TiVo won't start, etc) repeat (6) above. If things still fail repeat (1) through (6) above.
  4. "Bless" the new large drive:
    1. Make certain that only the new large drive and the CDROM are on the IDE bus (the drive should not be the master on the Primary IDE bus - for some unfathomable reason BlessTiVo won't work with a drive in that position)
    2. Boot off of Dylan's Boot Disk
    3. Login as root (i.e. type root and hit [return] when prompted)
    4. "Bless" the drive:
      BlessTiVo /dev/hdd
      When prompted with a warning, just agree. This is BlessTiVo just giving you one last chance not to destroy the data currently on the drive.
  5. Install the "blessed" drive into your TiVo as the slave.
  6. Double check all your connections. Is the Quantum set as master? Is the Maxtor set as slave? Do they both have power attached? What about the IDE ribbon? Did you re-attach the fan?
  7. Boot the TiVo. This may take a few minutes longer than usual as the unit recognizes the extra drive and adjusts itself accordingly.
  8. Visit System Information and scroll down one page. Your new recording capacity should be "Variable, Up to 108 hours"

Some notes on why I did it the way I did.

Real Linux:
My everyday desktop environment is Linux. It seemed a little silly to me to give up the use of both my computer and my TV while I made this copy, so I chose to use the dd from a full install of Linux rather than the stripped version on Dylan's Boots Disk. This allowed me to simply background the process and use my computer as I normally would.

No bs= with dd:
After wasting days copying with various dd options I decided to stop trying to speed things along by changing the data read and written by dd. When I used bs=1024k (as specified in the TiVo Hack FAQ) I would often get "Target Device Not Large Enough" errors. I suspect that this had to do with dd wanting to be able to write out a complete 1Mb of data at the end of the disk and having some subset of that available.

No sync with dd:
sync caused more copying difficulties. sync causes dd to pad the input block with NULs to the ibs-size. What this basically means is that it make more data and can cause things to not properly line up if software is looking for data to being and (more importantly) end at certain locations.

Copy through intermediary:
I made a copy of my master TiVo drive through an intermediate drive location for one reason: safety. It is possible to simply copy from the primary TiVo onto the new backup (this is how most people do it), but there's a certain risk involved in doing this:

dd conv=noerror if=/dev/hdb
looks suspiciously like
dd conv=noerror if=/dev/hdd
The former copies the contents of the primary slave over the contents of the secondary slave, the latter does the opposite. Since even a few bytes from the new drive copied into the wrong spot on the original drive would render the original useless, I was uncomfortable with this arrangement. Initially I simply spent much time making sure I knew where each drive was and verifying that the bits came from (and went to) the expected places by copying to /dev/null:
dd conv=noerror if=/dev/hdb
This arrangement copies to contents of the primary slave to a faux device (/dev/null). This allowed me to watch the activity light on the drive to make sure the correct one was blinking. After much worrying over this it occurred to me that I had a monstrously huge drive that I could simply use as a staging ground. Since I would be using a file as my out (backup) there was little chance of a 2:00am SNAFU happening. Likewise for the restore to the new drive.

Why this took me two days too long:
I am extremely uncomfortable with the shutdown procedure of the TiVo. Linux (and Unices in general) don't like just having their power yanked. It doesn't give them time to clean up their file systems, etc. Rather than research at all if there would be a better way of doing this I simply assumed (poorly) that putting the system into Standby would be sufficient. While that caused the TiVo to blank the screen, it didn't accomplish what I wanted (a different story there).

The problem from this came after my first successful backup/restore. I placed the new drive into the TiVo and started up. After acquiring the satellite signal the screen went blank. I removed power and restarted several times. Each time the screen went blank. I mounted the ext2 file systems on my Linux box and began examining the boot records of the TiVo. Everything looked healthy, so I could only assume that I had an error in the copy that was causing a kernel panic during boot. I started over and made fresh copies of the drive, etc. A full two days later (I did have some other things to deal with too) I tried booting the new copy. Same behavior. On a whim, however, I hit the TiVo button. Much to my chagrin the machine woke up and began functioning normally.

Yes, the sleep state is stored on the drive. The original copy was totally healthy - the machine was simply going to sleep after boot. Watch for this on your system.

Disclaimer: My text. Not your text. This text sprang forth in 2001 and is therefore copyright 2001, DzM, through whatever year it is now. So there.