Incorrect record/forget order in IceTV timer updates

The the IceTV API documentation says that "All “Forget” timer[ update]s will be sent first" (i.e. before "record" timer updates), but that isn't necessarily the case. The IceTV API Timer Workflow flowchart depends on "forget" timers being sent first in order to cleanly resolve the timer conflict in the "delete/reschedule" scenario in the Replication steps in a single update.

This is an instance of the "timers" list of a failed delete/reschedule update. Whitespace added for legibility:

"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"
    }
]

Having the "forget" entries following "record" entries means that if there's a timer conflict, and the user resolves it by deleting an existing recording and resending the recording marked with the error, then the "forget" can follow the "record", and at the time that the "record" is received, there's still the same timer conflict. The conflict will normally be resolved on a subsequent timer update.

This can be resolved by a code workaround in the IceTV plugin, but it would be better fixed on the server side. I posted a report of the problem on the IceTV forum on 12 Apr, but so far there hasn't been a response (but the Easter weekend has intervened).

Replication steps

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.

Comments (1)