Timers not deleted before new timers are added

[vader1111]

I did uncover another possible glitch in the IceTV server-side code as well...

I had a problem with timer conflicts. This was not unexpected - my IceTV schedule had 3 overlapping programs, on 3 different networks. I've disabled Tuner C (until the picture tearing problem is resolved), so 3 into 2 was never going to go. With timers for programs A & B already sent, it quite correctly flagged program C as a conflict.

I decided that the best solution was to delete the timer for program B (recording it on my Toppy instead), and re-scheduling program C.

I deleted the timer for B and re-scheduled C, doing both operations through the IceTV website. I received another timer conflict message when the T2 did its next timer/EPG fetch, 15 minutes later. I checked - B had been deleted, but C had not gone through. I re-scheduled C (again), and this time it went through with no problems.

It appears that fetch/update process sends the new timers, before deleting existing timers. Thus (the first time around) it was re-sending C before B had been deleted.

Personally, I think they should send the deletions first, then the new timers. I guess they have their reasons for doing it the other way around. Either way, it's not a problem with the Wiz - it's the ordering of the messages sent by IceTV.

[prl]

...
I deleted the timer for B and re-scheduled C, doing both operations through the IceTV website. I received another timer conflict message when the T2 did its next timer/EPG fetch, 15 minutes later. I checked - B had been deleted, but C had not gone through. I re-scheduled C (again), and this time it went through with no problems.

It appears that fetch/update process sends the new timers, before deleting existing timers. Thus (the first time around) it was re-sending C before B had been deleted.

Personally, I think they should send the deletions first, then the new timers. I guess they have their reasons for doing it the other way around. Either way, it's not a problem with the Wiz - it's the ordering of the messages sent by IceTV.

On an update, all timer changes are sent to the Beyonwiz in a single update message that contains (amongst other things) a list of timer updates.

Each entry in the list has an "action" field, which can be either "record" or "forget" (delete). The Beyonwiz code simply processes the entries in the timer update list in the order they are presented in in the JSON list (as specified in the flowchart in the IceTV API documentation). That documentation also says: All “Forget” timers will be sent first, these should be deleted.

But the documentation also says "there is no concept of incremental timer updates, we always send all current timers in each request", which is a little at odds with an API where "record" and "forget" actions are sent, rather than just a list that says "these are all the IceTV timers".

I'll try to replicate the "set-before-delete" behavior you're seeing and if I can, I'll ask about it in the IceTV forum. If it can't (or won't) be fixed at the server end, I'll look at making the client end process all "forget" entries and then all "record" entries.

[vader1111]

Thanks.

This isn't something that occurs often - it just happened to pop up in the last few days (when Sunday's timers went through).

[vader1111]

While we're on the subject of IceTV problems (and this one is definitely IceTV - not Beyonwiz)....

One really annoying feature of IceTV is the way its obsession with necrophilia. Let me explain...

I have "The Night Manager" set to record as part of a series recording. I have "removed" tonight's episode from my recording schedule (using the IceTV website), due to conflicts with other recordings. So far so good. IceTV have just updated their schedule, moving the program's start time from 9:25pm to 9:30pm. Changing the time results in the timer being resurrected from the dead - with a subsequent "Timer Conflict" email being sent.

This happens every single time they update the time for an episode of a series recording, which had previously been manually cancelled. Why does their system insist on resurrecting timers which have been specifically "removed"?

This is probably better addressed on the IceTV forum. It's definitely an IceTV issue. It is NOT a Beyonwiz problem.

[MrQuade]

One really annoying feature of IceTV is the way its obsession with necrophilia. Let me explain...
...
Changing the time results in the timer being resurrected from the dead - with a subsequent "Timer Conflict" email being sent.

I think you mean necromancy


Unless......no, not going there.

[prl]

OK, I've been able to create an instance of the problem and grab the JSON from the debug logs:

Code: Select all

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

[prl]

I've posted about the original issue on the IceTV forum. I'm hopeful that Daniel Hall will pick up on it. I don't know whether his reaction will be to change the code or the documentation

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

[prl]

... This is probably better addressed on the IceTV forum. It's definitely an IceTV issue. It is NOT a Beyonwiz problem.

Yes, that problem is probably better posted on the IceTV forum.

Please don't piggy-back unrelated problems onto a bug discussion topic. (That's a general request, not just directed to vader1111.)

[prl]

Bug #583: Incorrect record/forget order in IceTV timer updates

[prl]

Daniel Hall from IceTV has responded to my post on the IceTV forum to confirm the server side problem and to say that he'll get back to me when it's fixed.

[prl]

Daniel Hall at IceTV has posted that the server should now order "forget" and "record" entries in timer updates correctly.

I've been able to confirm the correct ordering in a few trials of vader111's timer conflict/delete/reschedule scenario, but other minor issues with IceTV were getting a bit in the way (see my posts on the IceTV forum).

[vader1111]

This problem appears to have reared its ugly head again. I've had 3 programs in the last 3 days, where network schedule changes have resulted in new timers being sent without the old timers being deleted.

Anyone else experiencing this problem?

Specifically, I saw it with SEAL Team and Blindspot on Sunday night, and Have You Been Paying Attention last night.

I'm running 17.5 20180417 firmware.

[Grumpy_Geoff]

This problem appears to have reared its ugly head again. I've had 3 programs in the last 3 days, where network schedule changes have resulted in new timers being sent without the old timers being deleted.

I think you'll find it's the IceTV server not paying any attention to a timer from the previous change, and issues a new timer for a further scheduling change instead of either (i) updating the existing, or (ii) deleting the existing and creating a new timer.
See here where I last investigated this.
I posted a link to that post on the IceTV forum - no one from IceTV replied.

If you have a look at your /etc/enigma2/timers.xml file and examine the entries for the instances of the event's timers you will probably see a different EIT value for each (i.e. a new EPG entry, not simply a change).

[vader1111]

So definitely an IceTV problem, not a Beyonwiz problem. Thanks for doing that research. Good to know I'm not the only person experiencing problems with IceTV lately.

[prl]

So definitely an IceTV problem, not a Beyonwiz problem. Thanks for doing that research. Good to know I'm not the only person experiencing problems with IceTV lately.

I'm less sure where the error lies than that, but it occurs so infrequently it's hard to study. I've had a background discussion with Daniel Hall about a user who had a recording fail because the timeslot switched between two different programs that he happened to be recording, and the first timer was updated rather than deleted, and then when the new timer for the same timeslot came along, it failed.

I think it was a server-side problem, but the available evidence was pretty thin.