Ticket #10282 (closed Bug Report - General: fixed)
Opened 16 months ago
Last modified 15 months ago
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
Change History
comment:1 Changed 15 months ago by gigem
- Owner changed from danielk to gigem
- Status changed from new to assigned
comment:2 Changed 15 months ago by Github
- Status changed from assigned to closed
- Resolution set to fixed
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
Branch: master Changeset: 510da6972b8b9c713873689ab7248c6da60c71f3
