How-To Upgrade your TiVo

[Jolly-Roger-52]

Hinsdale and friends,

A compilation of success and woes with my 35HR SAT-60 DirecTIVO and keep this thread going. I'm not sure of what caused my problems initially .

I started with the very slow copy everything and expand mode, from 1 40GB to 1 160 GB Segate. All seem to be well. I installed the cover and started experiencing crashes. The system finally locked up solid. I installed the original drive to make sure I didn't zap anything, and ran diagnostics on the Seagate drive. All was well.

This time I restored from the compressed backup image on the Windows drive. reinstalled the upgrade and have been running with the covers off for about two weeks. I suffered one minor crash the first day(auto reboot) and a stall with an error code 4 which cleared up with a manual reboot.

Every thing seems stable now but, I'm afraid to put the cover back on.

Jolly-Roger-52

[Dawgbone89]

Quick question. I have 540040 model, just replaced 40 GB w/ 300GB. Works great. Want to add second 300GB drive. Which can I use,BlessTiVo or Mfsadd, to do this easiest. Thanks

[Robert S]

You can't use BlessTiVo if the A drive has been upgraded (you'd have to restore a backup (without expanding it) if you wanted to use BT).

MFS Tools has a limitation 274Gb per partition, so you'd be better off using a 250Gb drive instead of a 300.

[n00blarME]

Originally posted by Robert S
You can't use BlessTiVo if the A drive has been upgraded (you'd have to restore a backup (without expanding it) if you wanted to use BT).

MFS Tools has a limitation 274Gb per partition, so you'd be better off using a 250Gb drive instead of a 300.

for reals? I thought we were beyond limitations nowadays? Is it just his model that can't do it because I know I've heard of bigger TiVos...

[weaknees]

If you are willing to lose your recordings (but not necessarily your settings) you can make larger drives work - dual 300s or even larger in the HR10-250.

Michael

[avramd]

Originally posted by tivoupgrade
Its just as likely to have two bad drives as it is to have one (according to the notion of statistical independence)... best to run the manufacturer's diagnostics on them to make that determination, however.

Actually, I have since run the MFR's diagnostics (the extended tests too, not just the quick tests) on both drives and they both came out with no errors.

What direction can I possibly go next to get these programs to stop freezing? The wierd thing is that recently recorded stuff never seems to have any troubles, it's mostly recordings that have been around for a week or more.

Oh, p.s. - Technically it is not just as likely to have two failures as one - it is the square - if something is 1% likely to happen in one instance, then it is 0.1% likely to happen in two independent instances. ;-)

[jdr93]

Re: Re: some programs freeze, others fail to record (avramd) re: oh p.s.

well, except .1 is not the square root of 1, 1 is.

and we're likely not talking about random events anyway. if a drive fails, a similar one in a similar setup under similar circumstances is likely to fail in a relatively short period of time.

[avramd]

but you are right, my math was wrong - if it is 1% likely to fail, then it is 0.01% likely to fail in two independant instances. If the probability of failure was actually 1, that would mean all drives fail.

Anyway, these drives did not "work and then fail." They are operating fine most of the time still. And the incorrect behavior was there from the first moment on both drives. And again as I said they pass the WD diagnostic tests with flying colors. Whatever is wrong was wrong from the beginning.

I am concerned that there is something else wrong, not the hardware, but perhaps a problem with the filesystem - that somehow blocks are getting overwritten when they should not be. It's as though as time goes on, and more recording gets done, every once in a while, a block from one recording gets used for another recording, and then the first recording chokes when it hits the block that doesn't belong.

[jdr93]

avramd - it seems like wiping the two drives entirely and starting over would eliminate the software on the drives as the culprit. but in rereading some of your posts i get the feeling the problem may be a loose connection inside the box, or perhaps a bad solder point on one of the boards. it does seem frustrating, but i'd look at every connection inside, and if you find nothing that makes it run properly, i'd wipe the drives and start over with a new download of the software. (?fan working, temperature good?)

[Robert S]

Software problems are unheard of TiVoes (well, there are a few bugs that cause minor problems, but they don't corrupt themselves the way Windows PC's do).

This is a very strange problem and I don't think this is a simple case of a failing hard drive.

I wouldn't wipe these drives, but I might try a different one, just incase the fault is in one of the drives' electronics.

But I'm guessing it's something like a bad RAM chip, although jdr's idea about a loose connection is good too.

[avramd]

I was more wondering if I could have somehow screwed up the filesystem when I did the drive upgrade. I did use the LBA-aware upgrade disk (they are 160GB drives), and the instructions I felt were pretty straight forward other than that. I also wonder if it's possible there's a bug in the drive's own firmware - that would certainly explain to identical drives having identical behavior. I tried looking for firmware updates for the drives, and I don't think there were any.

[Robert S]

Upgrading to 160Gb or larger drives with the LBA-48 CD and installing them in a TiVo without LBA-48 support is just dumb and you can expect Fate to punish you accordingly.

Is that what you did?

[avramd]

Well, I'm pretty sure I'm not dumb, but I suppose that is subjective. My both of my series 2 model #'s were in the list in the Hinsdale How-To of machines that support LBA-48. I did search for whether there was any extra step, and the results I found were "no, those models already have an LBA-48 capable kernel, just use the LBA-48 CD to do the space upgrade, that's it.

Please educate me if I've missed a step!

[ThreeSoFar]

The older S2s won't do LBA48---YET! I would bet money once this TTG upgrade comes out (did I hear it will be version 7.*?) that it will support LBA48 regardless of which S2 it's on.

[avramd]

ThreeSoFar - do you have a link or quick list of which S2's do/don't support LBA-48? Like I said I'm pretty sure mine were on the list in the Hinsdale How-To.

[avramd]

Ok, I just read the latest Hinsdale, and it says "Larger drives will function but you are currently limited to a maximum of 2 drives x 137GB (128GiB) or 274GB (256GiB) of usable space (exception are the Pioneer DVD/TiVo, HR10-250, TiVo TCD540XXX models, and Humax models with large drive support that can address larger drives)."

My S2's are a 140XXX and a 240XXX.

I SWEAR that when I followed the HowTo about a year ago, there was an explicit list of which S2's supported LBA-48, and both of mine were on that list. Am I on crack? Or did the HOW-TO used to list more S2 models as having LBA-48 support than it currently does?

Was the How-To wrong? Or did TiVo actually do a "downgrade" at some point, swapping in a less capable kernel?

I don't know how I could have screwed this up - I was fully aware of the LBA-48 kernel and >137GB drive issue, and explicitly read the doc looking to determine if I was a candidate for it or not. I remember it saying "consult the list below to determine if your model supports >137 GB drives" or words to that effect. Was I really wishfully thinking with this much detail?

[Robert S]

Those models have never had LBA-48 support, although, as 3SF said, we're expecting the release of the TTG software to push new kernels out to all Series 2 stand alones, so your problem may go away on its own fairly soon.

[avramd]

Yes, I was thinking I might get lucky and have it "just work" when the upgrade hits. Please forgive me for not searching for this, but... Do we have any tangible reason to expect 7.1 to have an LBA-48 aware kernel? Or is it really more that we are "hoping" it will?

[Robert S]

It's difficult to quantify as TiVo haven't said anything about it at all.

The two tangible facts are:

All TiVo software upgrades replace the kernel with a new one, although usually that one is identical to the old one.

Version 5.x runs on an LBA-48 kernel, so TiVo do have one qualified for use on the Series 2 TiVo.

[avramd]

What is special about 5.x? Why weren't my machines upgraded to it? I guess the best thing we can hope for is that they would have to make an extra effort to put different kernels in different variants of 7.1, otherwise their boxes wouldn't be able to support large drives either.

[ThreeSoFar]

bump

[bobgcampbell]

I've got a simple set up and can't get a good copy of my tivo drive.

TCD24004A (40G drive)

hda = new drive, 72G IBM Deskstar
hdb = none
hdc = old tivo 40G
hdd = cd-rom

I've tried all kind of combinations of mfsbackup | rmfsrestore and can't get the 72G drive to boot. I had done this once before on a series 1 without any trouble.

I've tried a mfstools 3.0 and ptvupgrade-4.01 (non-swap) boot cds. I have tried with expansion and without. I've tried with preserving recordings and without. I can't get a copy that will boot.

Every time the mfstools say that the copy was successful, no errors are reported. dmesg always shows drives being detected. mfsinfo shows partitions 1-13 on the old drive and 1-16 on the new drive.

I've followed the instructions from hinsdale and tivo.upgrade-instructions.com, but none of the commands give me a bootable drive.

This drive used to have XP on it, is this a problem. I tried nuking partitions on the new drive using pdisk, but it didn't make any difference.

When I copy without expansion and then try mfsadd, it says nothing to add.

Help!

Bob

[ThreeSoFar]

why such a tiny drive? And why an IBM? They really really suck. And drives are so cheap now.

You can get a 160G samsung for $90 from newegg.com.

[bobgcampbell]

why such a tiny drive? And why an IBM? They really really suck. And drives are so cheap now.

You can get a 160G samsung for $90 from newegg.com.

Well, it's what I had laying around. I want to experiment to make sure I know how the tools work before I do the big drive. I want to get a clean copy, hack it up, then copy to a big one, all while leaving the original 40G untouched. I'm just cautious. Any known problems with IBM?

Bob

[marquis6461]

Don't know if this will help you but I have used the Sleeper Iso Disk for that very purpose of making Backups. I love it. Very easy and quick. No fuss...

[bobgcampbell]

Don't know if this will help you but I have used the Sleeper Iso Disk for that very purpose of making Backups. I love it. Very easy and quick. No fuss...

I haven't tried this yet since I don't have a FAT drive to use for hda, all mine are nfts.

Also, I had read that there are issues with newer hacks (killhdinitrd?) on a sleepered disk. The weethet sleeper page says it is an old process, and also, the instructions are for direct-tivo, although other pages say a SA series2 is the same. I'm still digging through posts to research that one, but since I'm stuck on square one, i'm not worried about that yet.

Bob

[bobgcampbell]

I couldn't even load XP or Linux onto it. An 80G seagate worked.

Bob

[alan]

I was going to put in a larger drive in my old Sony SAT-T60 and I created a boot CD from the mfstools 2.0 image, but I was having trouble with byteswapping and getting the 1492/9214 byte-swap problem with these type of errors:

Hdb: Signature 1492, be16 Signature 9214
03:00: block 0 has signature 9214 rather then 1492
unknown partition table

Hdc: Signature 1492, be16 Signature 9214
03:00: block 0 has signature 9214 rather then 1492
unknown partition table

My drives were mounted as:

Hda: DOS disk
Hdb: new TiVo Drive A
Hdc: TiVo Drive A

Anyway, I couldn’t seem to get around this and so I got the floppy version from hinsdale’s how-to and was able to boot, backup the original TiVo drive to DOS, and restore from DOS to my new TiVo drive. I tested it out in the TiVo and things seemed to be okay. So, I reconfigured the drives and started to do the restore (saving recordings) via the specified command:

Mfsbackup … - /dev/hdc | mfsrestore –s 127 … - /dev/hda /dev/hdb

My config looked like this:

HDA: new TiVo disk A (80GB)
HDB: new TiVo disk B (80GB)
HDC: old TiVo Disk (40GB)

During the copy I got an error saying that:

Unable to handle kernel paging request at virtual address …

The error can be seen here: image (http://home.xnet.com/~kae/images/TiVo/error.jpg)

It put out one of these errors, but it’s still copying and seems to not care that this paging request failed.

Should I be concerned about this or do something about it?

Thanks for any help anyone can give.

I’m wondering if I should go back to the mfstools 2.0 cdrom and try booting with bswap on some of the drives like:

Boot: vmlnodma hdb=bswap hdc=bswap

I’m not sure that’s supported on the mfstools 2.0 cdrom image. Anyone know?

[ThreeSoFar]

bump

[klobbermeister]

Hey all,

I wasn't sure where to post, but this seemed like as good a place as any.

A bit of background on my situation first: I have a Samsung 4040 (S2 RID unit) which I was upgrading using the Hinsdale guide and PTVUpgrade's lba48 boot disk (despite all the contra-indications not to). The DTivo is sporting 3.1.1e. So, I booted from the lba48 disk, used the "backup | restore" pipeline as per Hinsdale to transfer all my saved recordings to a 200 GB Seagate, and put the new drive back in the DTivo to test it. It showed 177 hours of recording time, which seemed appropriate for the size of the drive....

However, after doing a bit more reading on my next steps, I kept stumbling across the idea that you shouldn't use an lba48-aware boot disk if you aren't going to have an lba48-aware Tivo kernel. Now, according to all of the PTVUpgrade caveats, my SR4040 is not native lba48, yet it recognized a drive >137. Why? I didn't (knowingly) swap in an lba48 kernel. Did the process automatically swap in a hacked kernel? Is the 3.1.1x kernel that I had in the 4040 DTivo somehow automatically aware of lba48? I was reading "somewhere" that the 3.1.1c kernel is just a variant of 2.4.4, which to my understanding, supports lba48. Or am I understanding that incorrectly?

Alternately, will the problems with what I've done come later, when the HDD is starting to fill up (r/w issues?), rather than "seeing" 177 hours worth of HDD?


Any clarification from those "in the know" would be appreciated.

Atis

[tivoupgrade]

Hey all,

I wasn't sure where to post, but this seemed like as good a place as any.

A bit of background on my situation first: I have a Samsung 4040 (S2 RID unit) which I was upgrading using the Hinsdale guide and PTVUpgrade's lba48 boot disk (despite all the contra-indications not to). The DTivo is sporting 3.1.1e. So, I booted from the lba48 disk, used the "backup | restore" pipeline as per Hinsdale to transfer all my saved recordings to a 200 GB Seagate, and put the new drive back in the DTivo to test it. It showed 177 hours of recording time, which seemed appropriate for the size of the drive....

However, after doing a bit more reading on my next steps, I kept stumbling across the idea that you shouldn't use an lba48-aware boot disk if you aren't going to have an lba48-aware Tivo kernel. Now, according to all of the PTVUpgrade caveats, my SR4040 is not native lba48, yet it recognized a drive >137. Why? I didn't (knowingly) swap in an lba48 kernel. Did the process automatically swap in a hacked kernel? Is the 3.1.1x kernel that I had in the 4040 DTivo somehow automatically aware of lba48? I was reading "somewhere" that the 3.1.1c kernel is just a variant of 2.4.4, which to my understanding, supports lba48. Or am I understanding that incorrectly?

Alternately, will the problems with what I've done come later, when the HDD is starting to fill up (r/w issues?), rather than "seeing" 177 hours worth of HDD?


Any clarification from those "in the know" would be appreciated.

Atis


The point of avoiding using an LBA48 boot CD on a unit running 3.1.1 is that the software running on the TIVO does not have an LBA48-aware kernel. Just because the system information screen is reporting the "correct" number of hours, doesn't mean the operating system kernel is going to address the space beyond 137GB without barfing.

If you want to run 3.1.1e on a drive using more than 137GB, it can certainly be done using our tools. Obviously, the popular guides aren't going to mention this because they are written by our competitors.

The other alternative is to wait for your Samsung to upgrade to 6.2 which DOES contain an LBA48 kernel, then upgrade the drive and use the additional space...

[klobbermeister]

So, the kernel that's in the kernel partition "post-pipe" is *not* lba48 aware, despite the upgrade process physically pushing the drive out to 177 hours, correct?

Then, practically speaking, I'd need to switch out the 3.1.1x kernel that's in the active kernel partition with one that's lba48 aware, so it doesn't 'barf' past the 137Gb limit? That or just use the 4.x+RID instructions (modified, of course) to monte into an lba48 kernel.

Thanks for the response.

[ThreeSoFar]

bump

[Hp_serverdude]

Ok guys i am new to this board and forgive me if i ask a few dumb questions. I have read and read and i keep reading. I printed out the new Hinsdale guide and this will be my first attempt at upgrading a TIVO. I have 2 a Samsung SIR-4080R and a Hughs Series 2 70 gig ( cant remember the model number). here are my questions:

1) What speed drive should i buy? 5400 rpm or 7200 rpm and why please?

2) I am very limited in my linux experiance. what do i need to know?

3) What software do i need to get started on all of this and where do i get it?

4) What is the largest drive i can use?

5) what is the best Direct TV Tivo reciever to use?

6) What do i gain and loose from the upgrade?

Please advise.

Thanks

[Hp_serverdude]

Bump anyone please>?

THanks

[Dkerr24]

Hp_serverdude:

1) any rpm is fine. Won't make any difference in a DTivo unit.

2) no linux experience necessary; just read and follow the guide instructions you printed.

3) read the stickys above in this forum.

4) 137gb is the largest drive a Series 2 DTivo can 'see'. The new R10 can see up to 300gb.

5) There is no 'best' receiver. All DTivos use same parts (with exception of hard drive manufacturers).

6) You have only more recording time to gain. No loss of any functionality at all.

[Hp_serverdude]

What is the new R10? Where can i get this and what are the advantages and disadvantages of this?

Please advise.

Thanks

[Hp_serverdude]

bump please

[ThreeSoFar]

bump

[Hp_serverdude]

Bump again please. What is an R10? Are they any good? should i get one? Please advise.

Thanks

[Maruzo]

Hi, another noobie here. I'm trying to upgrade my samsung dtv tivo 80gb with the 6.2 software to a 250gb harddrive. Please post a step by step for the upgrade procedure if possible.

Much obliged!

Mars

[ThreeSoFar]

That's what the HInsdale HOWTO guide is. Link:

http://www.newreleasesvideo.com/hinsdale-how-to/index9.html

[Maruzo]

Two questions:

1. If i successfully upgraded my samsung's original 80gb with the 6.2 software unto a larger 250gb drive, can i then use the same 80 gb to do another upgrade to another 250gb drive, and then install that 2nd 250gb drive into a philips dvr-708?

I've read somewhere that the motherboards and chipsets on these series 2 directv tivos are all the same regardless of who made these units. Whether samsung or philips all made the same units with the exact same spec.

So can i do the swap successfully? Has anyone tried it?

2. i want to retrieve a maxtor 200gb drive that was installed on my philips dvr-708 and reuse it as a regular winxp boot drive. I'm afraid that only i plug in the maxtor into a regular pc, it'll be locked up and be seen as an 8mb drive.

Is there any steps that i can take to return this maxtor back to it's original state so i can reformat it in ntfs correctly?

Thanks Very Much!

Mars

[JT-KGY]

Tivo go into a rebooting loop after upgrade.

Tivo: Series2 TCD540040 with maxtor 40GB drive
New "B" drive: 300GB seagate

Upgraded using Weaknees and Hinsdale upgrade kit and instructions...

Backed up image from 40GB then restore onto the new 300GB.
Tested with my Series2 and the new 300GB boots up fine.

Then running

(with Tivo drive in Primary master and New 300G drive in Primary Slave)
mfsadd -x /dev/hda /dev/hdb

Following Weaknee's instruction.. jumpered original Tivo drive as Master and
new 300GB as Slave. Placed both drive along with fan mounted on the weaknee's
drive bracket (very nice piece).

Boot up Tivo:

1. Powering Up
2. Almost there...
3. DVR has detected a serious problem... may take 3 hours to fix...
(repeat 1 - 3)

I used mfstool PTVupgrade LBA48 CD v4.01

:(
PLEASE HELP!!

[RaGINaR]

You really don't need to post more than once... Someone will help you.

[azitnay]

Sounds like the TiVo is getting to the Green Screen of Death (GSOD), and then not being able to finish due to a lack of adequate swap space.

First of all, I'd really recommend you stick with the single 300GB drive as your A drive, and don't use the 40GB drive at all. You're not gaining that many hours with the addition of the 40GB drive, and you're opening your TiVo up to twice the chance of a drive failure, not to mention power and heat issues, etc.

That aside, your current upgrade strategy (simply mfsadd'ing the 300GB drive as B) doesn't allow you to add the necessary swap space for 340GB of total drive space. Since you apparently have a valid TiVo backup image somewhere (let's call it /mnt/dos/tivo.bak), assuming the 40GB is still /dev/hda and the 300GB is still /dev/hdb, you can do:

mfsrestore -s 170 -xzpi /mnt/dos/tivo.bak /dev/hdb /dev/hda

After that, since the 170 above is greater than 127, you'll need to use tpip to fix the swap header. I don't know the command line for this offhand, but you can do a search.

Lastly, remember that your 300GB drive must now be jumpered as master and the 40GB drive as slave once they're back in the TiVo.

Drew

[jdr93]

Sounds like the TiVo is getting to the Green Screen of Death (GSOD), -snip-

Lastly, remember that your 300GB drive must now be jumpered as master and the 40GB drive as slave once they're back in the TiVo.

Drew
i didn't understand what happened there. it seems you first made the new 300g drive the master by copying the entire contents of the original drive to it, then put the old drive in as the master and jumpered the new drive as the slave.

john

[azitnay]

It sounded more to me like he made a backup image, tested it as is recommended on his new drive, and then mfsadd'ed his new drive to the old drive as drive B. Certainly a valid upgrade plan, but lacking the swap addition that appears necessary in this case.

Drew

[JT-KGY]

It sounded more to me like he made a backup image, tested it as is recommended on his new drive, and then mfsadd'ed his new drive to the old drive as drive B. Certainly a valid upgrade plan, but lacking the swap addition that appears necessary in this case.

Drew


Drew is exactly right... and I learned it the hard way as according to hinsdale
instruction... adding swap at that stage is only recommended.. but not necessary.

Here what I end up doing... had to give up all the previous recording though.
showthread.php?t=268473

[mhaithaca]

Thanks to the Hinsdale instructions and the appropriate PTVUpgrade CD with MFSTools, I've just successfully upgraded my HUMAX 80-hour DVD Recorder TiVo to 372 hours!

I replaced the buit-in 80GB Seagate drive with a 320GB Western Digital Caviar drive from newegg that I got last week for $122. As always, newegg was a pleasure to deal with.

Luckily, I had a friend who'd upgraded her own TiVo in the past come to help, because while I have a Windows box, and am comfortable inside computers, I really haven't had to deal with "primary" and "master" and "slave" and such distinctions in years. I'm a Mac guy. :-) She helped me figure out a minor change to one of the necessary command lines.

A tip... if you put your TiVo into standby mode before unplugging it at the beginning of process, it's going to go BACK into standby mode after it boots up following the upgrade! After that "Almost there..." screen, having the TiVo go black was disconcerting. Took a moment to remember that I had told it to go to sleep. It was just remembering what I told it to do! Pressing the TiVo button woke it up.

The only other oddity? One of the four torx screws holding the drive bracket into the TiVo was a T8 screw, when all of the others on the drive, bracket, and outer case were T10 screws!

My thanks to Hinsdale and Tiger and anyone else involved in providing these helpful instructions! I'll be donating to the ELF Foundation as suggested.

I decided to do this not only because the 80-hour capacity was cramping my style, but also because the resulting default recording quality of Medium was feeling inadequate sometimes. It was going to be especially inadequte if I should ever splurge on an HDTV. My top-notch DISH Network standard-definition signal wouldn't look TOO bad on an HDTV via S-Video, but the extra round of compression in the TiVo would make it look lousy unless I plan on using Best quality.

Of course, what I really want is an HD-capable TiVo and HD content from DISH Network, but I know I can't have either just yet.

P.S. My post included useful links to the relevant resources, but apparently I'm not allowed to do that, as a precaution against spam. What a sad world.

[ThreeSoFar]

Thanks to the Hinsdale instructions and the appropriate PTVUpgrade CD with MFSTools, I've just successfully upgraded my HUMAX 80-hour DVD Recorder TiVo to 372 hours!

I replaced the buit-in 80GB Seagate drive with a 320GB Western Digital Caviar drive from newegg that I got last week for $122. As always, newegg was a pleasure to deal with.

Luckily, I had a friend who'd upgraded her own TiVo in the past come to help, because while I have a Windows box, and am comfortable inside computers, I really haven't had to deal with "primary" and "master" and "slave" and such distinctions in years. I'm a Mac guy. :-) She helped me figure out a minor change to one of the necessary command lines.

A tip... if you put your TiVo into standby mode before unplugging it at the beginning of process, it's going to go BACK into standby mode after it boots up following the upgrade! After that "Almost there..." screen, having the TiVo go black was disconcerting. Took a moment to remember that I had told it to go to sleep. It was just remembering what I told it to do! Pressing the TiVo button woke it up.

The only other oddity? One of the four torx screws holding the drive bracket into the TiVo was a T8 screw, when all of the others on the drive, bracket, and outer case were T10 screws!

My thanks to Hinsdale and Tiger and anyone else involved in providing these helpful instructions! I'll be donating to the ELF Foundation as suggested.

I decided to do this not only because the 80-hour capacity was cramping my style, but also because the resulting default recording quality of Medium was feeling inadequate sometimes. It was going to be especially inadequte if I should ever splurge on an HDTV. My top-notch DISH Network standard-definition signal wouldn't look TOO bad on an HDTV via S-Video, but the extra round of compression in the TiVo would make it look lousy unless I plan on using Best quality.

Of course, what I really want is an HD-capable TiVo and HD content from DISH Network, but I know I can't have either just yet.

P.S. My post included useful links to the relevant resources, but apparently I'm not allowed to do that, as a precaution against spam. What a sad world.
Grats.

What swap space did you use? more than -s127 I hope?

If not, you may want to redo it with -s250. After the mfsrestore is done, it then requires tpip -s --swapped /dev/hdX to initialize that swap properly.

[tivoupgrade]

Grats.

What swap space did you use? more than -s127 I hope?

If not, you may want to redo it with -s250. After the mfsrestore is done, it then requires tpip -s --swapped /dev/hdX to initialize that swap properly.

I wouldn't be so sure about that... In addition to the limited upside of even having a large swap file, I'm pretty sure sure the current TiVo kernels will barf when trying to intitialize their swap if its larger than 127MB.

Its my theory that many people have been attempting to create large swap files, and may actually running with NO swap at all.

A good way to verify this is by looking in your kernel log file for something like this:

Jan 2 00:00:43 (none) kernel: Activating swap partitions
Jan 2 00:00:43 (none) kernel: Unable to handle swap header version 16777216
Jan 2 00:00:43 (none) kernel: swapon: /dev/hda8: Invalid argument


If you don't have a networked unit, just mount your TiVo drive and look on partition /dev/hdX9 in the /log/kernel file.

[ThreeSoFar]

I wouldn't be so sure about that... In addition to the limited upside of even having a large swap file, I'm pretty sure sure the current TiVo kernels will barf when trying to intitialize their swap if its larger than 127MB.

Its my theory that many people have been attempting to create large swap files, and may actually running with NO swap at all.

A good way to verify this is by looking in your kernel log file for something like this:

Jan 2 00:00:43 (none) kernel: Activating swap partitions
Jan 2 00:00:43 (none) kernel: Unable to handle swap header version 16777216
Jan 2 00:00:43 (none) kernel: swapon: /dev/hda8: Invalid argument


If you don't have a networked unit, just mount your TiVo drive and look on partition /dev/hdX9 in the /log/kernel file.
The tpip takes care of that. It's not the TiVo kernel that has a problem, it's the mfsrestore tool itself.

I would like to see someone with an S2 done in this manner confirm this, though. I don't do kernel/Linux crap on my TiVos, just upgrades in size.

[ThreeSoFar]

The tpip takes care of that. It's not the TiVo kernel that has a problem, it's the mfsrestore tool itself.

I would like to see someone with an S2 done in this manner confirm this, though. I don't do kernel/Linux crap on my TiVos, just upgrades in size.
Oh, and btw, I have noticed improvements. Menus a bit faster, and the Humax DRT800 hasn't seized up since I did it. I suppose there's a chance that's from the new drive in it rather than the larger swap.

[azitnay]

Simply put, swap partitions smaller than 128MB use a version 0 swap header, which MFS Tools 2.0 has no problem with. Swap partitions 128MB or larger require a version 1 swap header. MFS Tools 2.0 supports this according to the code, but there's a bug somewhere. tpip knows how to correctly generate the version 1 swap header.

Drew

[tivoupgrade]

My experience has been that the latest TiVo kernels barf on swap partitions created with mfstools and initialized with tpip 1.1 and tpip 1.2.

ThreeSoFar - there is a difference between initializing the swap file and writing a header (initializing) to the swap partition; the former is what I'm talking about, and the error I posted is one that was generated by a system booting with a large, tpip-initialized swap partition.

I have not done an intensive investigation of this (I've only tested this on a Mandrake system and not even on my own boot CD, which might make a difference) for the following reason:

The only benefit of having a larger swap space is allowing systems with freakishly large drives to potentially recover from the Green Screen of Death (GSOD). A GSOD can be invoked in one of several ways - by manually typing "mfsassert -please", or through filesystem corruption. In the case of the latter, filesystem corruption is a 'symptom' not a problem - the underlying problem is typically a failing hard drive. That means the problem will happen again, probably very soon.

So, the summary is this, larger swap will allow you to recover (temporarily) from a GSOD in certain situations. At best, it buys you some time. Time for what? Time to do a dd_rescue, which will not always succeed either.

For everyone out there who is considering going with a larger swap, we recommend you fully understand these issues - there is minimal upside (there is absolutely NO benefit to performance) and there is potential downside; mainly, you could end up with NO swap (and that will affect performance) or you could end up with the false notion that all is OK, when its not.

I should also mention that in 5+ years of shipping upgrade kits, 4+ of them offering drive sizes larger than what 'fsfix' should be able to successfully repair in the case of a GSOD, we have NEVER received a drive back from a customer that went into a GSOD that was NOT defective. So basically, you are not going to get GSOD's unless you have a defective drive (at least not with normal usage) and unless you plan on using dd_rescue, its just not going to matter...

-----

In any case, my current tests on an HUMAX T800 reveal that the following:

mfstool restore -x -s 250 -r4 -zi TiVo.bak /dev/hdc

followed by use of tpip 1.2 running on Mandrake:

tpip -s --series2 /dev/hdc

Will result in an unbootable system, and the following errors in your kernel log file:


Jan 2 00:00:43 (none) kernel: Activating swap partitions
Jan 2 00:00:43 (none) kernel: Unable to handle swap header version 16777216
Jan 2 00:00:43 (none) kernel: swapon: /dev/hda8: Invalid argument


Using

mfstool restore -x -s 127 -r4 -zi TiVo.bak /dev/hdc

you will get this, instead:


Jan 2 00:00:55 (none) kernel: Activating swap partitions
Jan 2 00:00:55 (none) kernel: Adding Swap: 130044k swap-space (priority -1)


Its my opinion (and I annually post on this issue) that your time would be better spent running advanced diagnostics, and LOW-LEVEL formats of drives, even intensive burn in, prior to installing them in your TiVo, rather then messing with swap.

If I have more time, I will run some more tests, but again, I really do view the whole swap discussion as a bit nitpicky more than anything else; it really isn't something folks should be concerned about.

Please let me know if anyone is observing anything different here, perhaps I've overlooked something; the tests I've run are not exhaustive, and as an Engineer, I am always reticent to post assessments without empirical results.

[JamieP]

tpip -s --series2 /dev/hdctpip has a bug in it that causes it to get the byte order wrong in the v1 swap header on series 2 units. The solution is to lie to it and claim that you have a byte swapped S1 unit. Details here (http://www.tivocommunity.com/tivo-vb/showthread.php?p=3085168&&#post3085168). I've reported this to the tpip author.

In general, I agree with your point of view. If you really know what you are doing, running with a large enough swap to get through a GSOD is probably a good thing, although I suppose this is arguable. Otherwise, you're better off sticking with 127MB of swap and hoping that a GSOD never happens. If it does happen, there's a good chance you have a bad disk and will lose everything anyway.

For those that do choose to run with a larger swap initialized with tpip, I highly recommend that you check the logs to be sure the swap is correctly initialized and is being used. Instructions are in the thread I referenced above.

[tivoupgrade]

Ah, cool. Thx for that link Jamie.

tpip -s -1 /dev/hdc

and the log file now shows success:


Jan 2 00:00:55 (none) kernel: Activating swap partitions
Jan 2 00:00:55 (none) kernel: Adding Swap: 255992k swap-space (priority -1)

[ThreeSoFar]

How much RAM on an S2 these days, anyway?

Maybe the assumption I'm basing this on is wrong. I am assuming that for things memory intensive (rearranging lists, for example), more memory is better than less.

In any unix system I've used, swap space effectively increases the amount of memory your system has.

Is GSOD truly the only time swap is important or used? I am skeptical about that. I don't mean critical (it will fail without enough), I just mean "good", meaning better with (more) than without.


My experience has been that the latest TiVo kernels barf on swap partitions created with mfstools and initialized with tpip 1.1 and tpip 1.2.

ThreeSoFar - there is a difference between initializing the swap file and writing a header (initializing) to the swap partition; the former is what I'm talking about, and the error I posted is one that was generated by a system booting with a large, tpip-initialized swap partition.

I have not done an intensive investigation of this (I've only tested this on a Mandrake system and not even on my own boot CD, which might make a difference) for the following reason:

The only benefit of having a larger swap space is allowing systems with freakishly large drives to potentially recover from the Green Screen of Death (GSOD). A GSOD can be invoked in one of several ways - by manually typing "mfsassert -please", or through filesystem corruption. In the case of the latter, filesystem corruption is a 'symptom' not a problem - the underlying problem is typically a failing hard drive. That means the problem will happen again, probably very soon.

So, the summary is this, larger swap will allow you to recover (temporarily) from a GSOD in certain situations. At best, it buys you some time. Time for what? Time to do a dd_rescue, which will not always succeed either.

For everyone out there who is considering going with a larger swap, we recommend you fully understand these issues - there is minimal upside (there is absolutely NO benefit to performance) and there is potential downside; mainly, you could end up with NO swap (and that will affect performance) or you could end up with the false notion that all is OK, when its not.

I should also mention that in 5+ years of shipping upgrade kits, 4+ of them offering drive sizes larger than what 'fsfix' should be able to successfully repair in the case of a GSOD, we have NEVER received a drive back from a customer that went into a GSOD that was NOT defective. So basically, you are not going to get GSOD's unless you have a defective drive (at least not with normal usage) and unless you plan on using dd_rescue, its just not going to matter...

-----

In any case, my current tests on an HUMAX T800 reveal that the following:

mfstool restore -x -s 250 -r4 -zi TiVo.bak /dev/hdc

followed by use of tpip 1.2 running on Mandrake:

tpip -s --series2 /dev/hdc

Will result in an unbootable system, and the following errors in your kernel log file:


Jan 2 00:00:43 (none) kernel: Activating swap partitions
Jan 2 00:00:43 (none) kernel: Unable to handle swap header version 16777216
Jan 2 00:00:43 (none) kernel: swapon: /dev/hda8: Invalid argument


Using

mfstool restore -x -s 127 -r4 -zi TiVo.bak /dev/hdc

you will get this, instead:


Jan 2 00:00:55 (none) kernel: Activating swap partitions
Jan 2 00:00:55 (none) kernel: Adding Swap: 130044k swap-space (priority -1)


Its my opinion (and I annually post on this issue) that your time would be better spent running advanced diagnostics, and LOW-LEVEL formats of drives, even intensive burn in, prior to installing them in your TiVo, rather then messing with swap.

If I have more time, I will run some more tests, but again, I really do view the whole swap discussion as a bit nitpicky more than anything else; it really isn't something folks should be concerned about.

Please let me know if anyone is observing anything different here, perhaps I've overlooked something; the tests I've run are not exhaustive, and as an Engineer, I am always reticent to post assessments without empirical results.

[JamieP]

How much RAM on an S2 these days, anyway?SA: 32MB;
DTiVo: 64MB;
HDTiVo: 128MB? (not sure about this)Maybe the assumption I'm basing this on is wrong. I am assuming that for things memory intensive (rearranging lists, for example), more memory is better than less.That's a valid assumption, as long as the processes that are maintaining these data structures use all the available memory.

The Tivo processes don't adjust their memory use to available physical memory or swap, as far as I have observed. As long as you have sufficient swap to cover the largest memory demand you will ever see, adding more swap generally won't help. Too little swap, and you run the risk of having processes run out of memory (e.g. "new" or "malloc" fail, or a "fork" fails to create a new process). In any unix system I've used, swap space effectively increases the amount of memory your system has.More physical memory usually helps unix/linux systems. Any extra memory not needed for processes goes to the disk buffer cache, which tends to speed up disk access. I suppose it is possible that a larger swap allocation might allow more of the idle processes to be swapped out, freeing physical memory for the buffer cache.Is GSOD truly the only time swap is important or used? I am skeptical about that. I don't mean critical (it will fail without enough), I just mean "good", meaning better with (more) than without.In my experience, a SA running 7.x can't run without swap. Processes die (the aforementioned new/malloc/fork failures) and the box won't even boot fully up. A DTiVo running 6.x does seem to be able to come up with no swap, but there are still process failures and it's not really running right.

On a hacked tivo, you can watch /proc/swaps or /proc/meminfo to see how much swap is being used.

I just took a quick look at my tivos: model 240; 320GB (dual drive): using 30MB of swap model 264; 320GB: using 34MB of swap model 240; 250GB: using 23MB/swap model 540; 200GB: using 24MB of swap

[ThreeSoFar]

In my experience, a SA running 7.x can't run without swap.
Ah, then if that's solid, my -s250 with tpip must have at least given me non-zero swap.

[JamieP]

Ah, then if that's solid, my -s250 with tpip must have at least given me non-zero swap.Probably, if you used the right flags with tpip as described here (http://www.tivocommunity.com/tivo-vb/showthread.php?p=3085168&&#post3085168).

[tivoupgrade]

How much RAM on an S2 these days, anyway?

Maybe the assumption I'm basing this on is wrong. I am assuming that for things memory intensive (rearranging lists, for example), more memory is better than less.

In any unix system I've used, swap space effectively increases the amount of memory your system has.

Is GSOD truly the only time swap is important or used? I am skeptical about that. I don't mean critical (it will fail without enough), I just mean "good", meaning better with (more) than without.

I think 32MB, but don't quote me on that.

More memory is better than less when an application's working set requires more physical memory than exists. That is where swap comes in, it serves as an extension of memory so that the OS can 'swap' unused portions of memory to disk when data that needs to be address must be accessed. Anything that 'swaps' will suffer performance; that is the nature of virtual memory systems.

Swap is definitely important and needed as some applications will need more memory at times than at others, swap serves as a place for some of that information to overflow. More is not necessarily better, though. Conventional UNIX systems are generally configured with swap space allocated to 2 to 3 times that of physical memory.

In general, nothing is really going to be slower than when the system needs to read or write to disk (that is why CacheCards are so effective on Series1 units); so a larger swap is really not going to be better than a smaller one, unless the application actually requires more memory than exists in the system, plus what is available to swap. That is when fsfix will 'break' and not allow a system to recover from a GSOD. So again, that is where the notion of 'its not that important' comes from -- other than the GSOD, a larger swap really yields no benefit. And a GSOD is indicative of another problem that recovery will to little to mitigate...

[tecumuman]

I have the Hughes HR 10-250. The current software version on the drive is 3.1.5f-01-2-357. I have successfullly been able to make a back up of the drive, so everything is being done on a new drive.

When I attempt to run killhdinitrd on the drive I get the message "invalid kernel version". Is there a different version of killhdinitrd that I need to download in order get this to work?

Thanks in advance!

[Dan Collins]

SA: 32MB;
DTiVo: 64MB;
HDTiVo: 132MB? (not sure about this)

I get the following meminfo on my Series2 DirecTiVos:
Kitchen TiVo #cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 44937216 42012672 2924544 0 2228224 27201536
Swap: 133165056 14819328 118345728
MemTotal: 43884 kB
MemFree: 2856 kB
MemShared: 0 kB
Buffers: 2176 kB
Cached: 24332 kB
SwapCached: 2232 kB
Active: 18396 kB
Inactive: 12856 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 43884 kB
LowFree: 2856 kB
SwapTotal: 130044 kB
SwapFree: 115572 kB
Kitchen TiVo #
Which would seem to indicate considerably less than 64MB of RAM - more like 42MB.

[JamieP]

Which would seem to indicate considerably less than 64MB of RAM - more like 42MB.There is 64MB of memory installed, but some of it is reserved for other devices and is not available to the kernel. Same is true of SA's, that typically have about 24MB available to the kernel, out of the 32MB installed.

[Dan Collins]

I figured there was some reserved RAM (I would have been surprised by a 42MB system, I figured it was actually 48MB). 18MB seems pretty intense, versus 8MB for standalones. Any idea what DirecTiVos are doing with this extra 10MB?

[JamieP]

I figured there was some reserved RAM (I would have been surprised by a 42MB system, I figured it was actually 48MB). 18MB seems pretty intense, versus 8MB for standalones. Any idea what DirecTiVos are doing with this extra 10MB?I'm not all that familiar with dtivo hardware as I have only SA tivo's. If you grab the kernel source form www.tivo.com/linux, you'll see some interesting things in include/linux/tivoconfig-init.h. Here's a couple of excerpts:#define BCM_UMA_DTV_MEM \
{ kTivoConfigMemSize, 0x04000000 }, /* 64 MB */ \
{ kTivoConfigContigmemRegion1, 0x00800000 }, /* 8.0MB */\
{ kTivoConfigContigmemRegion2, 0x00100000 }, /* 1.0MB */\
{ kTivoConfigContigmemRegion8, 0x00a00000 }, /*10.0MB */

#define BCM_UMA_SA_MEM \
{ kTivoConfigMemSize, 0x02000000 }, /* 32 MB */ \
{ kTivoConfigContigmemRegion1, 0x00100000 }, /* 1.0MB */\
{ kTivoConfigContigmemRegion2, 0x00080000 }, /* 512KB */\
{ kTivoConfigContigmemRegion8, 0x00580000 }, /* 5.5MB */

#define BCM_UMA_HD_DTV_MEM \
{ kTivoConfigMemSize, 0x08000000 }, /* 128 MB */ \
{ kTivoConfigContigmemRegion1, 0x00C00000 }, /*12.0MB */\
{ kTivoConfigContigmemRegion2, 0x00200000 }, /* 2.0MB */\
{ kTivoConfigContigmemRegion8, 0x01600000 }, /*22.0MB */
I believe this tells us how much physical memory is present on each platform, and how much is reserved in contiguous memory regions, presumably for some of the other hardware devices (e.g. graphics chips, etc). Some of the physical memory is also tied up for the kernel code itself, and is not included in the meminfo output.

If you examine /var/log/messages right after a boot, you should find something like this:
kernel: Memory: 22156k/32768k available (1222k kernel code, 10612k reserved, 81k data, 64k init, 0k highmem) which also tells you you much memory is used by the kernel code and data, and how much is reserved and not available to the kernel.

Guess we've ventured pretty far off topic now.

[burby]

Hi Guys....I to am getting the dreaded GSOD. I am a TiVo newb so be easy on me. I have already researched for many hours but nothing is making much sense to me at this point. Below is my setup and what steps I did....

I have the TiVo 40hr TCD540040.

I am trying to install a Western Digital 320gb HD as an upgraded A drive.

I followed these steps....

- mkdir /mnt/dos
- mount /dev/hda1 /mnt/dos
- mfsbackup -f 9999 -6so /mnt/dos/tivo.bak /dev/hdc
- mfsrestore -s 127 -bzpi /mnt/dos/tivo.bak /dev/hdb (also tried 170 the second time as per another users suggestion)
- Tested new upgrade drive in TiVo and worked but only reconized 40 hours
- mfsadd -x /dev/hdc /dev/hdb
- Put in TiVo....get powering up screen and then GSOD.

I since have done a low level format on the new 320gb drive and repeated steps but get the same exact results. I am possitive that all my jumpers, etc are correct as I work with PCs daily. Anyone have any ideas or suggestions for me? HELP?!?

Thanks in advance...

-Brian

[burby]

Actually, I decided to browse over to the weaknees website and I found some valuable info that made my unit work. FINALLY!

Only thing I did different was....

mfsrestore -s 127 -r 4 -zxpi /mnt/backup.bak /dev/hdb

Anyone care to explain what the difference was from what I was initially doing? I was first using the hinsdale write up, but I guess that wasn't completely up to date. Anywho, it is working now and I'm a happy camper.

It says that I now have 316 hours of recording time....but thats only 100 or so at best. Anyone recomend adding a second large drive? I was thinking about maybe adding another 200 or 300gb as a B drive. Any downsides to doing this? Any problems I may run into?

Thanks.

-Brian

[ThreeSoFar]

Here's your problem. /dev/hdb should be the only argument to this command:

mfsadd -x /dev/hdc /dev/hdb
Assuming, anyway, that you are only replacing the single drive not upgrading to two drives.

[geishaslave]

Upgrade Series 2 80 Hour to 140 Hour

Hello everyone.

Apologies in advance if similar information has been posted earlier.

Just wanted to share my experience with the procedures and files posted at

http://www.newreleasesvideo.com/hinsdale-how-to/index9.html

I was able to successfully change from an 80GB Maxtor hard disk drive to a 120GB Western Digital (WDC).

My task varied a bit from the published steps since I did not want to first make the Tivo back up image.

Here are the basic steps I followed:

1) Cloned entire 80GB Maxtor to 120GB WDC drive using MFS Tools/Linux. This took over 10 hours!

2) Placed 120GB WDC into the Series 2 Tivo and was able to boot up no problems. System info reported max 140 hour recording capacity.

3) Using Disk Management/Windows XP, created 10GB FAT32 partition on the 80GB Maxtor.

4) Using MFS Tools/Linux, backed up 120GB WDC to 80GB Maxtor, creating the tivo.bak image.

5) Burned tivo.bak to CD-R for archival purpose.

I could have first created a FAT32 partition on the WDC drive, backed up the original Maxtor disk, burned the CD-R, then cloned from the 80GB-->120GB.

No difference in amount of effort/time committment. I was worried about the Maxtor failing, and I knew my spouse would want the recordings and settings preserved, thus the reason I did the clone first.

Thanks for this opportunity to share my joy :-)

Details:

Tivo Series 2 model TCD24008A

OS version 7.2.2b-oth-01-2-140

[mademan]

Hello,

If you need ever to burn ISO to disc I propose you try out ISO-burner tool. This tool is free and never failed me before. Moreover, it is extremely easy to use
ntfs,com/iso-burning,htm

[timckelley]

Hello,

If you need ever to burn ISO to disc I propose you try out ISO-burner tool. This tool is free and never failed me before. Moreover, it is extremely easy to use
ntfs,com/iso-burning,htm

That could have saved me a lot of time during my last upgrade. Getting ISO to burn to disk was my big sticking point, and I went through practically a dozen CDs using different softwares and reading various newsgroups, and posting here, trying to get it to work.

[ThreeSoFar]

Samsung 500G SATA drives (for S3 upgrades) are just $149 at newegg.com, free shipping.

[spudly]

[Sorry that this is a duplicate post as I started a new thread with the situation. I'd still appreciate any answers within this thread!]

Hello,

Here is my situation: Have a Series I Dtvio (Philips DSR6000) from 2001 which I had expanded to 108 hours with second 80GB HD + original 40GB HD way back when. It's been acting flaky the last couple months and afraid one of the hard drives are gonna kick. This was purchased w/CC 5 yr warranty and a call to DTV they actually sent me a replacement unit and was told to "throw away" (hah!) the old one. So they sent me an R10 (series II).

So far so good (until I realized that this couldn't be hacked for TiVo Web, but I digress). I have a 300GB HD I'd like to replace (and remove the original 80 GB) in the R10 which I am confident I can do as the tools have only gotten easier in the past couple of years, but here's the rub..... is there anyway I can copy/move my recordings and season passes from the DSR6000 (series I) that I will retire?

Initially I thought I could just do the "Replace 2 HD w/Signle HD option" but then it ocurred to me that the software would likely be overwritten with the ancient series I on the series II unit.

Any help/suggestions?

TIA!
Glenn

[zewone]

I could use some help. I have a series 2 DirecTivo (RCA DVR39). I was upgrading the set by adding a second drive (80GB Maxtor). I had everything going well until it came to putting the drives back in the unit. I'm using a Twinbreeze and the IDE cable I have would not reach from the motherboard, to both units.

So, I tried something. I saw that there was a blue end on the IDE cable. It looks like this is suppose to be the end connected to the motherboard, but I would be able to connect everything if I connected the blue end to drive B. So, I did. I closed the unit and plugged it in. It was stuck at the "powering up" screen. I figured my idea didn't work and I would need a longer IDE cable.

I wanted to make sure my unit was still working, so I plugged in drive A by itself and put the blue end of the cable back into the motherboard. Boot it up, gets past the "powering up" screen, gets the "almost done" screen then it reboots. I'm worried that I screwed something up. Also, my remote wouldn't respond on the unit. I made sure to be careful about the white ribbon connected to the front, I hope that's not the problem.

If anyone can give me some reassurance that everything will be fine, it would mean a lot to me. :)

Sorry for the long post. I hope it's legible, I'm very tired.

[Downloaderuk]

Yes, he does cover the UK TiVo (it's virtually identical to the US Series 1 stand alone TiVo, the only difference is the -l 32 for the backup).

See http://www.steveconrad.co.uk/tivo/ for details of several common upgrades done on a UK TiVo. With pix!

This is a great site for Tivo upgrades. Thanks for the link.

DownloaderUK

[aladdin]

Help with HR10-250? I've tried every bootable MFStools and PTVUpgraded Linux tools cd, but everytime I try to backup my current drive (I even did a clear and delete all to see if that would help) and use the command: mfsbackup -f 9999 -6so /mnt/dos/hr10.bak it goes about 38mb and then stops and never moves again. I also found an image and downloaded, and have tried restoring it to my new 500GB WD drive using: mfsrestore -s 300 -bxzpi /mnt/dos/hr205.bak /dev/hdb and similar problem... after a couple mb, it just hangs. Any help here? What am I doing wrong? I'm using the 3.01 CD with the Kernel48 on it... also tried mfstools 2.01 but doesn't work either. My primary drive is dying, so I really need to get it copied to a new drive before it stops working completely... please msg me if you can help, I would really appreciate it.

[swob111]

I have a quick question. My hard drive died, so I want to know if it is possible to take a completely blank drive, and make it usable for my series 2 single drive. I don't know if the instructions will work because I am not upgrading, I am starting all over.

[timckelley]

Yes, that will work. You're doing a replace instead of an upgrade, and there are replacement instructions available for you to work from.

[ThreeSoFar]

Yes, that will work. You're doing a replace instead of an upgrade, and there are replacement instructions available for you to work from.

You will need a source image to recover from. Some individuals have them archived from past upgrades. Also available for a fee, IIRC.

[azitnay]

And if you post your model number here, you might just get a helpful PM or two :).

Drew

[Newbie]

Where can I download a test tivo.bak file I can mfsrestore to a new drive so I can see if the new drive works in the tivo? I just need it to boot beyond the initial "tivo is starting up" screen.

I have a philips series 1 dvr 312 although it has been upgraded to 2 drives so it's more like a 612.

My drive upgrade attempt has not worked, so I'm trying to narrow down the problem, starting with the new drive and the PC used to perform the mfsrestore procedure.

[gfreeman]

Hi all. As a Canadian with a Series 2 TiVo, I was wondering what I need to do in order to increase the space for recordings to the maximum I could possibly get.

Thanks in advance for any suggestions!

G

[wilhouse]

reduce the recording quality to as low as you can stand it.

wilhouse

[gfreeman]

Ah yes, thanks. Already at the lowest quality. I found an excellent page describing how to install a larger drive, which I shall try out as soon as I have a spare day to devote to it.

[wilhouse]

also see http://www.weaknees.com/

and

http://www.tvrevo.com/index.php

for people who would be happy to do it for you.

wilhouse

[bpl323]

I'm getting a Tivo HD and would like to upgrade the HDD. I'm on a Mac and can't seem to find any guide to do it (or any guide that is new enough to support the HD on Windows). Any help would be awesome!

[wilhouse]

ok, Tivo has actually made it easy for you.

Buy a DVR expander. I have two of them (one for each of my two Tivo HD's).

I got mine from Best Buy

http://www.bestbuy.com/site/olspage.jsp?_dyncharset=ISO-8859-1&_dynSessConf=1934228616010760249&id=pcat17071&type=page&st=my+dvr+expander&sc=Global&cp=1&nrp=15&sp=&qp=&list=n&iht=y&usc=All+Categories&ks=960

Tivo sells a 1TB unit. You won't need any more space after you buy that one.

http://www.tivo.com/dvr-products/tivo-accessories/extra-dvr-storage/index.html

It's simple to install. Just turn off the tivo, plug the unit into the tivo and reboot.

wilhouse