Does the s3/TivoHD really need hacking?

[Roger Dylan]

I have constructed new hacked drives for my (PROM-modified) s3 and TivoHD, but I am gravitating towards leaving the original drives intact. Here's my thinking, and I invite reactions and especially contrasting opinions.

My only hacking interest is the portability of shows, into and out of the Tivos.

The official tivo files, available from unhacked Tivos, give me all the timeshifting flexibility I need: viewing on Tivos in other rooms, storing on networked hard disk, viewing on computer, making DVDs for travel.
- there is a very public infrastructure (Tivo, Roxio, tivodecode, VideoReDo, etc.)
- the DDB tivo developers I know and love come and go
Though I am nearly 10 years into Tivo hacking (mostly DTivo) and luxuriating in the resulting access and flexibility, the notion of keeping abreast of the likely _frequent_ s3/TivoHD system upgrades is daunting. I am getting old and forgetful, and I find the prospect of keeping on top of system upgrades and manipulating slices painful.

Staying with unhacked drives means I can simply allow system upgrades to occur as God and Tivo intended. Required fixes/upgrades of _external_ software will be very public.

30% of my show interest is OTA/cable HiDef. No flags, maybe forever.
65% of my show interest is TCM, FMC (HiDef as soon as my cable company or FIOS or AT&T U-verse make it available), a few other non-premium (but not OTA) cable channels. No flags, at least for now.
5% of my show interest is from flagged premium cable sources, but well-served by NetFlix, RedBox and other sources.

I am very much more comfortable with a hacked Tivo in that the hated crippling of timeshifting is eliminated at the source. OTOH the tivo format is so open that, except for flagged shows, the crippling is of no consequence.

I think it's clear that I'd like to be convinced to switch to my hacked drives (It was not easy to get the damned things done). Everything is unencrypted from moment one; flags will not be a concern moving forward and of course at any moment non-premium (but not OTA) cable channels could be flagged at whim. More network flexibility (but you lose some officially supported networking). TivoWebPlus. Maybe better show title editing. Certainly the DDB-type hacking community will be more creative in pushing the envelope going forward.

Mostly the above has been my devil's advocate thinking out loud, but from what I'm hearing from my local Tivo community, these are issues on a lot of minds that could use exploring. Of course hacking/playing with the Tivos is fun in itself even if becoming not justifiable.

[captain_video]

IIRC, Tivos weren't introduced until around 1999 so 10 years of hacking them may be pushing it a bit. I also doubt very much that God has anything to do with Tivo upgrades. Hacking the S3/Tivo HD models is pretty simple once you have the PROM modded. You have to let them contact the outside world so blocking updates with either model isn't an option.

I've got my two S3's hacked with just the basics (telnet, tivoftpd, Alphawolf's binaries, & no encryption) so rehacking an upgraded OS is no big deal. It's just a matter of pulling the drive, making a backup, copying the kernel, patching it, restoring the patched kernel, and copying over the rc.sysinit.author file along with any hack files from the inactive partition to the active one and I'm done, except for patching the tivoapp file, which I'll do via telnet after reinstalling the drive.

Making the backup image takes longer than the rest of the process. I could probably get away with just copying the hacked kernel from the inactive partition to the active one, but you never know if the kernel has been changed as part of the upgrade so it's better to be safe than sorry.

While it is true that you can now use TTG to extract shows to your PC, the process of transferring the shows is excruciatingly slooooow. Hacking the Tivo for video extraction using the more familiar methods cuts the transfer time down to a fraction of what TTG takes. I find that more than enough justification for hacking the Tivo, even though it has to be redone with each upgrade.

[Roger Dylan]

I rounded off (7 plus years as I look at some old files) to "nearly 10 years of hacking" and thanks for the admonition. Time goes by fast when you're having fun. And even there I'd admit the first year or so largely consisted of just getting a new alternate hard drive up and playing, without much help or useful result.

For the rest: TTG=way slower than normal (hacked) methods. That's relevant. Thanks.

[newbie]

I don't know why a typical user would spend the money, and void their warranty, unless they already made the decision to hack their unit.

I deleted the rest of my posts in this thread.

[Roger Dylan]

I don't know why you took the time and/or spent the money to replace your ROM if you weren't going to hack? ... Updates were a hassle with the original monte configuration. Upgrades should be easy to do in place.

I'm very sorry I've been so unclear. I will try to edit my post because it's obviously confusing.

I _have_ hacked. A new hard drive for the HD and a new one ready to try out on the series 3 soon. Hacking 101 from Al Hodge or anybody else is not being solicited in this thread.

I don't hack original drives, I like to have them intact for a year or two for a new model and ready to plug back in (especially easy since I have for many years (I almost said "nearly 10"!!!!) always mounted my internal tivo hard drives in external removeable cartridges). That's my bias. So I always have the very easy option of switching back & forth between hacked and not. Up until now there was never a reason to go back to unhacked as SOP (in addition to other special-use cartridges I keep on hand). Now I'm tempted, thus the inquiry.

My issue (or more precisely the issue my friends are asking me about about and so I am trying to gather input) is whether to use hacked or unhacked hard drives in s3/HD as SOP. Regardless of day-to-day SOP, the PROM modification allows me to play around and have flexibility, which is why mine are modded and I'm happy with that no matter which way I go.

Your point about incorrect flagging _is_ exactly what we're looking for. Thanks.

To summarize so far, disadvantages of running non-hacked: transfers are much slower, and even non-premium content may get flagged and thus not be accessible.

Sincerely, thanks.

[lrhorer]

I thought your original post was extremely well written and to the point. The fact you stretched 7 or 8 years into 10 doesn't really bother me.

In short, you hit the nail firmly on the head. For myself and many others the issue is somewhat more acute, I believe, because by far most of the shows I record are flagged, and thus I am unable to employ MRV or to move them around in order to manage space. The 2T drive limit on the S3 is a real problem, and all I have is S3 units. I'm fairly soon going to be at the point where there is zero flexible recording space on any of my TiVos.

I do have a question, however. I was of the impression the S3 used the same software upgrade methods as the S1 and S2. Is this not true? Is there no longer an if [$upgradesoftware" = false] trap in rc.sysinit? Is there no longer a bootpage utility or does the OS no longer respect the upgradesoftware=false flag in the bootpage?

[newbie]

please delete, no reason to fight with OP.

[Roger Dylan]

I guess this thread might be of use to to others, that are trying to decide if they want to modify the PROM.

OK, my control-freak desire to keep this conversation focused has disintegrated. As it should be, this forum is very free-wheeling.

OK, to address this particular thread piece unravelling: I totally disagree. Anyone, everyone who has an s3/HD and is smart enough to read this forum should send the thing to Omikron immediately! Figure out the hack/don't hack issue later.

He will hate me for saying this because he's in it for fun and to make a contribution to the hobby, and the last thing he wants is a boatload of tivos to work on, but here we are.

1. He does a better job than 92.74% of would.
2. His fee (covering all material costs) is _very_ reasonable, particularly for just the PROM replacement itself.
3. You immeasurably increase your flexibility moving forward and in no way damage your ability to run simon pure unhacked if that's what you ultimately decide to do.
4. The opportunity to get such superb quality work done at this price is not going to last forever.

Sooner or later this wonderful person is going to get tired of it, tell us all to go to hell, and we're back to the days of back-alley modifications, or self-induced modifications.

This guy decided to drive 30 miles to pick up at the terminal one unit I sent him, to avoid an otherwise two week delay in getting the work done and getting it back to me (a timing issue). With time and gas any profit on this particular transaction was long gone, but he remained nothing but cheerful and friendly as always.

Omikron is a national treasure.

Use his services. Use them now; or regret it later.

[lrhorer]

You have to let them contact the outside world so blocking updates with either model isn't an option.

What does one have to do with the other? On S1 and S2 TiVos at least, blocking the upgrade was merely a matter of setting the bootpage parameters or hacking rc.sysinit to prevent the system from implementing the upgrade automatically. This didn't prevent them from contacting the outside world, by any means. Is this somehow no longer the case (see my previous post)?

so rehacking an upgraded OS is no big deal. It's just a matter of pulling the drive, making a backup, copying the kernel, patching it, restoring the patched kernel, and copying over the rc.sysinit.author file along with any hack files from the inactive partition to the active one

I wouldn't call that "no big deal". First of all, I personally am partially disabled, so even just unplugging all the cables from one of my TiVos and then getting them plugged back in is a modestly difficult and somewhat painful ordeal. Intellectually it's trivial. Physically it is not. Anything which can't be handled - and safely so - from the keyboard is somewhat more than "no big deal". Of course for everyone, YMMV.

Speaking more broadly, however, pulling the drives from a TiVo does involve some risk. I've hacked quite a few, but I also have had failures occur which blasted all the video content on more than one occasion. I've always had backups of the running partition or at the very least a bare image of the TiVo software handy, so I've never bricked a TiVo, but I've certainly accidentally reduced a couple back to their out-of box state and lost all the recorded shows on one or two. I would say that fails to qualify as "no big deal".

Even assuming that now with more experience I won't make one of these mistakes again (even I'm not so arrogant as to assume such a thing - and I'm pretty arrogant), I still find pulling the drives on a fully configured and nearly full TiVo to be a bit nerve-wracking, and I don't breathe easily until the unit is back on the shelf and fully functional.

BTW, I have in my time seen more than one hard drive dropped while handling it. In fact, one of the instances where the TiVo was reverted back to out-of-box was caused by my dropping the TiVo drive before I had a chance to make a backup.

Making the backup image takes longer than the rest of the process.

No Kidding! Especially if one is backing up the content on a full 1TB drive. On the other hand, if one is in a hurry (when am I not in a hurry?), one can of course only back up the running partition and /var. To add to that, back when keeping an extra 160G drive lying around as a backup for an S2 or S3 only cost about $45, it didn't bother me to spend the extra dollars. Now that a 1T drive costs over $300, I'm less inclined. That makes the failures potentially more painful.

While it is true that you can now use TTG to extract shows to your PC, the process of transferring the shows is excruciatingly slooooow.

True. What concerns me more, however, is getting the content back onto the TiVo in a timely fashion. TTCB just isn't fast enough to cope with a significant number of streams out there in real time. For a long, very high bandwidth film like my saved version of Judgment at Nuremberg I have to start transferring the file at least 15 minutes before watching it or we'll wind up being presented with the automatic pause screen one or several times during the viewing. Some casual testing suggests anything more than about 15 or 16 Mbps will require about a 4 - 5 minute per hour of content buffer to prevent pauses during viewing using pyTiVo or Galleon under Linux. TiVoDesktop requires just a bit more.

Of course with TTCB, one may begin viewing the uploading program almost immediately. I don't yet have my S3s hacked, so I can't test it, but can one safely begin viewing a transferring file shortly after beginning the transfer with mfs_ftp or a similar utility?

[lrhorer]

Not the end of the world if an upgrade goes through. This isn't the case of a non LBA48 kernel crashing your data (large drive with a series 1 unit). This isn't like the early monte partition layouts.

Yes, I was aware of that, thank you, although some other readers might not have been. It's not about the fear an upgrade will trash the TiVo, it's about the inconvenience of having to tear down the systems and pull the drives if it happens. I'd rather block the upgrades, hack the upgrade partitions so at a minimum telnet and ftp work, and then let the upgrades fly. Once telnet and ftp are enabled, the rest is easy, and it doesn't require pulling the drives out of the TiVos.

[captain_video]

What does one have to do with the other? On S1 and S2 TiVos at least, blocking the upgrade was merely a matter of setting the bootpage parameters or hacking rc.sysinit to prevent the system from implementing the upgrade automatically. This didn't prevent them from contacting the outside world, by any means. Is this somehow no longer the case (see my previous post)?

Check out this thread:

http://www.dealdatabase.com/forum/sh...ad.php?t=41782

It will still apply to the S3 and Tivo HD models.

I wouldn't call that "no big deal". First of all, I personally am partially disabled, so even just unplugging all the cables from one of my TiVos and then getting them plugged back in is a modestly difficult and somewhat painful ordeal. Intellectually it's trivial. Physically it is not. Anything which can't be handled - and safely so - from the keyboard is somewhat more than "no big deal". Of course for everyone, YMMV.

It's no big deal for most of us. Obviously your situation is unique.

Speaking more broadly, however, pulling the drives from a TiVo does involve some risk. I've hacked quite a few, but I also have had failures occur which blasted all the video content on more than one occasion. I've always had backups of the running partition or at the very least a bare image of the TiVo software handy, so I've never bricked a TiVo, but I've certainly accidentally reduced a couple back to their out-of box state and lost all the recorded shows on one or two. I would say that fails to qualify as "no big deal".

Again, not usually a problem for most of us. I've been hacking Tivos at least as long as the OP and I've never killed a drive by taking it out or putting it back into a Tivo. The risk you speak of usually depends on the skills of the hacker.

Even assuming that now with more experience I won't make one of these mistakes again (even I'm not so arrogant as to assume such a thing - and I'm pretty arrogant), I still find pulling the drives on a fully configured and nearly full TiVo to be a bit nerve-wracking, and I don't breathe easily until the unit is back on the shelf and fully functional.

No comment other than to say I have no problem with doing this at any time.

BTW, I have in my time seen more than one hard drive dropped while handling it. In fact, one of the instances where the TiVo was reverted back to out-of-box was caused by my dropping the TiVo drive before I had a chance to make a backup.

Perhaps you should consider a hobby that's less hazardous to your hardware.

No Kidding! Especially if one is backing up the content on a full 1TB drive. On the other hand, if one is in a hurry (when am I not in a hurry?), one can of course only back up the running partition and /var. To add to that, back when keeping an extra 160G drive lying around as a backup for an S2 or S3 only cost about $45, it didn't bother me to spend the extra dollars. Now that a 1T drive costs over $300, I'm less inclined. That makes the failures potentially more painful.

The size of the backup isn't related to the size of the drive unless you're cloning the entire drive. You're basically just making a backup of the active partitions and /var when using MFSTools or other backup utility. You shouldn't be in such a hurry when dealing with Tivos. Patience is the key. I just picked up a 750GB drive for $120 during one of the Black Friday sales. I see no reason to blow my cash just to get an additional 250GB of storage that I probably won't use anyway. I have two S3 Tivos (500GB each) and a HTPC with (soon to be) 3.5TB of storage once I get the additional 750GB drive.

True. What concerns me more, however, is getting the content back onto the TiVo in a timely fashion. TTCB just isn't fast enough to cope with a significant number of streams out there in real time. For a long, very high bandwidth film like my saved version of Judgment at Nuremberg I have to start transferring the file at least 15 minutes before watching it or we'll wind up being presented with the automatic pause screen one or several times during the viewing. Some casual testing suggests anything more than about 15 or 16 Mbps will require about a 4 - 5 minute per hour of content buffer to prevent pauses during viewing using pyTiVo or Galleon under Linux. TiVoDesktop requires just a bit more.

That's just one of the pitfalls of putting things back on a Tivo. Personally, once I've gone to the trouble of pulling the shows off the Tivo I generally put them on some other media that's easier to handle and is more portable, like DVDs. I figure if you have to pull shows off to make more room for more recordings then you either need a larger hard drive or you're watching entirely too much TV (guilty as charged, here).

Of course with TTCB, one may begin viewing the uploading program almost immediately. I don't yet have my S3s hacked, so I can't test it, but can one safely begin viewing a transferring file shortly after beginning the transfer with mfs_ftp or a similar utility?

I don't know the answer to that one. I haven't used mfs_ftp in years, and even then it was only for transferring to my PC or to another Tivo using FXP transfer. My HTPC provides me with all the means necessary to move shows back onto a device for playback.

[ScanMan]

I do have a question, however. I was of the impression the S3 used the same software upgrade methods as the S1 and S2. Is this not true? Is there no longer an if [$upgradesoftware" = false] trap in rc.sysinit? Is there no longer a bootpage utility or does the OS no longer respect the upgradesoftware=false flag in the bootpage?

Just to clarify, it's not in /etc/rc.d/rc.sysinit anymore:

/etc/rc.d/StageE_PreApplication/rc.Sequence_500.CheckForSoftwareUpgrade.sh

if [ "$upgradesoftware" = false ]; then
    echo "Not upgrading software"

[lrhorer]

It's no big deal for most of us. Obviously your situation is unique.

Everyone's situation is unique. The point is even for a perfectly abled person, shutting down the TiVo (or in my case three of them) removing the cables, pulling the cases and drives, pulling the case off another machine, setting up SATA drive umbilicals, and putting everything back together again is a significant bit of work. It is much worse for those who are disabled like me, but even when I was younger and much fitter, it still was a hassle.

Again, not usually a problem for most of us.

I doubt that. I'm a seasoned professional with 30 years in this business. I make sometimes a dozen mistakes or more in a single day, yet I generally make far, far fewer than my younger colleagues. Commercial airline pilots are some of the most competent and rigorously trained professionals in the world, yet an FAA study showed the average cockpit crew makes upwards of 15 serious errors per flight on average. Not only that, but one of the completely failed upgrades was due to a hardware problem, not any mistake I made. Another was an inexplicable problem with mfs_restore. I never did figure out what.

I've been hacking Tivos at least as long as the OP and I've never killed a drive by taking it out or putting it back into a Tivo.

Good for you. Neither have I. I have always done something else along with just taking the drive out and putting it back. Admittedly, just getting telnet and ftp working is about as innocuous a hack as can be, and I have never had a failure merely doing that, but the risk is real, albeit small, and no matter what I'm not going to breathe easy until the system is back together again. Of course the same is true at work when I perform an upgrade to one of our critical transport systems, and I've done literally thousands of such upgrades. I've only had four or five suffer service affecting outages during the process, but risk is risk.

The risk you speak of usually depends on the skills of the hacker.

That's part of it, of course, but even the most skilled individual on Earth still makes mistakes, and the unexpected can happen to anyone no matter how skilled.

Perhaps you should consider a hobby that's less hazardous to your hardware.

I said I have seen them dropped. Other than the one TiVo drive I dropped (accidentally knocked off the top of the PC, actually) and one in an operations controller I sat in what I thought was a stable position but was not, I've never killed any other hard drives in over 30 years of handling them. Still, it DID happen.

The size of the backup isn't related to the size of the drive unless you're cloning the entire drive.

That's right, and failure to do so has bitten hard on three separate occasions. Even so, backing up a 120G drive on a Series I took a lot less time than backing up 2T from a Series III.

You shouldn't be in such a hurry when dealing with Tivos. Patience is the key.

That's always good advice, but it's also not something I didn't already know.

That's just one of the pitfalls of putting things back on a Tivo.

I don't, except to watch them. Unfortunately, most of the content is copy protected, so I can't get it off the TiVos in the first place.

Personally, once I've gone to the trouble of pulling the shows off the Tivo I generally put them on some other media that's easier to handle and is more portable, like DVDs.

Since I don't have a Blu-Ray or HD DVD burner, that's not an option, and since as far as I know no one yet makes a 400+ disc BLu-Ray or HD DVD jukebox, I wouldn't do that anyway. The ones I do pull off I just put on one of the servers and leave them there.

I figure if you have to pull shows off to make more room for more recordings then you either need a larger hard drive or you're watching entirely too much TV (guilty as charged, here).

I don't really usually watch all that much TV, but in any case since the Series III has a limit of 2TB, larger hard drives are not an option.

My HTPC provides me with all the means necessary to move shows back onto a device for playback.

I'm not latching on to that acronym. What is HTPC?

[lrhorer]

Just to clarify, it's not in /etc/rc.d/rc.sysinit anymore:

/etc/rc.d/StageE_PreApplication/rc.Sequence_500.CheckForSoftwareUpgrade.sh

if [ "$upgradesoftware" = false ]; then
    echo "Not upgrading software"

Looking at that script, it looks to me like it also handles emergency repair functions, is that correct? One could of course just disable the entire script, but I wonder if it is worthwhile to only eliminate non-emergency upgrades?

[ScanMan]

Looking at that script, it looks to me like it also handles emergency repair functions, is that correct? One could of course just disable the entire script, but I wonder if it is worthwhile to only eliminate non-emergency upgrades?

That's correct. This script will handle the EMERGENCY_REINSTALL (Kickstart "52") procedure.

From /etc/rc.d/StageA_PreKickstart/rc.Sequence_700.CheckForPanic.sh

echo "Kickstart code 5 2 - emergency reinstall"
export EMERGENCY_REINSTALL=1

So if you disable this script you won't be able to perform a KS 52, which AFAIK simply installs a copy of the current sw (from MFS) into the alternate partition and attempts to boot from there. JIC you ever want a KS 52, I would stick with setting "upgradesoftware=false" in the bootpage string.