Opened 12 years ago
Closed 12 years ago
#10282 closed Bug Report - General (fixed)
Recording status changed to rsRecorded after failing
| Reported by: | stuartm | Owned by: | gigem |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.25 |
| Component: | MythTV - Recording | Version: | Master Head |
| Severity: | medium | Keywords: | |
| Cc: | Ticket locked: | no |
Description
I've noticed several instances of the following bug looking back over my logs. A recording fails for one reason or another and is marked correctly as rsFailed. However as we end the recording the rsFailed state is changed to rsRecorded giving the impression that the recording didn't fail. Additionally the change to rsRecorded seems to occur before is_good is set and so the failed recording isn't set to re-record.
Log snippet attached.
Attachments (1)
Change History (3)
Note: See
TracTickets for help on using
tickets.
As noted in SHA1:9551bce2, MainServer? doesn't know the actual recording status because it defaults to rsRecorded when the recordinginfo is initialized from the recorded table. MainServer? doesn't account for this and tries to make any needed state change which always ends up staying rsRecorded. MainServer? then passes this bad status to the scheduler. If the recording had already failed, the rsFailed status gets overwritten.
Since the scheduler knows the correct status, change the status to rsUnknown in MainServer? before updating the scheduler. The scheduler now notices the special value and applies any needed state change itself. In the case of a failed recording, the status now remains rsFailed.
Also, remove the duplicate code in MS::DoHandleDeleteRecording?() used to stop an in-progress recording and use MS::DoHandleStopRecording?() instead. Try to avoid unnecessary reschedules when deleting programs from the Deleted and LiveTV recording groups.
Fixes #10282