Opened 10 years ago

Closed 10 years ago

#7369 closed defect (wontfix)

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

Reported by: mark@… Owned by: gigem
Priority: minor Milestone: unknown
Component: MythTV - Scheduling Version: 0.21
Severity: medium Keywords:
Cc: Ticket locked: no

Description

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).

Attachments (3)

snapshot1.jpg (133.9 KB) - added by mark@… 10 years ago.
Snapshot 1 - List of recordings
snapshot2.jpg (123.2 KB) - added by mark@… 10 years ago.
Snapshot 2 - List of recorded programmes
Logfile.log (32.8 KB) - added by mark@… 10 years ago.
Log from relevant period

Download all attachments as: .zip

Change History (5)

Changed 10 years ago by mark@…

Attachment: snapshot1.jpg added

Snapshot 1 - List of recordings

Changed 10 years ago by mark@…

Attachment: snapshot2.jpg added

Snapshot 2 - List of recorded programmes

Changed 10 years ago by mark@…

Attachment: Logfile.log added

Log from relevant period

comment:1 Changed 10 years ago by 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.

comment:2 Changed 10 years ago by gigem

Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.