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.
Quote from: prl on September 30, 2010, 11:08:44 PM
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?
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.
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.
Quote from: prl on December 07, 2010, 07:02:38 PM
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.
Quote from: grampus on December 07, 2010, 09:57:24 PM
...
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.
Quote from: prl on December 08, 2010, 08:57:18 AM
Quote from: grampus on December 07, 2010, 09:57:24 PM
...
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.
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. >:(
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.
Quote from: raymondjpg on December 09, 2010, 09:41:23 AM
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?
Quote from: raymondjpg on December 09, 2010, 03:51:51 PM
Quote from: raymondjpg on December 09, 2010, 09:41:23 AM
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?
Quote from: grampus on December 09, 2010, 06:57:18 PM
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.
Quote from: grampus on December 09, 2010, 06:57:18 PM
Then the topfield didn't get the timer.
Correct.
Quote from: grampus on December 09, 2010, 06:57:18 PM
So the BW is erroneously being delivered the timer for the Topfield.
Seems so.
Quote from: grampus on December 09, 2010, 06:57:18 PM
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.
Quote from: grampus on December 09, 2010, 06:57:18 PM
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.
Quote from: grampus on December 09, 2010, 06:57:18 PM
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
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.
QuoteThe 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.
Quote from: grampus on December 09, 2010, 09:40:46 PM
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.
Quote from: raymondjpg on December 09, 2010, 10:17:11 PM
... 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 (http://forum.icetv.com.au/iceforum/index.php?topic=1960.msg10287#msg10287) about it myself on
1 Oct 2009.
The topic I posted in was New Interactive (http://forum.icetv.com.au/iceforum/index.php?topic=1960.0), 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.
Have a donut, but the timer sent for Laid ABC1 1930 tomorrow Wed 23 Feb, and RPA WIN NSW, same date/time. ACT EPG, Beyonwiz DP-Lite 01.07.350 firmware.
Oh, funny.
While doing some packet sniffing of the IceTV HTTP protocol, I think I found out why the doughnuts stick around.
When a recorder wants to change the state of a schedule, it posts a message to the IceTV server. Presumably one of these messages confirms back to IceTV that a schedule has been set on the recorder, whereupon IceTV turns the red doughnut into a solid disc.
But IceTV's web server also has a rate limiter. Make too many requests in the space of an hour and the server responds with an error message. My guess is that the rate limiter is there to stop the server being overloaded, also to discourage users sharing their IceTV logins with friends.
It turns out that the rate limiter responds even to those status update postings from the recorder. The status update gets rejected, the recorder never retries the post, and the schedule remains doughnutty forever.
I bet if IceTV stopped the rate limiter on HTTP POST requests from the recorder, the prevalence of doughnuts would drop greatly.
That doesn't really gel with how I think IceTV works. If it really is running foul of the rate limiter, why does it happen so infrequently?
Quote from: prl on October 21, 2011, 03:40:21 PM
why does it happen so infrequently?
It does? Lucky you! Just now I looked at my EyeTV recordings for the next five days, and about 50% of them are open doughnuts. Maybe other PVRs are better about retrying when they hit the rate limiter, and EyeTV doesn't. My Beyonwiz has filled doughnuts all the way out till five days.
It's beyond doubt that the rate limiter is responding to some HTTP POST requests; anyone proficient with a packet sniffer can verify that for themselves.
Quote from: futzle on October 23, 2011, 07:16:42 PM
...
It's beyond doubt that the rate limiter is responding to some HTTP POST requests; anyone proficient with a packet sniffer can verify that for themselves.
Maybe there is such a problem with EyeTV. What you describe doesn't fit with the behaviour of the superficially similar problem on Beyonwiz.