daylight savings change

[kkolarik]

It is against my better judgement to allow Directv to "upgrade" my software, lest I can't use Tytools and the like. One (or two) questions are left, however:

1) Is any change really necessary (or will the programming signal reset the clock itself)?

2) if an upgrade (or patch) IS required, has someone posted it/ is it available?

[kkolarik]

I guess I should add that this is a Directv series 2 tivo (hughes, originally 40 gig), upgraded to 6.2a using ptvupgrade and instantcake.

I would think that the datastream that lets the box know what programming is available also sets the RTC so the box knows what time it is. If this isn't the case, what are my optons??

[xdz]

The only option for now is to change your timezone for the next couple of weeks otherwise your manual recordings are pooched. We need a patch for 6.2 or this is going to be a yearly problem.

[ttodd1]

There is a patch out there its called 6.2a. And threads about :

http://www.dealdatabase.com/forum/showthread.php?t=53478

[BruceS]

I don't know how to post a link to the message, but there is an announcement on tivo.com that says any recordings from Season Passes or Wishlists should occur correctly without the new software.

It says that the only ones that would fail are ones where you select a specific start time and stop time.

[n5tcg]

I'm sorry to say I let them upgrade my DVR80, now I have no access to my dvr thru USB. Dam Them.................:mad:

[PlainBill]

I'm sorry to say I let them upgrade my DVR80, now I have no access to my dvr thru USB. Dam Them.................:mad:

You're blaming the wrong person. The process for upgrading to a new OS has been well documented. If done properly you will not lose anything and will not even have to pull the drive. All of the tivoapp patches have been identified, so there is no reason not to do it properly.

PlainBill

[ttodd1]

I'm sorry to say I let them upgrade my DVR80, now I have no access to my dvr thru USB. Dam Them.................:mad:

Curious - what did you think was going to happen when you let them upgrade your unit.? Did you think that DTV would put checks into the upgrade to see if you hacked your unit and then take steps to not mess them up on you? :confused: :rolleyes:

[onyx00]

The first time ever I am glad I live in Arizona :-) No daylight savings here, wee!

[PlainBill]

The first time ever I am glad I live in Arizona :-) No daylight savings here, wee!

The first time? I'm glad every time I hear about a hurricane heading for Florida, or a blizzard heading for Minnesota. Of course, then there are the afternoons in June where the temperature hits 115....

PlainBill

[comfreak]

Where's the information on the new patch and how to install it for relative newbs?

I see this is the only downfall of a modified box. Acts of Congress will cause my hacked Tivo to function improperly.

[mike_s]

I see this is the only downfall of a modified box. Acts of Congress will cause my hacked Tivo to function improperly.Your TiVo works fine. Acts of Congress have caused timekeeping to act improperly.

[EvilJack]

never mind... text deleted...

there is a timezone setting in the satellite menu. I told it that my Tivo
was in the next time zone, disabled DTS and my times are current again.

jack

[EvilJack]

Your TiVo works fine. Acts of Congress have caused timekeeping to act improperly.

I like one idea I heard... they should have moved us up 30 minutes and
then dropped DST all together. Just average us out and leave it alone...

jack

[land]

To set clock ahead hour open telenet and type
date --set='+60 minutes'

[dishdude]

To set clock ahead hour open telenet and type
date --set='+60 minutes'


Does this actually work or is it a joke?

[beanpoppa]

Does it work? Yes. Does it work to solve the DST change? No. It sets the internal clock ahead 60 minutes. Since the internal clock is kept at UTC, and season passes, guide info, etc are based on UTC, everything will start recording an hour too early. However, if you only are ONLY concerned about the time displayed on the info screen and manual recordings this will correct them... just break everything else. Oh, and since the DTivo updates its clock from the satellite regularly, the change probably wouldn't stick.

Does this actually work or is it a joke?

[Butch]

Sounds like this will work great for a non sub Stand alone series 2 TCD2400 (yes I can do manual recordings throw TivoWebPlus, he,he and also when I hit the record button) unit running software 7.2 It does not call in, I use it only as a manuall record & MFS_FTP transfer movies to it (It lost its HMO & HME)
I will put it in the cron to adjust time / then at the old dst time I will put it back.

[ctsshack]

never mind... text deleted...

there is a timezone setting in the satellite menu. I told it that my Tivo
was in the next time zone, disabled DTS and my times are current again.

That's a great ideal and had though of it earlier. The problem is that it doesn't work for us on Eastern Standard Time. If the menu had an Atlantic Standard Time option, we would be OK.

-ctsshack

[Butch]

THIS MIGHT BE HELPFULL TO SOMEBODY

Add this in your rc.sysinit.author

#!/bin/bash
#
# DST temp FIX
set xxm=""
set zxf=""
xxm=$(date +%m)
if [ $xxm -eq "3" ]
then
zxd=$(date +%d)
if [ $zxd -ge "11" ]
then date --set='+60 minutes'
fi
fi

THEN
IN CRON set to reboot your tivo on March 11 00:00:01 ANY YEAR and April 1st 00:00:01 ANY YEAR
NOTE:
#* * * * * command to be executed
#- - - - -
#| | | | |
#| | | | +----- day of week (1 - 7) (monday = 1)
#| | | +------- month (1 - 12)
#| | +--------- day of month (1 - 31)
#| +----------- hour (0 - 23)
#+------------- min (0 - 59)
#
#New DST adjustmented on restart rc.sysinit.author file
# need to reboot march 11 and april 1st ... hour 5 is 0 for est
1 5 11 3 * echo "`date` REBOOT March 11 For DST FIX" >> /var/log/cronlog-main; reboot
1 5 1 4 * echo "`date` REBOOT April 1 For DST FIX" >> /var/log/cronlog-main; reboot

JUST TO NOTE... MY TIVO DOES NOT CALL FOR GUIDE DATA.. if yours calls in for date then maby it will change its time, if so then you would have to adjust the time again.
But for me this will work perfect.

[jbch]

OK, take the previous cron and have it run these scripts. Essentially changing your timezone back and forth one hour, but without guided setup and any other problems...that I can tell. This code is for Cental, you will have to adjust the TimeZoneOffset seconds based on the time zone your in. It should work for the people on the East cost too. Remember to reboot after running the scripts. You will have to setup the cron to run DSTForward.tcl on the new date change, and run the DSTBack.tcl three weeks later when the original Tivo code catches up. Then again in the Fall, after the Tivo code prematurely falls back, and once more on the new Fall time change.

This code is for an old S2 SA but should also work for S1's.


bash-2.02# cat DSTForward.tcl
#!/tvbin/tivosh
#
#

# source of RetryTransaction function
tvsource $tcl_library/tv/mfslib.tcl

proc FIXUP {db} {
try {
RetryTransaction {
set sobj [db $db open /State/LocationConfig]
dbobj $sobj set TimeZoneOffset -18000
}
} catch errCode {
puts "Failed to FIXUP, code=($errCode)"
return 0
}
return 1
}

set db [dbopen]
FIXUP $db
dbclose $db


bash-2.02# cat DSTBack.tcl
#!/tvbin/tivosh
#
#

# source of RetryTransaction function
tvsource $tcl_library/tv/mfslib.tcl

proc FIXUP {db} {
try {
RetryTransaction {
set sobj [db $db open /State/LocationConfig]
dbobj $sobj set TimeZoneOffset -21600
}
} catch errCode {
puts "Failed to FIXUP, code=($errCode)"
return 0
}
return 1
}

set db [dbopen]
FIXUP $db
dbclose $db

[kumashi]

The above script doesn't seem to work on my S1 SA... the error message I get is "Failed to FIXUP, code=(invalid attribute: TimeZoneOffset)." Any ideas? Is the attribute called something else on S1s?

Thanks, Jesse

Update: I've found a setting in LocationConfig called TimeZoneOld, currently set to 1 (I'm on the East Coast). Could that possibly be changed to fool the Tivo into thinking it's in a different timezone, and change it back (using cron) after the three weeks are over? Investigating....

[dishdude]

My season passes seem to be recording correctly, the time on the display is the least of my worries. I have the slices on my tivo and I bought the slicer but if the only change right now is the time I'll stick with 6.2 until I get around to going thru the whole process..

[kumashi]

Update: I've found a setting in LocationConfig called TimeZoneOld, currently set to 1 (I'm on the East Coast). Could that possibly be changed to fool the Tivo into thinking it's in a different timezone, and change it back (using cron) after the three weeks are over? Investigating....Making some progress... according to DbEnum.tcl, the values for TimeZone are here:

namespace eval TimeZone {
variable Alaska 5
variable Central 2
variable Eastern 1
variable GMT 7
variable GMTMinus1 20
variable GMTMinus11 24
variable GMTMinus12 25
variable GMTMinus2 21
variable GMTMinus3 22
variable GMTMinus4 23
variable GMTPlus1 8
variable GMTPlus10 17
variable GMTPlus11 18
variable GMTPlus12 19
variable GMTPlus2 9
variable GMTPlus3 10
variable GMTPlus4 11
variable GMTPlus5 12
variable GMTPlus6 13
variable GMTPlus7 14
variable GMTPlus8 15
variable GMTPlus9 16
variable Hawaii 6
variable Mountain 3
variable Pacific 4
}

So if I use cron to set TimeZoneOld to 23 (GMT-4) on the third Sunday in March and set it back to 1 (GMT-5) on the first Sunday in November, it just might work for the East Coast.....

Update: Success! Setting TimeZoneOld to 23 fixed my Tivo's on-screen clock, and recordings are still happening on time.

Here are my crontab settings:

1 7 8-14 3 0 /var/hack/bin/DSTSpringAhead.tcl; echo "`date` - Reboot for DST fix (spring ahead)" >> /var/log/cronlog_dst; sync; /sbin/restart
1 6 1-7 4 0 /var/hack/bin/DSTSpringAhead.tcl; echo "`date` - Reboot for DST fix (spring ahead)" >> /var/log/cronlog_dst; sync; /sbin/restart
1 6 25-31 10 0 /var/hack/bin/DSTFallBack.tcl; echo "`date` - Reboot for DST fix (fall back)" >> /var/log/cronlog_dst; sync; /sbin/restart
1 7 1-7 11 0 /var/hack/bin/DSTFallBack.tcl; echo "`date` - Reboot for DST fix (fall back)" >> /var/log/cronlog_dst; sync; /sbin/restart

DSTSpringAhead.tcl:
#!/tvbin/tivosh
source /tvlib/tcl/tv/Inc.itcl
source /tvlib/tcl/tv/mfslib.tcl
set db [dbopen]
transaction {
set setup [db $db open /State/LocationConfig]
puts "Setting to GMT+4 ..."
dbobj $setup set TimeZoneOld 23
}
dbclose $db
unset db
event send 23 16 0
puts "Done"

DSTFallBack.tcl:
#!/tvbin/tivosh
source /tvlib/tcl/tv/Inc.itcl
source /tvlib/tcl/tv/mfslib.tcl
set db [dbopen]
transaction {
set setup [db $db open /State/LocationConfig]
puts "Setting to GMT+5 ..."
dbobj $setup set TimeZoneOld 1
}
dbclose $db
unset db
event send 23 16 0
puts "Done"

[gwar11d2]

Hmm, Your scripts look great...I'm getting the following though:
(Changing mine from 1 and 2 for central time zone...) running r10 6.1

bash-2.02# ./DSTSpringAhead.tcl
Setting to GMT+4 ...
invalid attribute: TimeZoneOld
while executing
"dbobj $setup set TimeZoneOld 1 "
invoked from within
"transaction {
set setup [db $db open /State/LocationConfig]
puts "Setting to GMT+4 ..."
dbobj $setup set TimeZoneOld 1
}"
(file "./DSTSpringAhead.tcl" line 5)

[jbch]

Sorry about that code change. I didn't dig the old S1 out to look. My S2 is running old 4.01b code. Congrats though, on figuring it out. Mine seems to work very well with the change.

Remember, if you have mfs_dumpobj on your tivo, you can do a 'mfs_dumpobj /State/LocationConfig' and see what your variables are called and their values.

Seems like I got the mfs_dumpobj and other mfs tools from one of the busybox type packages. Sorry I don't have a link, its been a few months since I messed with all this stuff. Got it working good, and never looked back.

[gwar11d2]

Hmm, it looks like it grabs the time from the sat no matter if I change the timezone offset or not...After I change it, and look at the variable it is changed...then I reboot and it's back to the same as it was before.

FYI, this is DirecTiVo R10 running 6.1 prom modded, and all the goodies...here is a little output:

LivingRoom-TiVo# mfs_dumpobj /State/LocationConfig
LocationConfig 7225/10 PRIMARY {
Version[1]=24
PostalCode[16]=61821
TimeZoneOffset[19]=-21600
IndexPath[4]=/State/LocationConfig
}
LivingRoom-TiVo# uname -a
Linux (none) 2.4.20 #2 Wed Aug 18 16:23:47 PDT 2004 mips unknown
LivingRoom-TiVo#

[jbch]

Hmm, it looks like it grabs the time from the sat no matter if I change the timezone offset or not...After I change it, and look at the variable it is changed...then I reboot and it's back to the same as it was before.

FYI, this is DirecTiVo R10 running 6.1 prom modded, and all the goodies...here is a little output:

LivingRoom-TiVo# mfs_dumpobj /State/LocationConfig
LocationConfig 7225/10 PRIMARY {
Version[1]=24
PostalCode[16]=61821
TimeZoneOffset[19]=-21600
IndexPath[4]=/State/LocationConfig
}
LivingRoom-TiVo# uname -a
Linux (none) 2.4.20 #2 Wed Aug 18 16:23:47 PDT 2004 mips unknown
LivingRoom-TiVo#

Thats strange, I'm running standalone, so it must be a 'feature' of DTivo, to reset the timezone info upon reboot, or a change in later code revision, as I'm running 4.0.1b. Maybe someone with more knowledge of DTivo can chime in. Sorry...

[gwar11d2]

I suspect when it pulls it's guide data, it syncs the clock as well... Fun stuff nonetheless. I've been getting much less sleep lately do to the time change and my tivo hacking :)

[kumashi]

(post deleted)

[kumashi]

Hmm, Your scripts look great...I'm getting the following though:
(Changing mine from 1 and 2 for central time zone...) running r10 6.1

bash-2.02# ./DSTSpringAhead.tcl
Setting to GMT+4 ...
invalid attribute: TimeZoneOld
while executing
"dbobj $setup set TimeZoneOld 1 "
invoked from within
"transaction {
set setup [db $db open /State/LocationConfig]
puts "Setting to GMT+4 ..."
dbobj $setup set TimeZoneOld 1
}"
(file "./DSTSpringAhead.tcl" line 5)The script only works on Series 1 SA running 3.0. Maybe the information can help someone write something for other Tivos, though... all I own is an S1, so that's all I have to work with. Sorry.... :(

[ctsshack]

It's a shot in the dark, but maybe if you turn off "Automatically detect time zone" in the system settings on the TiVO menu, maybe that might help.

[gwar11d2]

Unfortunatly....I don't have that option in the stripped down dtivo menu :(... However if someone could help me find it in mfs, I might be able to tweak it there... Another thing I was considering is changing the zip code...but that _could_ screw up what downloads schedule wise...I dunno. Maybe not?

[kumashi]

Unfortunatly....I don't have that option in the stripped down dtivo menu :(... However if someone could help me find it in mfs, I might be able to tweak it there... Another thing I was considering is changing the zip code...but that _could_ screw up what downloads schedule wise...I dunno. Maybe not?The zip code on S1 is located in /State/LocationConfig. That might be a good place to start with an S2.

[gwar11d2]

Yep, that's exactly where it is at on the S2.5 R10:
LocationConfig 7225/10 {
Version = 33
PostalCode = 61821
TimeZoneOffset = -21600
IndexPath = /State/LocationConfig
}

So....presumably I can change my postal code to another timezone someplace to the east and see what happens... I'm wondering if I'll loose my locals....we'll find out, I'll keep you all posted.

[gwar11d2]

nope...didn't work... On reboot, it still changed the TimeZoneOffset back to -21600

Oh well! By the time I might figure this out it will be the normal DST anyway :)

[Narf54321]

A guy on TCF (jberman) already got a workaround running as part of a cron job. Apparently clever enough that Tivo Inc. is going to roll it into some sort of update (http://www.tivocommunity.com/tivo-vb/showthread.php?t=344459) for S1SA owners.

Anyway, jberman's "Timezone hack (http://www.tivocommunity.com/tivo-vb/showthread.php?p=4954286&&#post4954286)" (linked) involves a couple of scripts run through cron which set an MFS setting called TimeZoneOld. The values from DbEnum.tcl are still there, so it might work on an S2.

[kkolarik]

While the guide data is accurate to real time, the RTC is an hour behind. I see now that this isn't worth worrying about. Evidently, it only is an issue if you set record times manually, ignoring both the guide and the fact that you are on XDT vs. XST (X being your time zone, D meaning Daylight.... S meaning Standard)

[mateom199]

nope...didn't work... On reboot, it still changed the TimeZoneOffset back to -21600

Oh well! By the time I might figure this out it will be the normal DST anyway :)

You might want to take a look in the various startup scripts, there might be a DTV specific area that sets the clock from the sat.

Could be as easy as commenting out a few lines....but it may be hardcoded in tivoapp/dssapp

[kumashi]

Yep, that's exactly where it is at on the S2.5 R10:
LocationConfig 7225/10 {
Version = 33
PostalCode = 61821
TimeZoneOffset = -21600
IndexPath = /State/LocationConfig
}

So....presumably I can change my postal code to another timezone someplace to the east and see what happens... I'm wondering if I'll loose my locals....we'll find out, I'll keep you all posted.You should leave your postal code alone. Instead, start with jberman's scripts (http://www.tivocommunity.com/tivo-vb/showthread.php?p=4954286&&#post4954286), and wherever it says TimeZoneOld change it to TimeZoneOffset. Also, in the DST_on.tcl script you should be setting TimeZoneOffset to -18000 (that's -18000 seconds from GMT, a.k.a. GMT-5), and in DST_off.tcl the TimeZoneOffset should be set to -21600 (a.k.a. GMT-6). The relevant lines should end up looking like this:

in DST_on.tcl: dbobj $setup set TimeZoneOld -18000
in DST_off.tcl: dbobj $setup set TimeZoneOld -21600

Then follow the rest of the instructions in jberman's post (you'll need to run DST_on.tcl three times a year and DST_off.tcl once a year; preferred way of doing this is setting up a cron job, as outlined in this followup (http://www.tivocommunity.com/tivo-vb/showthread.php?p=4954817&&#post4954817) to the original post), and you should be fine. Please report your results though!

By the way, I am jberman. kumashi is just another name I sometimes use in other forums. No foolin'! :D

[gwar11d2]

Still a no go....crap. I think the key _could_ be this line:
event send $TmkEvent::EVT_DATA_CHANGED $TmkDataChanged::SCHEDULE 0
in Jberman's scripts... It seems as though those variables don't exist in the library's on the r10... Anyway, thanks for the help!

[Narf54321]

Still a no go....crap. I think the key _could_ be this line:
event send $TmkEvent::EVT_DATA_CHANGED $TmkDataChanged::SCHEDULE 0
in Jberman's scripts... It seems as though those variables don't exist in the library's on the r10... Anyway, thanks for the help!

Yes, this is the same issue with MFS_FTP (and a few other tools), where EVT_DATA_CHANGED stopped working after Tivo System v.5 or so.

You should comment out that line of the script.

[kumashi]

Still a no go....crap. I think the key _could_ be this line:
event send $TmkEvent::EVT_DATA_CHANGED $TmkDataChanged::SCHEDULE 0
in Jberman's scripts... It seems as though those variables don't exist in the library's on the r10... Anyway, thanks for the help!That line just rebuilds the ToDo list. I think you should be able to do the same thing by adding a new recording... or possibly rebooting the TiVo... or it may just happen on its own, eventually. I'm not sure.

In any case, Narf54321 is right - you can safely comment out this line and the script should still work. Just give your TiVo some time to reindex.

[djl]

I'm working on a module that reads records from elseed.log, and realized that even after the 6.2a upgrade the times listed for caller-id are still off by an hour. Does anyone know where elseed gets its time information, and if there's any easy fix? Elseed.conf doesn't seem to support any time zone parameters.