# Patching Series 1 for new DST rules



## sbourgeo (Nov 10, 2000)

Since it appears that TiVo has no plans to issue a DST update for S1 boxes, I've been messing around with trying to add this functionality myself.

I haven't had much success though, and am wondering if timezones are all handled at the MFS level. No matter which timezone I try to use, my TiVo always seems to use GMT instead.

Here's what I've tried:


Check existing DST dates on a Red Hat box:

```
# zdump -v EST5EDT|grep 2007
EST5EDT  Sun Apr  1 06:59:59 2007 UTC = Sun Apr  1 01:59:59 2007 EST isdst=0 gmtoff=-18000
EST5EDT  Sun Apr  1 07:00:00 2007 UTC = Sun Apr  1 03:00:00 2007 EDT isdst=1 gmtoff=-14400
EST5EDT  Sun Oct 28 05:59:59 2007 UTC = Sun Oct 28 01:59:59 2007 EDT isdst=1 gmtoff=-14400
EST5EDT  Sun Oct 28 06:00:00 2007 UTC = Sun Oct 28 01:00:00 2007 EST isdst=0 gmtoff=-18000
```

Grab latest timezone data from here
Extract the data onto Red Hat box with _tar xvfz tzdata2007c.tar.gz_
Compile time zone files with _zic northamerica_
Test new DST dates:

```
# zdump -v EST5EDT|grep 2007
EST5EDT  Sun Mar 11 06:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 EST isdst=0 gmtoff=-18000
EST5EDT  Sun Mar 11 07:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 EDT isdst=1 gmtoff=-14400
EST5EDT  Sun Nov  4 05:59:59 2007 UTC = Sun Nov  4 01:59:59 2007 EDT isdst=1 gmtoff=-14400
EST5EDT  Sun Nov  4 06:00:00 2007 UTC = Sun Nov  4 01:00:00 2007 EST isdst=0 gmtoff=-18000
```

tar up TZ files for copy to TiVo:

```
cd /usr/share/zoneinfo
tar cvf timezone2.tar PST8PDT MST7MDT MST HST EST5EDT EST CST6CDT
```

Pull drive from SA TiVo and extract timezone files into /var/hack/zoneinfo
Add _export TZ="/var/hack/zoneinfo/EST5EDT"_ to /etc/rc.d/rc.sysinit on SA TiVo
Put drive back in SA TiVo and power up

Whatever I set TZ to ends up giving me GMT in my TiVo banner (5 hours ahead). I'm stuck and not sure how to proceed. Does anyone know how timezone info is handled on the S1 standalones and if so, could you point me in the right direction?

Thanks,

Steve


----------



## sbourgeo (Nov 10, 2000)

^bump^


----------



## PortlandPaw (Jan 11, 2004)

If I'm not mistaken, the TiVo runs on GMT and the program data is adjusted accordingly to local time in the guide data updates.

So, assuming that the guide data makes the necessary adjustments, there shouldn't be a problem. 

I guess it's possible that the guide data is sent out GMT and the TiVo makes the adjustment, but I hope not.

I hope I'm not just assuming away the problem!


----------



## SeanC (Dec 30, 2003)

PortlandPaw said:


> If I'm not mistaken, the TiVo runs on GMT and the program data is adjusted accordingly to local time in the guide data updates.


This has been mentioned by Tivo employees several times here, but for whatever reason there is still much gnashing of teeth.


----------



## sbourgeo (Nov 10, 2000)

SeanC said:


> This has been mentioned by Tivo employees several times here, but for whatever reason there is still much gnashing of teeth.


So you're 100% sure that my manual recordings will also work correctly?


----------



## SeanC (Dec 30, 2003)

No I'm not. But if Tivo has looked at the problem and what their reps have been saying on the board is correct, then there is nothing to worry about. Time will tell.


----------



## sbourgeo (Nov 10, 2000)

SeanC said:


> No I'm not. But if Tivo has looked at the problem and what their reps have been saying on the board is correct, then there is nothing to worry about. Time will tell.


The problem is that TiVo has not discussed the impact of DST changes on manual recordings.


----------



## PortlandPaw (Jan 11, 2004)

I think if the TiVo clock is set correctly and if it's not incorrectly "updated" by the TiVo service, then even the manual recording should be OK.


----------



## sbourgeo (Nov 10, 2000)

I had a bit of time to monkey around with this today, and tried to manually configure DST to start on the second Sunday in March and end on the first Sunday in November by adding the following to /etc/rc.d/rc.sysinit:


```
export TZ="GMT00EDT,M3.2.0,M11.1.0"
```
This change seems to impact only the time displayed in the banner, however. While the "date" command at the bash prompt properly displays GMT, the guide and to-do list are still an hour behind starting on 3/11. I still don't know where TiVo buried the DST logic (MFS or in a binary somewhere?) though. It appears that some TiVo owners from Australia, New Zealand, and Canada have done some work in this area, so reading up on their work might at least be a place to start.

There is some pertinent info stored in MFS/State/LocationConfig, but I don't have much info on it as yet:


PostalCode: appears to be where your zip code is stored
DaylightSavingsPolicy: DST appears to be disabled when set to 1, and enabled when set to 2 (or NULL). 
TimeZoneOld: appears to indicate your timezone.

0 = GMT
1 = GMT-5 (EST)
2 = GMT-6 (CST)
3 = GMT-7 (MST)
4 = GMT-8 (PST)
5 = GMT-9 (Alaska)
6 = GMT-10 (Hawaii)
7 = GMT
8 = GMT+1
...

There appears to be more relevant info residing in MFS in newer software versions (including defined DST periods I think), but that isn't much help here. I should probably do some poking around in my DSR6000 that is running 3.5b, and has received a patch for the DST issue.

I am "thinking above my pay grade" here, so any input from someone more knowledgeable than myself would be greatly appreciated.


----------



## BTUx9 (Nov 13, 2003)

sbourgeo said:


> I had a bit of time to monkey around with this today, and tried to manually configure DST to start on the second Sunday in March and end on the first Sunday in November by adding the following to /etc/rc.d/rc.sysinit:


the DST calculations are fairly well hard coded (a simple update to data in mfs won't solve the issue)

the calculations are done deep within tivoapp (the monolithic tivo s/w file) but I don't know if it calls an external glibc routine or not


----------



## joblo (Jun 5, 2002)

Just a hunch: after changing all the relevant config files you can find, try changing your time zone by rerunning GS.


----------



## BTUx9 (Nov 13, 2003)

no... It's extremely unlikely that just running guided setup would be required for changed config files to take effect... it just doesn't make sense with what we DO know


----------



## joblo (Jun 5, 2002)

And what, pray tell, is it that "we DO know"?

I'm a complete novice at TiVo hacking, but based on the way GS works in the older software versions, it seems logical that that's where the TZ config info would be referenced. Why distribute config files at all if they aren't used in the field and all the necessary info is hardwired into the binary?

It also seems pretty clear that ReplayTV  which, unlike TiVo, chose to support ALL of its users  implemented DST the way Im suggesting, based on their DST fix. (www.replaytv.com/dst, and btw, the procedure ran like a champ on my old SS2000.)

While its certainly possible that TiVos DST implementation is more brain damaged than Replays, I find that hard to believe. It seems more likely to me that TiVo made a corporate decision NOT to support S1 units because most of them are either unsubscribed or have lifetime subs, and thus (1) they arent risking a very large revenue stream, and (2) they probably think they can sell more S2 and S3 boxes if they make S1 software even less user-friendly than it already is. Which stinks to high heaven, but there it is.

Anyway, Im sure there are a number of us here that would like to have a fix/patch/workaround for S1 units, so if you have information which might be helpful, please advise.

Btw, I dont really care whether the units know the correct change dates or not. Ive already discovered that turning off DST and bouncing between time zones twice a year via GS is a perfectly valid workaround for anyone west of the Eastern Time Zone. Unfortunately, I am in the Eastern zone, so for me, this will mean keeping my clocks off by an hour year round.

Now I have three unsubscribed units, plus 18 manual recordings even on my one subscribed unit, so rerunning GS twice a year and living with incorrect clocks is definitely preferable to redoing all those manual recordings 4 times a year. Still, if someone could advise me on how to fool my TiVos into thinking that EST is GMT-4 and CST is GMT-5, Id be a much happier camper.


----------



## BTUx9 (Nov 13, 2003)

joblo said:


> And what, pray tell, is it that "we DO know"?


just trying to give some knowledgable advice and maybe save you some work.

btw, if this is your way of asking for help, I must say it leaves me singularly unmotivated to do so.


----------



## joblo (Jun 5, 2002)

Except you haven't offered any actual advice yet, BTUx9, just negatives and supercilious implications that you know things the rest of us poor souls don't. Look, no offense, I don't mean to be rude, but if you don't have anything positive to offer, it doesn't much matter whether you're motivated or not, does it?

Now sbourgeo has told us what he knows and asked for help, and I offered an off-the-cuff suggestion in my first post and admitted Im a novice in the second. So we already know we're ignorant. Pointing out to us that, yea, verily, we art even more ignorant than we thought, while quite probably true, is singularly UNhelpful. Know what I mean?


----------



## zarsky99 (Jan 27, 2007)

Oh no you didn't! 


*you have to say it like a stereotypical inner city black woman


----------



## chris22 (Aug 31, 2006)

You rude new people (joblo) need to shut up and respect BTU for what the user has contributed to the Tivo Hacking Community.


----------



## sbourgeo (Nov 10, 2000)

I think BTUx9 is correct about TiVo burying their DST logic in tivoapp. They certainly don't appear to depend on standard routines in libc since I found no difference when I tried copying libc and the linker from my DSR6000 running 3.5b to my SA TiVo. Regular TiVo functionality appeared to work fine, but there was no change to the handling of time...

I also have a spare DSR6000 running 3.5 (pre-"b"), so I was able to see some of the "before" and "after" picture of the fix for S1 combo units. 3.5b introduces DaylightSavingsPeriods in MFS/State/LocationConfig, which includes offsets for start and end dates as well as start and end times. Presumably, the TiVo code just reads these values out of MFS. If the S1 standalones used the same logic, we could probably just change "StartDate" and "EndDate" to do whatever we wanted.

Without the ability to get to the source that handles the DST logic, I'd say that we're SOL at this point...


----------



## joblo (Jun 5, 2002)

sbourgeo said:


> Whatever I set TZ to ends up giving me GMT in my TiVo banner (5 hours ahead).


Ok, question: did your TiVo banner always display GMT? (Im guessing it didnt, otherwise why would you be concerned about the DST issue at all?)

Or did your TiVo only start displaying GMT after you messed with the config files? In that case, your changes clearly had some effect, and the problem is just to figure out why/what/how.


----------



## sbourgeo (Nov 10, 2000)

joblo said:


> Ok, question: did your TiVo banner always display GMT? (Im guessing it didnt, otherwise why would you be concerned about the DST issue at all?)


I must have initially been setting $TZ wrong, since it defaults to GMT when you set it to a bogus value.

Setting $TZ to "_GMT00EDT,M3.2.0,M11.1.0_" was also kinda weird. It changed the banner time properly on my unsubbed DSR6000 running 3.5, but actually set my HDR312 go back an extra hour on reboot. I tried setting $TZ to the same value on a Linux box and "date" returned the proper time...


----------



## BTUx9 (Nov 13, 2003)

in case some of you weren't aware, there's an interesting development: http://www.tivocommunity.com/tivo-vb/showthread.php?t=343660&page=1&pp=30

If what jberman has reported stays true, it'd certainly be a much better alternative to changing manual recordings for the period


----------



## sbourgeo (Nov 10, 2000)

BTUx9, you beat me to the punch.  I wanted to add jberman's findings to the more technical discussion here since they are far more useful than what I have found out so far.

From here: 


jberman said:


> I'm certainly no expert at this, but I think I might have figured out a workaround for my Series 1 SA (Philips) Tivo....
> 
> I spent most of the afternoon piecing together information on this problem, and eventually discovered that there's an MFS setting called TimeZoneOld that has the following possible values (which I grabbed from DbEnum.tcl):
> 
> ...


I think we can build a workable solution based on jberman's findings.

At a high level, we would have a tcl script that would be fired off via cron at 1:59 AM every Sunday in March and November, which would:


Check if it is the second Sunday in March or the first Sunday in November
If so, pull the TimeZoneOld value out of MFS, and reset it to an appropriate value (+1/-1 in most cases and 1/23 for the eastern time zone special case)
Reboot the box


----------



## kkimmell (Aug 16, 2005)

I realize that these notes are from a post this morning but I'm wondering if there has been any progress from the gifted scripters out there?


----------



## slango (Nov 25, 2002)

What happens when the "old" DST code (i.e. change to DST the first Saturday in April) kicks off. Will the altered time zone cause the clock to once again be off by one hour?

Just playing Devil's Advocate.


----------



## sbourgeo (Nov 10, 2000)

kkimmell said:


> I realize that these notes are from a post this morning but I'm wondering if there has been any progress from the gifted scripters out there?


I'm planning on implementing a more user-friendly DST workaround via jberman's technique, but am kinda busy with "real work" today. Go figure...


----------



## kkimmell (Aug 16, 2005)

Damn real work!!! I guess I can stick my nose back in that freeBSD box I've been fiddling with then... 

Seriously, thanks to all who've contributed. Looking forward to trying out the fix that the company I paid my fees to can't seem to come up with.


----------



## jberman (Oct 2, 2002)

sbourgeo said:


> I'm planning on implementing a more user-friendly DST workaround via jberman's technique, but am kinda busy with "real work" today. Go figure...


Cool! But be careful... if tivoapp decides to set the clock forward by another 3600 seconds at 2:00 am on April 1, you're gonna have a problem on your hands...


----------



## jberman (Oct 2, 2002)

slango said:


> What happens when the "old" DST code (i.e. change to DST the first Saturday in April) kicks off. Will the altered time zone cause the clock to once again be off by one hour?


Slango -

My little hack-job of a script essentially tells the Tivo to "set the GMT offset to -14400, dammit!" ... so it's really a hard-coded fix for East Coast users. However, when scheduled to run twice (once on the second weekend in March and again on the first weekend in April), it has the nice side-effect of automatically and immediately undoing anything done by the "old" DST code. (By the way, I created a corresponding hard-coded script for "falling back" in October/November; the only change is that the offset is different.)

The script can be easily edited for other time zones (in fact, over in the other thread I provide instructions on how to do so), but sbourgeo is looking into creating a more "fluid" solution that doesn't have any hard-coded values, and instead can simply change the current offset from GMT by an hour (without any of the brute-force, and hard-coded, stuff that I did). And I wish him the best of luck!


----------



## sbourgeo (Nov 10, 2000)

Update everyone:

TiVoPony has posted that an official DST fix for S1 standalones is available! See here for the details. And congrats are in order for jberman for helping the TiVo engineers think outside the box.

That aside, the time I spent today packaging up a nice distribution of a DST tool that would automatically toggle TimeZoneOld to handle the new DST rules is officially obsolete. 

Oh well, we have a solution and I got to play with tcl a bit... 

sbourgeo


----------



## kkimmell (Aug 16, 2005)

Um... before realizing the potential problems that signing up for the "official" fix might bring, I signed up for it.

I'll admit that my memory is quite hazy since the last time I hacked my Series 1 was when the modem died and I added the Net add-on.

I know I've done some hard drive upgrades in the past but can't remember what size the drives are. The output of a "df -h" wasn't helpful to me.

Can someone give me some simple steps aside from opening the box that might tell me my drive sizes. And should I be worried that if they are over a certain size that the update that should be forthcoming in the next day or so might break my system?

Thanks/uh-oh...

-K


----------



## BTUx9 (Nov 13, 2003)

re: finding hard drive sizes

with the net add-on, I assume you can telnet.
there's probably an easier way, but if you run "pdisk -l /dev/hda" for hda and hdb, and add up the numbers in parentheses at the ends of lines that end with G, that'll give you a fairly accurate #gigs (all the other partitions add up to 1.5 GB or so)

Alternately, if you have Tivoweb, the info screen shows disk information... the "sectors = ########" item shows blocks... divide by 2000000 and it'll give number of gigs


----------



## kkimmell (Aug 16, 2005)

Yes I can telnet and have tivowebplus installed... of course I'm at work now so I'll check at lunch.

So what numbers should worry me - if any. I see in the "official patch thread" that it wont be a full kernel install. So should I be worried if I've got a 200G drive in there? 

I'm only wondering if I should disconnect from the network until I can get all of my ducks in a row to fix it.

-K


----------



## BTUx9 (Nov 13, 2003)

any number over 130G is likely to be problematic (the highest standard drive that doesn't need lba48 is 120G)

if you check "bootpage -p", and you see "upgradesoftware=false" then you don't have to worry... even if the system downloads an upgrade, it won't actually install it until you take action (although it'll reboot every couple days)


----------



## maerativo (May 15, 2005)

For those of us that are not computer savvy when working with Linux would someone tell me how to access the "bootpage -p" when I have my TiVo HD installed into my desktop computer? Do I need to have Linux installed on my desktop computer in order to access the TiVo HD from my Sony SAT-60? As you can tell I'm a novice at this and don't know anything about programing.

Thanks,
Maera

2 Sony SAT-60's (1-300GB HD & 1-stock)


----------

