1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

New Daylight Savings Time Update for Series1

Discussion in 'TiVo Coffee House - TiVo Discussion' started by TiVoPony, Mar 14, 2007.

  1. Mar 15, 2007 #81 of 277
    BTUx9

    BTUx9 back?

    1,596
    0
    Nov 13, 2003
    Rockport, MA
    the phone call just connects to an internet access point... the 2 types of calls are functionally equivalent once connected to the network.
     
  2. Mar 15, 2007 #82 of 277
    Joe Smith

    Joe Smith Medium Member

    100
    0
    Aug 1, 2003
    North...
    Since TiVo is running Linux, I expect it uses the old POSIX way of translating GMT (seconds since 1-Jan-1970) to human readable form. Unlike Microsoft, which has a single rule that is used for all dates (past and future) regardless of year, the POSIX way has a set of several rules. Each rule includes a definition of which year the rule was active.

    The Now Showing list does not have a DST flag, does not have the local date/time of when the recording started. It has the time of recording stored in GMT. When you bring up the Now Showing list, all those times are converted to local time using a specific set of rules and the timezone + DST preferences.

    The proper fix is going to be a change to the set of rules for calculating when DST starts/ends. Either in a shared library or in the TiVo app itself. Then, when the settings are reset to actual timezone + DST preferences, all the old dates will be displayed correctly. That includes programs recorded a year ago that when the 1987 to 2006 rule was in effect.
     
  3. Mar 15, 2007 #83 of 277
    wickerbill

    wickerbill Member

    153
    0
    Apr 3, 2002
    Tulsa, OK
    Thanks for doing this. It's nice to see Tivo taking care of their customers, even if it's a little late. I still love my series 1 so it's nice to see that Tivo's still supporting it.
     
  4. Mar 15, 2007 #84 of 277
    TiVoJerry

    TiVoJerry 00-16 TiVo Employee

    1,511
    0
    Jul 26, 2005
    Alviso, CA
    One thing to note: the connection that downloads this update will not display as "succeeded". It will show something to the effect of "loading. phone not in use" up until the time it reboots (3am in this particular instance). If you want to restart it yourself, I suggest waiting at least 15-30 minutes after this status is displayed just to play it safe.
     
  5. Mar 15, 2007 #85 of 277
    Tivo_Terry

    Tivo_Terry New Member

    6
    0
    Dec 9, 2005
    Just like the Social Security Trust Fund. :eek:
     
  6. Mar 15, 2007 #86 of 277
    Tivo_Terry

    Tivo_Terry New Member

    6
    0
    Dec 9, 2005
    Does it matter if the Series 1 was originally setup with PTVupgrade's InstantCake software, instead of the official Tivo software?

    Will the fix kill any of the InstantCake functionality (hacks)?
     
  7. Mar 15, 2007 #87 of 277
    pokegol

    pokegol New Member

    306
    0
    Feb 24, 2003
    Chicago
    I'm thinking of taking an image backup of my TiVo after the DST patch loads. That way if the hard drive craps out, I won't have to remember to reapply the DST patch (if its even still available at that time).
     
  8. Mar 15, 2007 #88 of 277
    BobCamp1

    BobCamp1 Active Member

    1,383
    18
    May 15, 2002
    OK, I'm signed up, and my S1 has never been fixed and is running the original kernel. Do you want me to have manual recordings for any specific times? (I'll put some back in, maybe around the 3am time TivoJerry mentioned earlier, and my regular ones.)

    Also, I think the ReplayTV server sends the DST & timezone info. during guided setup. Modifying that WOULD be a good solution, as it would not impact UTC. Replay users had to just rerun guided setup, and that fixed their units. ReplayTV also had the advantage (?) of having ALL of their units have the same bug, so they could monkry around with the guide data as a plan B.

    If Tivo POPs can't distinguish between S1s and the other units, they can't monkey with the guide data at all.
     
  9. Mar 16, 2007 #89 of 277
    jberman

    jberman Mostly Harmless

    102
    0
    Oct 1, 2002
    Great post, very informative. Thank you! :D
     
  10. Mar 16, 2007 #90 of 277
    bicker

    bicker bUU

    10,401
    44
    Nov 9, 2003
    Georgia
    Nah, it's not worth it. I don't really use the S1 at all. I was just interested in perhaps keeping it up-to-date in case I want to sell it or give it away. Again, it was just an idle question. If the answer was "yes" then I'd dig the thing out and make a phone call. Otherwise, no problem.
     
  11. Mar 16, 2007 #91 of 277
    bicker

    bicker bUU

    10,401
    44
    Nov 9, 2003
    Georgia
    Okay, so if we have an unsubbed box, we just need to sign up, make a call, and it will get the fix?
     
  12. Mar 16, 2007 #92 of 277
    joblo

    joblo Member

    98
    0
    Jun 5, 2002
    Yeah, I’d been offline a few days, so the first notice I got of this new workaround came from a message on my TiVo, but when I went to tivo.com and read that caveat, I knew immediately, even before I read it here, that this update was based on your ideas and the ensuing discussions in these forums. (Kudos to TiVo, Inc. for being honest about that, though!)

    I’m just guessing at this point, of course, but it looks like TiVo’s engineers are basically doing a server-side implementation of your scripts, and then pushing TZ/DST info to the boxes as part of the daily calls. This could be done as follows:

    If, while DST is in effect (currently second Sunday March to first Sunday November), an “upgraded” box reports to the server that DST is enabled on that box, a server-side DST flag would be set, and the unit would be told to advance its TZ an hour and turn off DST. Turning off DST on the box would remove guide discrepancies at the old change dates in April and October and disable further TZ adjustments from the server.

    The server side flag, meanwhile, could only be cleared by rerunning GS, which would cause the unit to revert to its original understanding of TZ/DST until the positive DST flag caused the server to adjust it again during the next daily call. (It would be more seamless if the TZ manipulations were restored by the second GS call, itself, of course; it’s not clear whether this is impossible because the box does not report TZ info during setup – it wouldn’t have to, I don’t think – or whether this is simply a work in progress and that will come later. The caveat does say “may”, not “will.)

    On the first Sunday in November, the server would push correct TZ info to those boxes whose server side flags are set, including turning on the DST flag on the box itself to disable further updates, as in the Spring. And so on, ever after, whenever the time actually changes, as may be determined by Congress.

    The nice thing about such a workaround is that it’s version independent and relatively safe, because it doesn’t require updating any files on the boxes at all. As long as you can push TZ/DST settings to the boxes from the server, you’re all set.

    But let’s be clear that this IS a workarounds, not a fix. Guide times will still be wrong around time change dates. Joe Smith is right that a “proper fix” would require changing the logic by which DST start/end dates are determined. But I also think BTUx9 is right that, unfortunately, this logic is buried deep in the app where it’s inaccessible to o.s. or server manipulation, so we may never see a proper fix.

    That said, many thanks to jberman and to TiVo for the workaround!
     
  13. Mar 16, 2007 #93 of 277
    technomutt

    technomutt New Member

    103
    0
    Jun 14, 2004
    Going from the sublime to the completely ridiculous, I must ask: Will this include a fix for the Year 2038 problem?

    http://en.wikipedia.org/wiki/Year_2038_problem

    Gee, how many Series 1 units will still be alive then???? :eek:
     
  14. Mar 16, 2007 #94 of 277
    jberman

    jberman Mostly Harmless

    102
    0
    Oct 1, 2002
    Very well described. The only thing that I would add is that, if you're right, presumably the displayed time will still be an hour off between 2 am on the old DST change date (this coming October 28, for example) and the next time you do a daily call. Not a big deal to people who call in every day, but if that is the case, it's somewhat bad news for people who are using their boxes as digital VCRs, who would now need to call in four times a year to have the clock corrected. Still a vast improvement over the previous situation, though! :up:
     
  15. Mar 16, 2007 #95 of 277
    gastrof

    gastrof Hubcaps r in fashion

    7,481
    0
    Oct 31, 2003
    Potato and pen.
    JB...

    A question if you please. (TiVoJerry and TiVoPony are free to answer as well.)

    As far as you can tell, will this change that TiVo's implementing cause any problems for people with larger drives that were given the "kernel" difference some people are talking about?

    According to Weaknees, their ready-to-go drives don't change the kernel, so machines using them should be safe.

    Problem is, I'm only certain about one of my machines having a Weaknees drive.

    The other was upgraded by the previous owner, and I have NO idea what method he used.

    If that one's kernel WAS changed, am I in trouble with your/TiVo's DST update method?
     
  16. Mar 16, 2007 #96 of 277
    BTUx9

    BTUx9 back?

    1,596
    0
    Nov 13, 2003
    Rockport, MA
    It's been posted (by one of the tivo ppl) that the fix will NOT interfere with lba48 kernels.
     
  17. Mar 16, 2007 #97 of 277
    gastrof

    gastrof Hubcaps r in fashion

    7,481
    0
    Oct 31, 2003
    Potato and pen.


    Thank you.
     
  18. Mar 16, 2007 #98 of 277
    joblo

    joblo Member

    98
    0
    Jun 5, 2002
    No, that will happen at the new change date in November, not the old change date. Everything should function normally at the old changes dates, both Spring and Fall, because the internal DST logic should be disabled on the box at both of those times.

    Well, if they disable the internal DST logic as I’m suggesting, it should only require two calls a year, not four. But I have three such unsubscribed boxes, and my plan for those boxes was to rerun GS twice a year unless/until I got around to hacking them to the point where I could use your scripts. So even for those boxes, I think this is indeed an improvement! :up:

    Re potential display and recording errors between the actual time changes and the subsequent daily call, there are several ways that could be handled, and TiVo has until November to settle on one.

    The first and best way, if possible, would be to delay any pushed TZ/DST change events so they don’t take place until the actual time change at 2 am. Although cron isn’t part of the S1 software, the whole app is schedule based, so perhaps there’s a similar scheduling mechanism within the app that they could use. We know they can schedule reboots at 2 am, whether they can delay other events, I don’t know.

    I do think it’s important not to tie a TZ change solely to reboots, though, because you don’t want a daily call on Saturday morning or afternoon to schedule a reboot for TZ update at 2 am Sunday, only to have the time change early Saturday evening because there’s thunderstorm and a power flicker. People expect things to go wrong immediately after a time change, so they’ll tend to be forgiving about that. But they don’t expect things to go wrong before the change, so that would be more likely to increase the volume (pun intended) of complaint calls to CSRs. Plus Saturday evening is date night, when people are most likely to be depending on TiVo to do their TV watching for them.

    A second thing TiVo might be able to do is cluster daily calls in the 2 am to 6 am timeframe. Replay does this all the time, but perhaps TiVo could do it only for the time change dates in March and November, and if server load is a concern, perhaps they could disable program downloads during those time periods, so that the servers could handle a higher volume of calls at those times.

    A third option would be to simply message people that the time display and repeating manual recordings might not be correct until Sunday’s daily call, and advise those with manual repeating recordings on Sunday morning to force a daily call early on Sunday.

    Or fourthly, they could re-enable the clock setting functionality in the test calls and add TZ/DST pushing to those, so that people with affected recordings could make test calls on Sunday morning and/or the servers could force 2 am test calls instead of reboots or daily program calls.

    As I said, TiVo’s engineers have many months to consider their options, but I think any forum readers who have ideas about this should definitely post, because it sure looks like they could use all the help they can get.
     
  19. Mar 16, 2007 #99 of 277
    jberman

    jberman Mostly Harmless

    102
    0
    Oct 1, 2002
    Oh yeah, you're right. You know, I spent a lot of time working on the effects of this DST change in the healthcare environment, and sometimes I still have trouble wrapping my mind around all the details!
     
  20. jberman

    jberman Mostly Harmless

    102
    0
    Oct 1, 2002
    Yup... and if the fix that TiVo's implementing is anything close to what joblo outlined (which makes a lot of sense), you shouldn't have to worry about your kernel.
     

Share This Page