Timers one hour out

[Vortical]

That might be because they have already been advised of them.

I'm sure once they are fixed a brief message will be posted.

[futzle]

I don't understand! If timers are stored in local time, and as a user I want to record a show that is due to start at say 1:00pm Tuesday 1/11, ie. my local time of 1:00pm, what has DST got to do with it? If the desired local time is stored then as long as the PVR has the correct time, the timer will fire correctly, right?

Hi John,

I don't pretend to speak for IceTV, but I'll try and give some examples that might explain why, if I were in their position, I'd make the same decision and do everything in UTC.

Thought experiment #1: Imagine that I'm a fan of the 4 am American evangelical TV shows and record them all to watch at a more reasonable time.  I'm not prepared to get up and change the local time on the PVR at 3 am, after DST has started.  I am also not prepared to set the clock forward when I go to bed, because I am also a SF fan and need to record whatever incarnation of Star Trek is on "After Nightline".  (If this seems too far-fetched, then imagine that I am away for a week around DST changeover day.)  Unless my PVR knows to swap over automatically, then one of those recordings is going to be wrong.

Rule #1 of Time Zones: No matter what, the PVR has to know the daylight saving rules.

Religiously adhering to storing timers in local time, and having the PVR know only about local time, just isn't going to help here.

The sad fact is that most PVRs, in the long term, fail to satisfy Rule #1 of Time Zones.  Only a heavyweight solution like Tony's timezone code in EPG_Uploader (which is essentially the same as what all Unix systems do) is likely to be future-proof enough to withstand the harebrained whims of our dear governments.

Thought experiment #2: Imagine that I live near a timezone boundary.  It might only be a timezone boundary for part of the year.  There isn't really a place in Australia that demonstrates this well.  Perhaps the best is the NSW/Queensland border around Tweed Heads, or the extreme SE of South Australia around Mt Gambier or Naracoorte.  I receive TV broadcasts from both sides of the boundary.  For some of those broadcasts, my local time is the same as the broadcaster's.  For others, my local time differs (either because I am observing different DST to the broadcaster, or because I am across a permanent timezone boundary).  The guide data I get from these other broadcasts is going to be wrong *for me*, but it's right for the broadcaster.

Rule #2 of Time Zones: "Half an hour earlier in Adelaide" does not mean I can cheat the lottery by watching Adelaide broadcasts.

So if I get my guide from the broadcaster in the broadcaster's local time I have to know the DST and timezone rules for every broadcaster that I receive (which, for satellite TV, could easily be the other side of the world).  In the general case, converting a local time from one timezone to the other is best done by converting the first timezone to UTC, and then converting UTC to the other time zone.  Because of Rule #2, UTC is, in the general case, unavoidable.

For many people, me included, Rule #2 is hard to notice.  Anyone in the Eastern Standard Chauvinist Time zone in Australia barely thinks about it unless they are watching the Second Test at the WACA.

With so many variables, some of the time zone processing decisions really have to be delegated down the line, not done by the EPG provider but by the PVR, which knows where it is, and so ought to know its own time zone.  There are parallels here with other discussions I've seen about what IceTV does or doesn't do: Why doesn't IceTV Interactive merge adjacent timers on the same channel?  Why doesn't IceTV Interactive alert you when you have too many timers and not enough tuners?  Why doesn't IceTV interactive handle before-and-after padding?  The answer's the same: those are things that IceTV has decided are the responsibility of the PVR (or its operator).

Anything that IceTV adds to the guide data to try to cope with all of these variables is like adding epicycles to the heliocentric model of the solar system: eventually the system gets so convoluted that it's unavoidable to change your point of reference.  None of these problems comes up if the guide data is maintained and disseminated in UTC.

One thing I agree with you on is that the end user shouldn't really be having to think about time zones, that it should Just Work.  Unfortunately, PVR manufacturers are often still of the opinion that it's OK for users to be manually setting the clock forward or back an hour, as if the PVR were a microwave oven.  PVR manufacturers, please pay attention: It's Not OK.  You cannot cut corners with DST, and you cannot assume that this year's rule is going to occur in perpetuity.  Please Do It Right.

(I should mention that I once wrote a timezone library for a MUD, and I tried to cut corners, which is why I learned the lessons that I am trying to teach here.  That's why I feel qualified to speak about this issue.)

[tonymy01]

At first thought, you would think "oh great, don't have to worry about DST garbage if you send the timers as UTC", but the issue is that a program that starts at midday UTC non-DST starts at 11am UTC DST.... so that doesn't work too well if the unit clock doesn't update also.   Also all PVRs I have played with (all 3) store and display their timers in localtime, so they have to conver the UTC to localtime anyway, and it is asking a bit much to have the logic for a PVR to not only adjust the clock at the correct date/time each year, but to also have the logic to know when in future that correct date/time is and to add the correct offset so that the timers have the correct localtime pre and post DST.
I think the best solution is for ICE to send the timers as UTC (as their whole database for EIT is UTC which is the correct standard for EIT anyway), but to also include a GMT offset parameter with the timer data, and then the PVR can much more simply just add the offset if the PVR stores timers in localtime, then everyone is happy.
Then all you need is for the PVR to correctly adjust its clock at the right time, and then everything will be in order.
Regards

[tonymy01]

I finally got some PM feedback from ICE (in answer to a PM I sent them, sorry mate, hope your new life change is working out!)
I can explain one phenomenon we got during the DST transition anyway now.
When all my timers were out by 1hour, I deleted all of them from the Wiz gui, and then followed the ICE FAQ to "resend all timers to device" which failed.
Turns out that the act of deleting the timer on the Beyonwiz cancels the timer for that week at ICETV also.   So "resend all timers" ends up sending nothing for any of the timers you deleted.    The only reason I deleted them is I figured they would cause some serious clashing due to trying to create a second set of timers one hour after the first (but I have lots of overlaps as it is most nights now).
Thus why the series record is still working (and this week all my timers are back), but ICE assumes you don't want to record it for that week because you deleted it from the PVR.   This feature is pretty good actually, as sometimes you don't want an ICE uploaded show to record that you spot when checking out the PVR guide for the next week (to avoid a clash for a more important show, or you spot it is something you have seen before or whatever), so it would be annoying to delete the timer and find it back again the next day.
But... this meant that every program I deleted the timer for (approx 20-30!!), I had to go into the ICE Interactive interface and choose the "record" option (and I forgot to do this on a couple of shows grr), which is the only option apart from cancelling the series record.
I think there is still a synch time issue, as in the past when I change a timer, it usually takes a week before things start running smoothly again (i.e. trying to get that red dot to show again isn't always successful even if you use the "record" option).
See, if these things are explained in detail (this is what I mean by "I wish they would explain the protocol to us"... I didn't mean to give away all their bits/bytes secrets so we could reverse engineer it or anything), then it would certainly reduce the heartache and confusion with trying to deal with all the quirks of this thing.
I know it is a learning process for them too, as each PVR has its own idiosynchrasies with dealing with ICE data I think...
Regards

[prl]

...
See, if these things are explained in detail (this is what I mean by "I wish they would explain the protocol to us"... I didn't mean to give away all their bits/bytes secrets so we could reverse engineer it or anything), then it would certainly reduce the heartache and confusion with trying to deal with all the quirks of this thing.
I know it is a learning process for them too, as each PVR has its own idiosynchrasies with dealing with ICE data I think...
Regards

The IceTV online descriptions of what the service does are very sketchy, and really totally inadequate when it come to trying to work out the cause when something unexpected happens.

For this problem, it doesn't help much that the "All of my timers are incorrect now that daylight savings is in effect." FAQ says that on PVRs that use IceTV Interactive (and Beyonwiz is named amongst them), the way round the problem with the timers is to "delete the timers and then have IceTV Interactive send all the details back down to the PVR", which will trigger exactly the behaviour that you describe.

It also doesn't help when the undated Series recordings with specific time not being scheduled correctly since daylight savings has come into effect carries a message like "We are working on the issue and hope to have this fixed shortly". Shortly with reference to what?

[tonymy01]

Exactly Peter.   You make assumptions about how things work based on FAQs and the like, and then when it behaves differently to this, it is hard to work out what is the issue and then you realise the underlying assumption was wrong.
I am guessing that FAQ about "why are my timers out by one hour" (which I read prior to doing anything also when I found the same) was either written by an ICE person who doesn't understand the protocol, or written based on some past behaviour about how an older version of interactive might have behaved.

I actually found that FAQ when I used their search engine to try to work out how to resend all timers, as I had read in the past people had used this option, but couldn't find it in any of my normal interactive pages (turns out it is in the account settings area)....   something else non-intuitive about interactive LOL.
Regards

[prl]

...
It also doesn't help when the undated Series recordings with specific time not being scheduled correctly since daylight savings has come into effect carries a message like "We are working on the issue and hope to have this fixed shortly". Shortly with reference to what?

This has now been updated to "Series recordings with specific time not being scheduled correctly since daylight savings has come into effect. (Updated - Fixed)", and the text indicates that that problem has been fixed. Thanks, IceTV!

The advice in "All of my timers are incorrect now that daylight savings is in effect." is unchanged.

[tonymy01]

Yeah I clicked your link yesterday and didn't get the same info that you said it had.   Would have been nice to get a bit more substance on what the issue was and what approximately was the fix...(again, I am not asking ICE to give away bits & bytes protocol secrets here, just the basic "ok, our system didn't auto adjust the entries correctly for the DST transition, now we look at the future timezone transition information and individually adjust the entries so this issue should not ever happen again if you select your correct timezone in your profile" or some such info like that).
But it is easy to fix the issue after the DST transition, ICE simply ticks the box that says "subtract one hour from the previous GMT time to get the new show time" once the DST transition has happened and everything is good again (assuming this was the problem in the first place, I am not so sure about that).  But will the issue come back when DST finishes?  Does their system actively look at EPG before and after the transition point, and do the correct ammendment to the entry prior and after the transition?  We will have to wait till March and see...
Regards

[deangelj]

I think the best solution is for ICE to send the timers as UTC (as their whole database for EIT is UTC which is the correct standard for EIT anyway), but to also include a GMT offset parameter with the timer data, and then the PVR can much more simply just add the offset if the PVR stores timers in localtime, then everyone is happy.
Then all you need is for the PVR to correctly adjust its clock at the right time, and then everything will be in order.

But ICE would say, "here's the data in UTC with a GMT offset - go calculate the localtime, mr PVR", and the PVR manufacturers are saying "well, why don't you just give it to me already calculated! - I don't care about UTC and offsets..." -both are equally valid and both solve the issue at hand.

In reference to "futzle"'s post, requiring the PVR to know (in perpetuity) every DLS rule and changes to those rules a government is likely to think up just isn't going to work.

cheers
John

[tonymy01]

But, over on Free TV, there is an excellent paper on what they say is mandatory in Australia for the broadcasters to send both a TDT (time & date table, the standard one that most STBs use) and a TOT (time offset table, which includes T&D and also GMT offset and the next transition time... perfect, if the pimply work experience kids configuring their equipment knows that GMT isn't an old AC/DC song).
So one day we can hope that a STB doesn't need brains as the broadcaster is going to send what their own silly organisation is insisting should be mandatory...

http://www.freetv.com.au/media/Engineering/OP45_Application_of_Time_Related_Tables_in_Australian_DVB-T_Systems_Issue_3_September_2008.pdf

"While ETSI EN 300 468 [2] indicates that this table is optional, the Australian
practice is for this to be mandatory."... pity it doesn't discuss the accuracy of it should also be mandatory..

The TDT certainly does "Broadcasters must transmit this table in SI of their DVB-T transport stream and ensure that it is derived from a reliable time standard, e.g. global positioning system, to present an accurate UTC time reference to receivers."
but fat lot of good that does when the TOT is what derives the STB GMT offset, local time, next DST transition time etc.
Regards

[futzle]

But ICE would say, "here's the data in UTC with a GMT offset - go calculate the localtime, mr PVR", and the PVR manufacturers are saying "well, why don't you just give it to me already calculated! - I don't care about UTC and offsets..." -both are equally valid and both solve the issue at hand.

That would work *if* rules were adhered to by all parties.

1. PVRs switch on or off DST when the change actually happens, and not when the user goes about the house changing the clocks on the walls and microwaves the night before or the morning after. 
2. PVRs be especially careful of timers set for the hour that repeats itself between 2 am and 3 am in Autumn, and fire them off only when the current GMT offset matches the GMT offset of the timer (otherwise they will start an hour early).
3. The local time and GMT offset in the guide data are correct for your location, not the location of the broadcaster.  As I said in my previous post, this is not much of an issue in Australia because of geography, but in other parts of the world it's vital.  This you'd need to set at the IceTV end.
4. PVRs that go to sleep and wake up for the next timer don't do it by naively subtracting future-local-time minus current-local-time and sleeping that many seconds, but note if there is a DST transition in between.
5. PVRs either work strictly with timer durations, or don't assume that the end time of a timer is in the same time zone as its start time.

Considering that no PVR I have owned even handles rule 1 right without after-market software, I doubt that manufacturers comprehend why rules 2 to 5 are even necessary.

Digression: It occurs to me how silly it is that we expect our PVRs to know the local time.  If we all used PVRs like true PVRs, and just have them record the things that we select in IceTV Interactive, then who cares what time is displaying on its front panel?  Perhaps this anxiety about local time is a vestige from when we all had VCRs and were programming manual timers from a paper TV guide.  I reckon that the way many of us use our PVRs, they'd be just as functional set to UTC, and we wouldn't be needing to have this conversation.

[prl]

...
Digression: It occurs to me how silly it is that we expect our PVRs to know the local time. ...

I still want to be able to see timers in local time, set manual timers in local time, and have the EPG display in local time.

The Beyonwiz system clock runs UTC, not local tme. I'm not sure about the Topfields.

[Daniel Hall at IceTV]

To confirm a few things:

* Timers and Guide data are sent down from the IceTV server in UTC.
* Daylight savings time is taken into account when sending down timer and guide information.

As this is the 'correct' way of doing these according to the EIT specification (and there are systems on the market now that work without flaw during daylight savings cross overs) we are not looking at changing this.

We are however looking at how the re-send timers functionality is handled on the Beyonwiz and Topfield ends to confirm how timer updates are handled, if they are handled incorrectly then we will be feeding this information back to both companies to look at. What we are looking at is on the day of the cross over when the timezone settings are changed on the recorder that the re-send recordings option is selected as well to re-send all recordings, this will then update the recordings on the recorder to be at the correct time without having to have them be deleted.

[prl]

Because the Beyonwiz PVRs (and, I think, the Topfield 7x00 HD PVRs) don't use either the Unix zoneinfo system (they both run variants of Linux) nor the DVB-T Time Offset Table (TOT) to translate between UTC and local time, and also as a consequence, require manual intervention to switch between DST and standard time, it is very difficult (perhaps impossible) to always get local times displayed as they might be reasonably expected to be displayed

The zoneinfo files hold all the information for past time zone and DST changes, and can also give correct future local times as far as future DST changes are known, are not changed, and are entered into the files. The TOT provides information about the current time offset (time zone + DST if applicable), the next time offset change, and the next time offset (or offsets, it allows for the signal being received in multiple time zones and DST regimes). The TOT is a little more limited in capability than the zoneinfo files, but it has the advantage that it is (or should be) always current as long as a DVB-T signal is being received (in Australia at least, the normally optional TOT is stated as mandatory by the voluntary standards promulgated by FreeTV; see tonymy01's earlier pose for a link)

[Daniel Hall at IceTV]

I have just confirmed that the Beyonwiz does update the tasks correctly if resent after updating the timezone settings. So the best steps are to change the timezone on the Sunday morning and then select the "Resend all recordings" via the My Account section of the website, then all timers will be updated to have the correct local time.

(The FAQ entry has been updated to reflect this as well)
http://www.icetv.com.au/cgi-bin/websupport.cgi?op=show_faq&faq_id=144&faq_cat_id=2