Timers get the wrong program names!!

[j s]

There is a very basic flaw in the way timers get set on BW devices. It's very obvious that the program name is NOT set as part of the timer request but that Ice depends on  the name being picked up from the EPG. Unfortunately this can result in some very screwy titles.

Case 1: The EPG for that timeslot/LCN is empty when the timer arrives from Ice. Timer gets set with a name of (for example) "*Seven HD" which might (or might not) pick up the correct name at the time the recording starts. Often it picks up the name of the previous show.

Case 2: The EPG for a timeslot/channel has been received by the BW. Subsequently the EPG needs to be changed (the reason doesn't matter).  The new entry is for a show flagged in either a series or keyword. Ice Interactive sends the timer to the BW BEFORE the EPG update gets sent so the timer gets created with the wrong name.

Both of these issues would not exist if Ice sent the timer name as part of the timer request. Presumably the code in the BW would also need to be changed to accept the name but we are told this code is supplied (or perhaps just specified) by Ice.



As an aside to the above it is very obvious that the Interactive code is not very robust (for BW devices at least because that's all I have experience with). If anything goes wrong it can quickly get very out of whack.  Often the issue is made worse by users trying to "correct" issues when perhaps they would be better just waiting a while.  Of course the user doesn't know this because Ice refuses to publish any description of the process by which timers get set/updated/deleted meaning that we, the users, are flying blind and cannot be blamed if we make things worse.

There's also a bad case of lefthand/righthand typified be the issue raised above. Another exemple is that the Ice code in the BW has a "Clear EPG" option yet if you use this to try an fix an EPG problem you inevitably end up in a "request made too often" state and have no EPG at all for an hour. Left hand provides the option - right hand punishes the user for using it.   :'(

[tonymy01]

I had this phenomenon just 2 days ago with the MotoGP (Tuesday morning actually, so not quite 2 days ago).   When I was going to set a manual timer for it (as ICE hadn't updated their schedule to put the rescheduled MotoGP in) I was looking to see if there was a show starting at about the 3.45-4am time on TenHD and noticed that the Nascar was at that time (but starting considerably earlier) so I wasn't going to be lazy and create a timer for that show.   I was going to (but forgot) go onto the Wiz and set a manual timer for 3.45am.   Anyway, cutting a long story short, ICE updated interactive to have the MotoGP in some time on Monday night (just before I put the Wiz into standby) and as such, the MotoGP was scheduled ok.   Just to be sure (I wasn't entirely trusting of the red dot in the widget), I checked the ICE interactive web also and saw it was definitely a red dot and not a donut.   I turned on the Wiz for 5mins *just in case* early hours of Tuesday morning.   So it had plenty of opportunity to get the updated guide.
Anyways, the file recorded was "Nascar"... but at the MotoGP times....
I am starting to think JS your assumptions are correct that the timer name just isn't sent/interpreted by the Wiz, only the timeslot, duration and channel LCN are.  So the Wiz, when it polls ICE and finds a new timer, uses its CURRENT guide to decide what to name the timer.   There is also a bit of jiggery pokey with the Wiz with timer names starting with an "*" that causes this guide syncing stuff to happen, but I thought it was at the time of the recording it obtained that info to name the recording properly, rather than at the time the timer was created, but who knows with NO DOCUMENTATION OF THIS PROCESS!

Similarly:
This is the first time in ages the filename has been wrong, but certainly it seems everytime ICE realise a mistake in the scheduling and update the timeslot for a show, it is dumb luck whether it understands that the timer you have for timeslotX should be deleted and moved to timeslotY.    It seems if timeslotX corresponds with a new show (due to the reschedule to, say, later in the evening), ICE thinks "oh, do they want to record that show now also", and you end up with something recorded on the original timeslot, and your rescheduled actual show recorded.   So ICE isn't correctly sending through a delete when the schedule changes for a show in other words.    Luckily though it will create a timer for the new timeslot, but bad luck if  you had a clash on timeslotX and miss out on something you might want because ICE didn't delete timeslotX.....
Regards