Yesterday on interactive i noticed some strange timers that i had not ever set.
They seem to be one hour early than series recording on the same channel.
eg. House wed 8.30 ten sd (this is a known series recording)
Bondi rescue wed 7.30 ten sd (never set this to record)
Kenny's World wed 8.00 ten sd (never set this to record)
House timer shows no icon, but bondi and kenny's world show the once off record icon.
Today i set topgear Aust to record , refresh screen topgear aust has no icon but two shows
one hour later on sbs have record once icons next to them.
eg. topgear aust mon 7.30 sbs (no icon, this was set to record)
South park mon 8.30 sbs (record once icon, i never set to record)
Bogan pride mon 9.00 sbs (record once icon, i never set to record )
Thanks Juzzman, I was about to post on exactly the same thing.
I was trying to set Spicks and Specs to record tonight but I'm getting the 7.30 report instead.
I'm guessing it has something to do with day light savings starting this week.
Unfortunately I can't check till i get home whether it has updated correctly.
There were some similar reports on the DTV forum (http://www.dtvforum.info/index.php?showtopic=54965&view=findpost&p=1175266). It looks like one of the Sydney broadcasters was transmitting times that were an hour out.
We are currently looking into this issue.
This however looks like be just a display issue at this stage, the timers are being set correctly in the database, but for some reason they are being displayed incorrectly in the Upcoming Shows page and TV Guide pages of IceTV Interactive.
That was what my mind jump to daylight savings , but surely after
what happened last change it cant be happening again.
DLS hasn't started yet.
Quote from: prl on October 01, 2008, 11:21:43 AM
There were some similar reports on the DTV forum (http://www.dtvforum.info/index.php?showtopic=54965&view=findpost&p=1175266). It looks like one of the Sydney broadcasters was transmitting times that were an hour out.
But this was on ice interactive site, before any timers had been sent to my Beyonwiz.
Quote from: juzzman on October 01, 2008, 11:26:02 AM
That was what my mind jump to daylight savings , but surely after
what happened last change it cant be happening again.
DLS hasn't started yet.
Quote from: prl on October 01, 2008, 11:21:43 AM
There were some similar reports on the DTV forum (http://www.dtvforum.info/index.php?showtopic=54965&view=findpost&p=1175266). It looks like one of the Sydney broadcasters was transmitting times that were an hour out.
But this was on ice interactive site, before any timers had been sent to my Beyonwiz.
You're right. Sorry, I didn't read carefully enough.
The good news is that this display issue has been resolved now so all timers should be showing up correctly under the IceTV Interactive webpages.
Quote from: Daniel Hall on October 01, 2008, 03:10:14 PM
The good news is that this display issue has been resolved now so all timers should be showing up correctly under the IceTV Interactive webpages.
Thanks Daniel for the speedy fix, it was getting hard to follow what was set and what wasn't.
Just be warned everyone! My beyonwiz timers for this week, all the ones created by ICE prior to last night, are all one hour too early. Only timers created today are correct. So it looks like ICETV uses a fixed GMT offset and doesn't adjust the offset "in advance" for DST. So you need to delete all your timers and get them resent, and then everything is back to normal.
It certainly wasn't adjusting the Wiz clock by one hour that has anything to do with this, as I have a daily "wakeup" timer for 4am that is still at 4am. So it is clearly timers set by ICE interactive that obviously used a 10hour offset despite the timers being for a time when the 11hour offset should be in place. Once the DST transition happened, it appears that ICE interactive correctly uses an 11hour offset.
Regards
Quote from: tonymy01 on October 05, 2008, 07:50:13 PM
Just be warned everyone! My beyonwiz timers for this week, all the ones created by ICE prior to last night, are all one hour too early. Only timers created today are correct. So it looks like ICETV uses a fixed GMT offset and doesn't adjust the offset "in advance" for DST. So you need to delete all your timers and get them resent, and then everything is back to normal.
It certainly wasn't adjusting the Wiz clock by one hour that has anything to do with this, as I have a daily "wakeup" timer for 4am that is still at 4am. So it is clearly timers set by ICE interactive that obviously used a 10hour offset despite the timers being for a time when the 11hour offset should be in place. Once the DST transition happened, it appears that ICE interactive correctly uses an 11hour offset.
Regards
Please see http://www.icetv.com.au/cgi-bin/websupport.cgi?op=show_faq&faq_id=144&faq_cat_id=2 (http://www.icetv.com.au/cgi-bin/websupport.cgi?op=show_faq&faq_id=144&faq_cat_id=2).
The problem is that the Beyonwiz (and Topfield TF7100HDPVRt) are not fully daylight savings aware, so it will apply the same timezone to all timers and guide information for the entire week, so while the timers that were previously sent down before today (the day of the change) for today or after were sent down with the correct +11 timezone the PVR was only applying the old +10.
See Daniel, if you detailed your protocol in full we can lay the blame to the appropriate people. So what you are saying is that the timers that ICE send the PVR are in GMT only. This is a recipe for problems as it means the PVR has to not only auto adjust for DST, but to understand that "this timer is in 4 days time, which is 2 days after the DST transition, and thus I have to adjust the time for the entry with an extra hour".
If the protocol for how timers were determined, updated, deleted, uploaded, we might have some idea about how to get the best out of interactive. I deleted all my timers on the Wiz and ICE interactive simply refuses to update the timers now (and I followed the FAQ on how to go into your account details and trigger the timers to get resent. It has only sent about 4 timers and I had about 24timers, including sending 2 timers for last night).
So this whole mess needs some more thought I think. Probably your timers, if they are sent in GMT time, should also have a GMT offset info to be sent with the timer info, and the PVR can use this offset info to determine what time to set the timer for.
Regards
While I agree with Tony that it's important for this information to be easily available to users, I wanted to applaud the use of UTC as the basis for IceTV timers. Working with local time is fraught with difficulty, especially when DST ends (Example: there are two instances of 2.30 am on Sunday 5 April 2009 where I live). I place the blame for this mess squarely with the PVR manufacturers, who insist on storing timers in local time without really understanding that the same local time-of-day isn't always a multiple of 24 hours away. Well, also, I blame capricious government bodies for failing to make a rule and stick to it. Also Benjamin Franklin for getting the silly idea in the first place. But I digress.
Unfortunately there are an awful lot of PVRs out there with dodgy DST code. (I happen to be the owner of one that's pretty good now, thanks to EPG_Uploader.) Including an offset attribute (like "+600" or "+660") might be a simple hack that could help PVRs without the brains (or with old unmaintained firmware) to work out this year's DST rule for themselves, but my homebrew EPG code will continue to ignore it and work with UTC as God intended.
(I can't get the damn "re-send timers" to work either, FWIW.)
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?
cheers,
John
any comment from icetv staff?
cheers,
John
Unfortunately not, and I have complained until I have been blue in the face on some of the quirks that make this experience less than brilliant, with zero response. I pm'd Daniel with my thoughts during the week, with zero response also.
Regards
That might be because they have already been advised of them.
I'm sure once they are fixed a brief message will be posted.
Quote from: deangelj on October 08, 2008, 08:12:25 AM
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.)
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
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
Quote from: tonymy01 on October 14, 2008, 10:36:06 AM
...
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. (http://www.icetv.com.au/cgi-bin/websupport.cgi?op=show_faq&faq_id=144&faq_cat_id=23)" 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 (http://www.icetv.com.au/cgi-bin/websupport.cgi?op=show_faq&faq_id=143&faq_cat_id=23) carries a message like "We are working on the issue and hope to have this fixed shortly". Shortly with reference to what?
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
Quote from: prl on October 14, 2008, 11:04:25 AM
...
It also doesn't help when the undated Series recordings with specific time not being scheduled correctly since daylight savings has come into effect (http://www.icetv.com.au/cgi-bin/websupport.cgi?op=show_faq&faq_id=143&faq_cat_id=23) 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) (http://www.icetv.com.au/cgi-bin/websupport.cgi?op=show_faq&faq_id=143&faq_cat_id=24)", 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. (http://www.icetv.com.au/cgi-bin/websupport.cgi?op=show_faq&faq_id=144&faq_cat_id=23)" is unchanged.
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
Quote from: tonymy01 on October 12, 2008, 11:54:03 PM
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
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
Quote from: deangelj on October 16, 2008, 04:39:03 PM
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.
Quote from: futzle on October 16, 2008, 09:40:39 PM
...
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.
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.
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)
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
Quote from: Daniel Hall on October 22, 2008, 04:40:30 PM
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
I did this on both my 7100 and my S1 and Ice Interactive killed all the timers in the Upcoming Timers list on the Ice Interactive wesbite
Even clicking on update doesn't seem to bring them back.
I also got some bizarre timers appearing after I got rid of all the old timers. ie timers set for 4am & 5am after I clicked resend all recordings.
In the end I had to manually select all the recordings in my Shows list and select the correct device and click record.
Edit:
So far the Topfield has received all it's timers after doing the above with 1.00.21 firmware
The Beyonwiz S1 seems to be struggling and all it's received is a bizarre timer dated 26/10/2008 at 4am-5:10am which is in the past.
Usually the Beyonwiz is the first to get it's timers. it's set to +8GMT with DST enabled.
Same happened for me when we changed 3 weeks ago. However, I deleted the timers from the Wiz before doing the resend, which tells the ICE server that I didn't want them recorded for that week, so, as you did, had to choose "record" on each item individually and pray that the synch happened properly (missed a show or two that week as I missed a couple of my faves to choose "record" on... I have LOTS).
Presumably you have enabled the Wiz to be in DST mode now? Is the Topfield 7K auto or manual DST?
edit:
When I chose the "resend all" option from my account preferences after doing the delete of all my timers, the only timers that ICE resent were some new ones that my 4am synch obviously didn't pick up, and 2 timers in the past, that show up grey with no names for the timers in the Wiz EPG, so the resend function seems to even resend a couple in the close past it seems?
Regards
Finally the beyonwiz got them all.
Just can't explain the timers that keep getting created in the past at 4am running for 70min.
I certainly hope DST gets cancelled in WA after this last trial year. Then we won't have to worry about things like this again