PDA

View Full Version : Optional Series I DST fix


km
03-17-2007, 09:42 AM
What exactly is the optional DST update for the Series 1? Does it actually end up switching partitions? I don't know if its worth the hassle of having to reinstall any hacks.

sbourgeo
03-17-2007, 09:48 AM
It doesn't change root partitions, the kernel, or any hacks. It is based on changing the value of the TimeZoneOld variable in MFS followed by a reboot.

km
03-17-2007, 10:21 AM
It doesn't change root partitions, the kernel, or any hacks. It is based on changing the value of the TimeZoneOld variable in MFS followed by a reboot.

What changes the timezone back later?

I presume the download is a tcl script. Does anyone have a copy? I would rather have a look at it first and run it manually.

helpdeskdan
03-17-2007, 11:08 AM
That sounds like it won't ruin my hacks. Anybody else with hacks have the guts to try this? sbourgeo, I assume you tried it?

sbourgeo
03-17-2007, 01:09 PM
That sounds like it won't ruin my hacks. Anybody else with hacks have the guts to try this? sbourgeo, I assume you tried it?

It didn't mess with my hacks. The fix is implemented as a tcl script that tweaks TimeZoneOld in MFS and is not a full software install.

I have the LBA48 kernel, ppp over serial, and autospace installed and nothing got wiped out with TiVo's fix.

helpdeskdan
03-17-2007, 02:50 PM
I'll give it a try and report back.

n8walker
03-18-2007, 08:40 AM
Software Version is the same:
Software System: 3.0-01-1-000

All my 'hacks' are still in place.

TivoWebPlus still works like it used to.

It needs to execute each time you 'update'. So thats why they need your Service Number.


Mar 16 19:53:49 (none) comm[134]: About to execute: /var/packages/RM-FixDST.runme 2>&1
Mar 16 19:53:56 (none) comm[134]: Command Output: 03/16:19:53:56: /tvbin/tivosh: New DST start date is March 10 (13582)
Mar 16 19:53:56 (none) comm[134]: Command Output: 03/16:19:53:56: /tvbin/tivosh: Old DST start date is March 31 (13603)
Mar 16 19:53:56 (none) comm[134]: Command Output: 03/16:19:53:56: /tvbin/tivosh: Old DST end date is October 27 (13813)
Mar 16 19:53:56 (none) comm[134]: Command Output: 03/16:19:53:56: /tvbin/tivosh: New DST end date is November 3 (13820)
Mar 16 19:53:56 (none) comm[134]: Command Output: 03/16:19:53:56: /tvbin/tivosh: Checking for existing DST overrides
Mar 16 19:53:56 (none) comm[134]: Command Output: 03/16:19:53:56: /tvbin/tivosh: Creating DST override (1 -> 23)
Mar 16 19:53:56 (none) comm[134]: Command Output: 03/16:19:53:56: /tvbin/tivosh: Clearing existing DST overrides

falc122727
03-18-2007, 09:56 AM
Based on this thread, I signed up for the update at Tivo.com for my 2 hacked S1s. However, soon after, I see this post from another forum, and now wish I hadn't:

The patch updates the software to: 3.5b-01-1-031. It replaced my LBA48 kernel with the original so my extended hard drive (over 137gb) was inaccessible. The recordings are still there but will give an error when you try to watch them. (Don't delete them till you've replaced the kernel.) It also deleted all my hacks including telnet and ftp. I pulled the drives and had to reinstall the lba48 kernel, cachecard drivers and kill initrd. I should have fixed rc.sysinit.author also but didn't realize that it been deleted. If you don't have a cachecard you'll probably still have telnet/ftp. I then ftp'd my backup /var/hack files and started TWP via telnet. I'm now in the process of getting all the other stuff working again. I'll upload my backup rc.sysinit.author and redo the symlinks I had and copy to the inactive partition. I do have a problem with Tivo rebooting on certain shows that I assume were recorded on the extended partition since it will do it everytime at a certain spot while replaying but overall not a huge issue just a major PITA.

I wonder if I can call Tivo and have them stop the updates?

sbourgeo
03-18-2007, 10:31 AM
I wonder if I can call Tivo and have them stop the updates?

Release 3.5b is for S1 DirecTV combo units. The DST fix being discussed here is for S1 standalone units.

If you were able to sign up for the fix via research.tivo.com/prioritydst (http://research.tivo.com/prioritydst/), then you have a standalone S1 and will not get software release 3.5b.

PortlandPaw
03-18-2007, 09:56 PM
I've written a new routine for hackman that does what the TiVo patch does as developed by jberman (thanks, jman!). It's only been tested on my Series 1 standalone and DTivos and I have no idea what it will do on other models. It probably won't brick them, but you proceed at your own risk. Download from sig site.

Oh, and be sure to read the ReadMe if you're new to hackman.

TivoMind
03-19-2007, 11:34 PM
Does this optional fix need to run periodically (e.g. annually or semiannually) or does it reset the beginning and ending of DST permanently?

PortlandPaw
03-20-2007, 07:34 AM
I don't know yet. The way I think of it is this -- run it when the time is wrong on the TiVo.

I expect that will be at the beginning and end of the new "extended" DST periods in the fall and spring, four times total.

Or, if you turn of DST in guided setup, you might just have to do it at the beginning and end of DST, twice a year.

Still experimenting!

km
03-21-2007, 09:33 AM
Does this optional fix need to run periodically (e.g. annually or semiannually) or does it reset the beginning and ending of DST permanently?

It appears that they download "RM-FixDST.runme" on each call. The first time it runs during a special week it saves state in an override object in the MFS. Each time it runs it checks for the override object and if it exists and agrees with the current DST calculation it does nothing. Otherwise it updates or deletes the object, changes the timezone and schedules a late night reboot.

If you cross the special DST time boundaries without making a call, your timezone will be wrong.

It's conceivable they could put some intelligence in their server, parse the logs that are uploaded and not send "RM-FixDST.runme" on every call, but I doubt it. They have sent it to me each day since I opted in. They can't let down during the old DST periods, because your machine could have been turned off for a long period starting in one of the new DST weeks, and they would need to reset the timezone and delete the override object.

PortlandPaw
03-21-2007, 10:09 PM
Is "RM-FixDST.runme" a text file, tcl or otherwise? Can you upload it here?

km
03-22-2007, 08:45 AM
Is "RM-FixDST.runme" a text file, tcl or otherwise? Can you upload it here?

It's a tcl script. It has a copywrite notice at the top, so I don't want to post it. However, it will download every day to anyone who opts in, so its easy to trigger a call and just copy it out of /var/packages.

PortlandPaw
03-22-2007, 08:54 PM
Thanks, but I'd rather not trigger a wipe of my hacks. Or do they give you directions on how to run it and/or does it run non-destructively?

km
03-22-2007, 09:14 PM
Thanks, but I'd rather not trigger a wipe of my hacks. Or do they give you directions on how to run it and/or does it run non-destructively?

It does nothing but if necessary change your timezone and reboot.