Project

General

Profile

Bug #5010

missed DVR recording moved to removed instead of failed

Added by g siviero over 2 years ago. Updated 5 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
PVR / DVR
Target version:
-
Start date:
2018-03-19
Due date:
% Done:

0%

Estimated time:
Found in version:
4.3-1152
Affected Versions:

Description

Configuration:
1) TVheadend 4.3-1152 as SAT>IP client on QNAP NAS
2) TVheadend 4.3-1152 as SAT>IP server on RPi2 (DVB-S tuner)
3) TVheadend 4.3-1152 as SAT>IP server on RPi2 (DVB-S tuner)

Situation:
If client (1) is recording/streaming from a SAT>IP server and a new recording is requested, and the requested server (the supposedly free one) for some reason gives for example "service instance is bad, reason: No input detected" and then "No input source available for subscription "SAT>IP" ...", after some time the recording is missed but instead of being moved to "Failed recording" (with "time missed" for example) it is moved to "Removed recording" with status "file missing". The file is truly missing, but because it was never recorded, not because it was removed.
I'm afraid that this behaviour would prevent for example an autorec recording of a re-run of the missed recording: the system would find the missed recording under removed instead of failed and so skip a possible re-recording.


Files

dvr_db.c.patch (434 Bytes) dvr_db.c.patch patch file Simon Hyland, 2020-04-22 16:45

History

#1

Updated by Simon Hyland 5 months ago

Similar thing here - recording a second stream from an IPTV network with setting 'Max # input streams = 1' obviously fails with 'No input source available for subscription' and 'Time missed' in the log.

Master may now have this fixed, I'm using an older checkout (ebb0968047b6a3aecd61b48792ab8b48a50ecb0d) from 2019 but don't want to upgrade the whole installation so came up with a workaround hack of dvr_db.c.

The patch attached changes a conditional statement to determine if a recording is classed as completed or missed. Missed recordings for the above reason (others not tested) now show in 'Failed recordings' rather than 'Removed recordings' so it achieves this aim but whether or not it breaks something else is unknown.

Not sure if URLs are permitted here, the patch can also be found at https://pastebin.com/53AJsYhh

Cheers

#2

Updated by Simon Hyland 5 months ago

Patch follow-up:

After a single test run, so long as your recording profile has 'Try re-scheduling recording if more errors than' set to a non-zero value, the missed recordings are re-scheduled with the above patch applied (they are not if this setting is zero).

Also available in: Atom PDF