# TiVo corrupting one recording with video from more recent recordings.



## razer (Apr 4, 2007)

I upgraded my Series 1 14hr tivo with a single 13.6 GB disk to a pair of 160GB disks. It now corrupts older recordings with video segments from newer recordings.

I followed the Hinsdale HOWTO <newreleasesvideo-com/hinsdale-how-to/index9.html> (hereafter referred to as "the howto"), and used mfs tools <newreleasesvideo-com/hinsdale-how-to/MFSLBA48.zip> The CD boots and prints to the screen; "PTVupgrade LBA48 Utility Disk Version 1.0 - Series 1 Units Only!"

I have a Philips 14hr HDR112 Standalone, using a single 13.6GB A drive (I copied that off of the howto). The drive was a Quantum, that was locked, and the TiVo software version is 3.0-01-1-000. I performed the upgrade as described in the howto using two Maxtor DiamondMax D540X-4G 160GB UATA/133, 5400RPM, IDE disks (4G160J8) from here <unityelectronics-com/product-product_id/3967/m/Maxtor/p/4G160J8_R> (the disk says ATA/133 on it, not ATA/33; the website uses both. Probably a typo. I trust the disks label.)

I used qunlock.exe to unlock the Quantum drive as it was reported as being exactly 10MB. In the text of the howto, it says


> For most model TiVos and most common upgrades you should download Tigers Mfs Tools Boot CD 11.5MB containing all necessary utilities (If you have older Series 1 models you should use Mfs Tools Boot Cd (10.3MB)).


 In spite of my having an older series 1, I opted (perhaps incorrectly) to use the 11.5MB version because I am using large disks (>137GB) and the name (MFSLBA48.zip) included LBA. I assumed that that meant it has Large Block Addressing support and as such would be necessary.

I followed the instructions... used option #1 for step (7) ("BACKING UP A SINGLE DRIVE TiVo"), continued on following the instructions and used configuration #3 on step (10) (From: Any Single Drive TiVo ## To: New A and New B Drive). All went well, no errors were reported along the way, the backup and single drive restore worked well, the TiVo booted and seemed to function normally. I again removed the disk from the tivo and then copied everything from the old disk to the two new disks using the dual disk command from step 10, opt 3. The command I used is


> mfsbackup -Tao - /dev/hdc | mfsrestore -r 4 -s 127 -xzpi - /dev/hda /dev/hdb


 I've read in places that "q" is used for mfsbackup to make it quiet and not send status information down the pipe, and "n" in front of "xzpi" for mfsrestore, thought, I think those were referring to newer versions of the relevant programs. I was using the howto and the programs referenced therein. This is the option that preserves the recordings from the original source disk; which amounted to 9.5 hours of VBR programs at medium quality. That took about 20-30 mins, had no errors. I put the new disk pair into the TiVO making sure to have the drives jumpered correctly and also have the IDE connected properly, and the disks were connected as A master and B slave. I powered the tivo up and all seemed well. It reported as having space for 113 hours at best quality, 414 at Basic quality. The process was completed around 5:40pm yesterday (Monday 4/2). I reconfigured it to record everything thereafter at best quality.

In this new configuration, it recorded 5, 1hr programs that evening. I will call those programs *1*, *2*, *3*, *4*, and *5*.
Recordings *3* and *5* were definitely uncorrupted on Monday.
The next morning (Tuesday) it recorded a half hour program and two one hour programs (call them *6*, *7*, *8*).

During that afternoon at around 2pm, the power browned out to 52.7 VAC-RMS. The UPS tired to switch to battery, but failed (batts too old), and the whole entertainment rack powered down (TiVo included). Later I tried to power the UPS back up, and the power came on (to the rack) for around 3 seconds, and then went back off. I took the UPS out of line and connected power directly to the mains and everything powered up normally. That evening at 9pm, it recorded a single 1hr program (call it *9*)

This is where things went terribly wrong.....

That evening at around 10:15, I go to watch program *5*. The program info screen under "Now Playing" correctly reports it as being 1:00 long, when I play it, the bar shows it as being 1:00 long, but only the first :30 of the bar is green, the rest is just shaded (as if a partial recording). From minute :0 to minute :28 it is video from some portion of program *9*. The remaining 2 minutes are the correct video for the program that should be playing.

Program *4* is suppose to be 1:00 long, the info screen and the bar report this correctly. The green portion indicates that it is :24 long. This program is corrupted with video from program *8*, from minute :0 to :16. From :21 to the end at :24 it has the correct video for the program it should be. The block from :16 to :21 is not accessible. Depending on play or ff/rw, it will skip over that section, or jump to the beginning or ending of the recording (like when you use the ->| key)

Program *3* is supposed to be, and is, 1:00 long. It is correct from :0 to :17, and then corrupted with video segments, again from program *8*, from :17 to :35. The transition in the video at :17 is similar to what I normally see at the beginning of the recordings; I see the channel numbers appear on the screen, and the cable box changes channel. The tivo normally captures this at the beginning of every recording. So the corruption at that point is with the first portion of recording *8*. The video from :35 to :54 is unaccessible just as with program *4* above, and from :54 to :60 it is the correct video that should be playing.

A quick viewing shows that all other programs appear to be unaffected, though, I have not checked exhaustively. I have not tried deleting the programs that are the subject of the duplication, nor do I believe such an action would do any good. Live tv and other functions I've used _appear_ to be unaffected.

At this point I do not think that the power fluctuation had any effect on this, and furthermore I have no reason to think that future recordings won't cause additional corruption to previously recorded programs. Unfortunately, I cannot determine a relevant point in time where I know that everything was ok, other than Monday night when all five programs were uncorrupt. Well, that is necessary since the programs that they were corrupted with were recorded the next day (Tuesday).

The howto also states this about using large drives in an old tivo


> "The original Series 1 models have ATA and TiVo kernel confinements that limit using at most 137GB (128GiB) of any drives installed. Larger drives will function but you are currently limited to a maximum of 2 drives x 137GB (128GiB) or 274GB (256GiB) of addressable space in Series 1 models."


 I will assume that the large drives are not causing a low level addressing problem since the tivo reports the space as being very large (113/414 hours) What appears to be the case is that the tivo software is not properly utilizing the space. Perhaps using MFSTools LBA was the error.. it understood the disks too well, and now the tivo does not understand then correctly? Partitions too large? Interesting though. if it is only going to recognize 256GB and it started out at 13.6GB and could hold 4 hrs 17 min at best quality it should have only been able to hold something around 80 hours at best quality. ((4+17/60)/13.6*256) Even at 137GB it would only be 85 hr. Now, since I used 160GB disks, if we assume that it was expecting to utilize all that space.. it would be 100 hours. Ok, 113 hrs vs 100? Have 10% computation error? Might be. It expects to have 113 hours available, but does not know how to address it??

I did not perform any kind of diagnostics on the disks before installing. I still have the original disk, so I could perform the upgrade again in a different way if that is the (best/possible) solution.

I apologize for the verbosity of this post. I wanted to include ANY information that could be relevant. Thank you for taking the time to read it, and I very much appreciate any help that you can provide.

-Razer


----------



## blindlemon (May 12, 2002)

I suspect you need to run copykern from the PTVUpgrade CD to install an LBA48-compatible kernel to your TiVo. 

Just using the LBA48 CD to do the upgrade allows the partitions to extend past the 137gb boundary, but doesn't add an LBA48 kernel - so when the TiVo OS starts to store recordings 'past' 137 gb, the addresses wrap and it actually stores them at the start, leading to the problems you've seen.

You can run copykern without redoing the upgrade or losing any data other than your broken recordings.


----------



## razer (Apr 4, 2007)

Thank you so much for the fast response and excellent diagnosis.
I downloaded the latest mfstools from <dvrupgrade-com/dvr/stores/1/lba48_support.cfm>, and installed the LBA kernel using the copykern script.
The tivo has since recorded 2x one hour programs and many one-half hour programs. All appears to be going well.
I must have done something wrong, because for some reason the first recordings that were made after the initial upgrade are all 0 length.
Press play and it immediately displays the end of program dialog asking if I want to delete it. No matter. They'll all be on again soon enough.

Thanks again.


----------

