IceTV error message anomalies

[prl]

A question on the IceTV forum about someone getting a "No matching service" error when setting an IceTV timer when they thought (correctly IMO) that a "Timer conflict: ..." error would be more appropriate led me to have a close look at the timer setting code in the IceTV plugin.

It appears to me that anomalous error situations can occur in the code when the list of LCN information sent by the IceTV has some entries that fail to match scanned channels in the T series.

The problems are the one that the user encountered and that multiple copies of the same timer error might be sent.

If a user has, for example, their IceTV My Account>Guide settings for a channel set to "All", but one of the LCNs in the list has an ONID/TSID/SID triple that's not in the T series scan database, then the following can happen if the user sets an IceTV recording that causes a timer conflict:

• If the non-matching channel is processed before the matching channel with a timer conflict, the timer response (iceTimer[]) is added to the response queue (update_queue) initially with the error message "No matching service". When the matching channel with the timer conflict is processed the error message in the timer response is changed to "Timer conflict: ...", but the timer response is added to the response queue again. When the loop completes and the timer hasn't been sent the timer response is added to the response queue once more, so that the IceTV server is sent a "Timer conflict: ..." message three times. It seems to handle these multiple responses OK, but they shouldn't be there. But in this instance, the user should see an appropriate error message.
• If the matching channel with the timer conflict is processed before the non-matching channel, the final state of the timer response will be "No matching service", even though a matching service was in fact found (but couldn't be recorded from). The timer response will again have been placed in the response queue three times.
• In the case where a matching channel is processed after the non-matching channel and the timer can be created, an "Added" timer response is put into the response queue, even though in normal circumstances the response is not put in the queue.

I think the processing loop

Code: Select all

                        for channel in channels:

in IceTV.plugin.EPGFetcher.processTimers() should only set the error status to "No matching service" if in fact there were no matching services at all, and leave the message as "Timer conflict: ..." if there were matching channels but they were unable to record. If a the timer responsh has already been added to the response queue, it should not be added again.

[peteru]

With the demise of the old IceTV, the API documentation is no longer available. It was only ever available as a live online document through a portal hosted external to IceTV. I guess when IceTV went into administration, the third party service was cut-off and the API documentation is no longer available.

I think that before any changes to the plugin are made, IceTV should make the API documentation available to interested parties. From what I recall, there were a bunch of requirements on the order of processing and state transitions. It's been a long time since I wrote the code, but the server end was very fragile and picky about the updates of timers. Some things may be done in odd ways because it was the only way to make it work at all.

I won't be able to make changes, since I don't have access to the IceTV service.

[prl]

I don't have access to services that would fail in the required manner, but I can probably fake the conditions well enough for testing.

[prl]

I've started looking at this properly.

• Thanks to a bug in the IceTV server, which happens to send timers with invalid ONID:TSID:SID triples for Canberra ABC as well as the valid ones, I can reproduce the bug where the IceTV plugin returns a "No matching service" error when it should return a "Timer conflict: ..." error. Dave at IceTV, Daniel Hall at IceTV: if you happen to read this, please don't fix this bug yet, it's handy for my testing
• If a timer creation, update or forget operation succeeds, no response for the timer is queued. This seems to be incorrect according to the IceTV timer protocol flowchart, but it doesn't appear to affect operation.
• When an incorrect "No matching service" message is issued, more than one response for the timer can be queued. This is also incorrect according to the flowchart, but it doesn't appear to affect operation, apart from the response message fields having the wrong contents.
• When the server sends a "forget" for a timer that exists on the Beyonwiz and the timer has not completed (which is usually the case), the timer is deleted twice, once by the onTimerChanged() callback and once by the onTimerRemoved() callback (in that order). This is the source of the double log entries ("Timer deleted OK"/"Can not delete timer: 404 Client Error: Not Found") every time a timer is removed on the Beyonwiz by the IceTV server.
• On my reading of the flowchart, sending a delete command back to the IceTV server when the server has sent a "forget" timer is probably incorrect. The plugin should just set the timer state and message appropriately and put the response in the update queue.

[peteru]

Don't be fooled by the IceTV documentation. There are many instances where it is inaccurate or outright incorrect. The flow charts in particular are misleading. They neither reflect the server behaviour nor the textual description and in some cases do not cover all possible paths.

Even though I provided feedback to IceTV during development, the documentation has seen very few updates and corrections. As you will see there are also completely undefined areas, such as padding behaviour.

By far the most pragmatic approach to IceTV development is to use empirical evidence and experiment with what works. You can try reporting issues to IceTV and perhaps discussing specifics of observed vs documented behaviour, but you are unlikely to see a very quick turnaround when it comes to fixing the server side code. Fixing up server side data on the other hand can be quick.

[prl]

... There are many instances where it is inaccurate or outright incorrect. Even though I provided feedback to IceTV during development, the documentation has seen very few updates and corrections. ...

I've noticed that since the documentation was released, too. They've corrected the errors in the definition of Category entities that I pointed out on the IceTV forum back in March, but though they've changed their description of Credits entities since I posted about it, it's still wrong.

However, you commented earlier:

I think that before any changes to the plugin are made, IceTV should make the API documentation available to interested parties.

I assumed from that that you thought it more useful than you now seem to.

[peteru]

It's still useful. Even if it is just to get a little bit more of an insight as to what they are trying to achieve or at least some of the logic going on behind the design. However, there's no substitute for trial and error when you are dealing with a closed source black box implementation.

[prl]

I've come across another anomaly with the IceTV implementation in the plugin.

My testing so far has been with a test box with only the recordings I need to test a particular scenario set up.

I've found that sometimes a recording is successfully sent to the Beyonwiz and EPGFetcher.postTimer() is run in a thread in response to that message, and the actual timer addition is done by EPGFetcher.putTimer(), but the request to the IceTV server sent by putTimer() doesn't seem to update the timer's state on the IceTV server, it stays on "queued", instead of changing to "sent".

If that recording is then deleted on the IceTV side, no "forget" message is sent to the Beyonwiz, because presumably the IceTV server doesn't think there's anything to forget, because the server state is telling it that the timer hasn't been set on the Beyonwiz. The timer "queued" icon is removed on the server side.

If instead of deleting the timer on the IceTV side, it is deleted on the Beyonwiz size, the deletion is sent to the IceTV server, but it appears to be ignored, because the "queued" icon is not removed. Possibly the "deleted" message is ignored by the server because its state is telling it that the timer isn't on the Beyonwiz anyway.

If two timers are sent in one "Fetch EPG and update timers" request and they are the only ones under IceTV control, the last one of the pair seems to be the one not properly updated on the server side.

It's all a bit odd, because I don't see this kind of thing on our in-use T4.