Schedule amendments to an in-progress recording results in duplicate recordings

[mark@…]

I've witnessed some slightly strange behaviour here on v0.21. I'm using Freeview in the UK (DVB-T) with the over-air EIT data.

I had a recording scheduled for a programme, where the previous programme was over-running. As a result the scheduled start time was updated three times after the recording had already commenced.

Each time the scheduled start time changed, Myth started a new recording. Consequently by the time it actually started, Myth was recording four instances of the same programme (had it not been for Multi-Rec it would have run out of tuners!). The subsequent programmes were then pushed back in the schedule, followed by a further update to the programme being recorded with a new end time.

A screenshot of the upcoming recordings in Mythweb at this point is here (plus a manually scheduled recording on tuner 5 to catch the delayed ending):

​http://www.chez-moi.org.uk/snapshot1.jpg

Bizarrely it's showing two concurrent recordings on tuner 1, of which the latter is based on the revised end time. In reality there were only four recordings, one on each of tuners 1-4. All of these finished based on the original rather than the revised end time:

​http://www.chez-moi.org.uk/snapshot2.jpg

The issues here are twofold:

1) It was filling up the disk space rather rapidly with quadruple recordings, even though all four had the same programme ID (duplicate detection didn't prevent this). In some instances this could also create recording conflicts (though it didn't in this case);

2) All four recordings missed the end of the programme (my manually scheduled recording got it, but only because I happened to be watching the recording as it was broadcast).

[mark@…]

Snapshot 1 - List of recordings

[mark@…]

Snapshot 2 - List of recorded programmes

[mark@…]

Log from relevant period

[mark@…]

I've discovered that duplicate checking was disabled for that particular recording schedule, so that would explain why it didn't prevent the multiple recordings...

Based on that I'd still argue that it's not ideal behaviour, but probably not a huge issue to most users.

The fact that it ignored the revised end time is still a concern though. Given that over-runs are not uncommon on live programmes, it would be good if the recording end time were adjusted with any changes to the schedule.

[gigem]

I'm closing this as wontfix for now because I see it as a very rare case. If it turns out to not really be that rare, open a new ticket and we'll see what we can do.