IceTV doesn't list timer deletions before timer add/update

[prl]

I'm posting this in the Beyonwiz forum because it was found on a Beyonwiz T series, but it probably applies to any PVR using the new IceTV API.

The original bug reported in the Beyonwiz forum was:

• Create a timer conflict by recording on more broadcast channels than there are tuners.
• Try to resolve the conflict by deleting one of the successfully created recordings, and rescheduling the one that was flagged as a conflict error. This must be done so that both actions are sent in a single IceTV update.
• Wait for an IceTV update, or force an update using MENU>IceTV>Fetch EPG and update timers now.
• The deleted timer will be removed, but the rescheduled timer may not be set. A conflict email will be sent if the timer wasn't set, but the IceTV EPG page will show the timer as "queued", not "error"
• If the rescheduled timer isn't sent in that update, it will be sent successfully in a later update.

The problem is that the API Timer Workflow documentation says "All “Forget” timers will be sent first", but that isn't necessarily the case. The Timer Workflow flowchart depends on "forget" timers being sent first in order to cleanly resolve the timer conflict in the above "delete/reschedule" scenario in a single update.

Here's an instance of the "timers" list of a failed delete/reschedule update. Whitespace added for legibility:

Code: [Select]

"timers":[
    {
        "id":"1491971820",
        "device_id":"180890",
        "channel_id":"75",
        "name":"Death In Paradise",
        "show_id":"131427844",
        "start_time":"2017-04-12T09:30:00+00:00",
        "duration_minutes":"70",
        "action":"record",
        "state":"waiting",
        "message":"Reschedule requested via Interactive web interface.",
        "series_recording_id":"12664001",
        "keyword_id":"0"
    }, {
        "id":"1491971579",
        "device_id":"180890",
        "channel_id":"2411",
        "name":"My Year 12 Life",
        "show_id":"131463583",
        "start_time":"2017-04-12T09:30:00+00:00",
        "duration_minutes":"30",
        "action":"forget",         <<<<< The "forget" isn't before the "record"
        "state":"waiting",
        "message":"Unschedule requested via PIMP web interface.",
        "series_recording_id":"0",
        "keyword_id":"0"
    }
]
The "forget" follows the "record", so the timer conflict isn't resolved by the Timer Workflow algorithm in the API documentation.

A minor additional nitpick: the Timer Workflow page talks about 'All “Forget” timers', and the "timers" entity specification says that the "action" strings are "Forget" and "Record" (first letter upper case), but as can be seen in the example, the actual "action" values are all lower case.

[prl]

Bump... Dave? Daniel?

[Daniel Hall at IceTV]

Yep, definitely weird, will fix the sort on the server and let you know when its done.

[prl]

Thanks, Daniel.

[Daniel Hall at IceTV]

This one has been fixed and is online.

[prl]

Thanks, Daniel. I'll give it a whirl.

[prl]

My testing has been hampered by frequent timeouts on reading the channel map and the occasional "502 Server Error: Bad gateway for URL: http://api.ice.com.au/shows/...".

I'm seeing similar issues on our in-use T4.

I've so far had one clear run of a delete/reschedule that correctly ordered the "forget" ahead of the "record" in an update, but I'll try to get a few more runs to confirm.

I'm doing the testing on a Beyonwiz T2 running firmware 20170310.

[prl]

I've had a couple more clear runs where the ordering of the update was correctly "forget" then "record". Still getting sporadic timeouts on reading the channel map and "502 Server Error: Bad gateway for URL ..."

Doing this testing has reminded me that Timer, sent, but still a donut icon, that I first posted about back in 2011 is still a problem, and so is Device name missing from "Reschedule recording on"