Timer, sent, but still a donut icon

[prl]

I have a series recording set on Mighty Ships (7maate 1830 Sat). The timer has been set for the recording on the Lite, but the IceTV web pags still shows the "queued series" donut.

ACT EPG, Beyonwiz DP-Lite, firmware 01.07.065beta when the timer was sent, currently 01.07.067beta.

I've been getting these on and off for ages.

[grampus]

I have a series recording set on Mighty Ships (7maate 1830 Sat). The timer has been set for the recording on the Lite, but the IceTV web pags still shows the "queued series" donut.

ACT EPG, Beyonwiz DP-Lite, firmware 01.07.065beta when the timer was sent, currently 01.07.067beta.

I've been getting these on and off for ages.

I have experienced this on the odd occasion.
The timer is present in the device.  A red doughnut in the web site.  Red doughnut stays on for the 5 day till the event has passed.  I would have thought that the timer would have been sent again, until it was noted that it had been entered, or a yellow triangle been presented.
I wonder if this is part of the " timer sent to the wrong box" problem?

[grampus]

Just rechecked my timers

I had 1 red doughnut for tonight.  But the timer was present in the box.
Same box another red doughnut for Sunday night.  No timer in the box.
The timer was created yesterday afternoon, and the box had been on this morning for just over an hour.
I would have expected it to be there at the end of the hour.

I checked the other box, no mixup with timers at this time.   Thought I had was maybe the sunday timer got sent to the other box.
More I thought about the ifs buts and maybes, NAPT, destination port tables in Ice, the more my head hurt, so I gave up, thinking about that one.

[prl]

I've got a "scheduled" icon for my recording of Floyd on France tomorrow night (8/12, 18:00, 7TWO), but the timer is set on the Beyonwiz.
I've got an "error" icon for Bargain Hunt tomorrow night (8/12, 18:30, 7TWO), but I can't see any conflict that could have caused the problem.

Beyonwiz DP-Lite, firmware 01.07.350 beta (with 01.0x.350, Beyonwiz is now using the same third part of the version number for both 01.05 and 01.07 firmware series).
IceTV ACT EPG.

[grampus]

I've got a "scheduled" icon for my recording of Floyd on France tomorrow night (8/12, 18:00, 7TWO), but the timer is set on the Beyonwiz.
I've got an "error" icon for Bargain Hunt tomorrow night (8/12, 18:30, 7TWO), but I can't see any conflict that could have caused the problem.

I keep getting red doughnuts occasionally when the timer is set.

You have 2 devices in your sig.
I have had intermittent problems where a timer is sent to the wrong device.
Generally it seems to be that my second box has requested a timer update, and it selects a timer from my first one in the list.
If my second box already has both tuners scheduled, then I get an error, but if there is no conflict, the timer ends up on the wrong box.


I reported this to Ice, they said it was a BW problem, and they would take it up with them again.

[prl]

...
You have 2 devices in your sig.
I have had intermittent problems where a timer is sent to the wrong device.
...

Yes, I do have two devices, but the timer that was sent but left in "scheduled" state on the server was sent to the right box, and the timer with the error was sent to neither.

[grampus]

...
You have 2 devices in your sig.
I have had intermittent problems where a timer is sent to the wrong device.
...

Yes, I do have two devices, but the timer that was sent but left in "scheduled" state on the server was sent to the right box, and the timer with the error was sent to neither.

Yes, as with you, I get the occasional timer after being set in the correct box, I still see it is still left in the scheduled state.  It remains like that every day after being set.

As with the timer with the error indication, I have had it posed to me, by Ice tech,  one of the boxes, calls for updates, somehow selects the wrong box in the Ice server, and sends a new timer there.
The reasoning that was given was that it will be the second box in your device list in the Ice server that calls for the update, and selects the first in the list.

I've seen a couple of results from this. The first result is that I see a timer being set in the wrong box.
The other result is that the timer being sent to the wrong box finds that there is a conflict as you already have 2 timers set for that time, and ends up being flagged as an error.

As an aside to this, even though we set up device names in the Ice server to match our box names, the request that is sent is by ID, in the case of 2 devices in the list, either 0 or 1, not the box name.
So without seeing a trace for this, the 2 different causes for this may be, second box, ID = 1, somehow sends a request for ID = 0.
Or sends a request for ID = 1, and the Ice server selects ID = 0.

I've also talked with BW people about this, the tech said that he'd like to set this up on their boxes, and trace it.
But I suspect that the occurrence is too intermittent to be able to be caught, without monitoring virtually 24/7.
 

[prl]

I resent the recording for the "errored" Bargain Hunt, and it was sent correctly. Since I hadn't changed any recordings or timers in the meantime, then clearly there was no actual error condition in the first place. 

[raymondjpg]

Yesterday I had a program showing OK as a scheduled series recording on the Ice site, but no timer set on the Topfield. I set it manually.

Today I had two series recordings (concurrent, two different services) scheduled for the Topfield showing as errors on the Ice site. Resetting (not resending) resulted in the recordings showing up OK on the Topfield, but only one registered as having transferred on the Ice site. The other persists as a red doughnut.

Both of these concurrent series recordings transferred without problems to the Beyonwiz, and registered as having transferred on the Ice site.

[raymondjpg]

Yesterday I had a program showing OK as a scheduled series recording on the Ice site, but no timer set on the Topfield. I set it manually.

It turns out that the Beyonwiz made two (identical) recordings of this show.

Another piece in the Beyonwiz stole my Topfield recording puzzle?

[grampus]

Yesterday I had a program showing OK as a scheduled series recording on the Ice site, but no timer set on the Topfield. I set it manually.

It turns out that the Beyonwiz made two (identical) recordings of this show.

Another piece in the Beyonwiz stole my Topfield recording puzzle?

To make it clearer for me,  you are saying is that you had originally had the same recording timer set in Ice for both devices.
Then the topfield didn't get the timer.
So the BW is erroneously being delivered the timer for the Topfield.

Now for what I think is another piece of the puzzle.
Where in your list in Ice is the BW?
I think that it may be the second one.
If thats the case then the statement that I had given to me that the BW is selecting the first device erroneously may very well be the issue.
Which would probably mean that the BW is probably sending a request for device 0, when it should be looking for ID = 1.  Maybe its got a small hiccup in the selection of the device ID, and picks up a null field?
That'd be a great crystal ball?


If thats the case, how do we get BW's attention to resolve this?
I've had discussions on a few occasions with BW tech's, but I'm not sure if its just put down the list of priorities.


Maybe I've just gone round in a big loop and said what everyone else has?


 

[raymondjpg]

To make it clearer for me,  you are saying is that you had originally had the same recording timer set in Ice for both devices.

Correct.

Then the topfield didn't get the timer.

Correct.

So the BW is erroneously being delivered the timer for the Topfield.

Seems so.

Where in your list in Ice is the BW?
I think that it may be the second one.

You asked me that one before. Topfield first, Wiz second.

If thats the case then the statement that I had given to me that the BW is selecting the first device erroneously may very well be the issue.
Which would probably mean that the BW is probably sending a request for device 0, when it should be looking for ID = 1.  Maybe its got a small hiccup in the selection of the device ID, and picks up a null field?
That'd be a great crystal ball?

If thats the case, how do we get BW's attention to resolve this?
I've had discussions on a few occasions with BW tech's, but I'm not sure if its just put down the list of priorities.

In most if not all of these issues it seems to me that it is an interaction between the Ice enabled device and Ice TV i.e. not the fault of one or the other.

If you haven't had any change out of Beyonwiz, I'd be inclined to ask Ice if they can resolve it. Both parties have an interest in seeing that the device marketed as Ice enabled does work.

Have you logged a service ticket with Ice yet? I could do it if you prefer.

Maybe I've just gone round in a big loop and said what everyone else has?

I don't recall anyone else having made a fuss about this recently. Maybe I haven't been paying attention.

In any case, time to call on the technical expertise of Ice I think.

Regards

[grampus]

The more people who make this visible with both support groups the better off we will be, I hope.

I have already discussed it with Ice.
I had a case (37599) open, and closed on the 2nd June, with the following reply.

The way the Ice TV server knows which device is connecting on an account is sent by the device itself, this is first setup in the My Account section of the IceTV website and then under the "Select Device" option on the Beyonwiz.

There are times in the past where for no reason the Beyonwiz resets the device it is set to and goes back to the first one in the list. We are not sure what symptoms cause this to occur unfortunately. The first thing to do through it to ensure that for each of your devices they are showing the correct device name under the "Select Device" option under the IceGuide menu.

I have also discussed it with Ice again recently by phone, the end result of that was that the tech I spoke to undertook to take it up again with BW via their sales path.
I have no knowledge of the end result of that.

As BW don't have a formal case mechanism, I can't track anything that I have opened with them.

Sorry about the reiteration of the query of your list sequence.

 

[raymondjpg]

I have also discussed it with Ice again recently by phone, the end result of that was that the tech I spoke to undertook to take it up again with BW via their sales path.
I have no knowledge of the end result of that.

I had a case of a timer scheduled for the Topfield only, sent to the Wiz instead last month. The Ice tech I tick tacked with left it at "...I'll get our developers to see if they can see what happened. Everything looks okay for next week, which is why it's strange that it didn't work for you last week."

So I'll follow it up with him tomorrow. Hopefully it isn't in the "strange but with any luck it will go away" basket.

[prl]

... Hopefully it isn't in the "strange but with any luck it will go away" basket.

It appears to me that all three problems being discussed in this topic:

• Timer sent, but server still shows "queued";
• Error in sending timer, but no apparent cause; and
• Timer sent to wrong device;

are all in just that state. The "queued" problem, even though fairly innocuous, has been known about and discussed on this forum for ages.

I posted about it myself on 1 Oct 2009.

The topic I posted in was New Interactive, started in July 2009. That was when the style of the series recording options last changed. I've had the "queued but actually sent" problem off and on pretty much for the whole time since the major scheduling bugs were sorted out in the "New Interactive" server.