[mythtv-users] Auto re-record damaged recordings? Definition of damaged?

[Stephen Worthington]

On Tue, 15 Jan 2019 11:04:58 -0800, you wrote:

>On 1/15/2019 10:52 AM, Jon Boehm wrote:
>> Hi,
>>
>> What is the definition of a damaged recording?  I use an antenna and I 
>> have a couple of channels that are very weather dependent.  I often 
>> get short recordings with lots and lots of dropped frames.  The start 
>> and stop times, on these short recordings, are correct but the total 
>> play time is short as shown in playback, maybe 55mins out of a 1hr 
>> recording. Are these classified as damaged?
>>
>> Second question, is there a setting to allow the scheduler to auto 
>> re-record and replace damaged showings, possibly at lower priority?
>>
>> thanks

>My experience is that damaged recordings do automatically get 
>re-recorded.  At least with 0.27 and 0.28.  Now what constitutes 
>damaged, I don't know.  I have seen recordings with a few dropouts be 
>deemed not damaged and some as damaged.  There is probably some error 
>count threshold someplace.  I have also observed that with severe 
>damage, the commercial commflagging process will sometimes segfault, 
>restarting the backend.  This can be bad if another recording is taking 
>place at the time.  You might consider marking such channels as 
>commercial free to avoid that if it is an issue for you.
>Jay

If mythfrontend shows the recording in yellow (MythCenter-wide theme),
then the recording is marked as being damaged and will be re-recorded
automatically if possible.  The DAMAGED flag is one of the flags
stored in the recordedprogram.videoprop field in the database.  If you
add the "-v record" option to your mythbackend command line options,
then the mythbackend log will show extra messages like this at the end
of each recording:

Jan 16 03:09:00 mypvr mythbackend: mythbackend[2872]: I TVRecEvent
tv_rec.cpp:863 (FinishedRecording) TVRec[92]:
FinishedRecording(10208_2019-01-15T13:14:00Z) good
recq:<RecordingQuality overall_score="0.99"
key="10208_2019-01-15T13:14:00Z" countinuity_error_count="4"
packet_count="4618096">#012    <Gap start="2019-01-15T13:29:16Z"
end="2019-01-15T13:29:36Z" duration="20" />#012</RecordingQuality>

If the overall_score value is 1, then the recording is undamaged.  I
am not sure of how that calculation is done, and what exact percentage
of damage will get a recording marked with the "damaged" flag in the
database, but the above example was too little to get flagged (note
the "good" in the log message).

Here is another example where the recording was marked as damaged:

Dec 25 02:07:41 mypvr mythbackend: mythbackend[2587]: I TVRecEvent
tv_rec.cpp:863 (FinishedRecording) TVRec[92]:
FinishedRecording(10031_2018-12-24T13:07:32Z) damaged
recq:<RecordingQuality overall_score="0"
key="10031_2018-12-24T13:07:32Z" countinuity_error_count="0"
packet_count="16763">#012    <Gap start="2018-12-24T12:40:00Z"
end="2018-12-24T13:07:34Z" duration="1654" />#012    <Gap
start="2018-12-24T13:07:39Z" end="2018-12-24T13:55:00Z"
duration="2840" />#012</RecordingQuality>

In this case, I believe it was a LiveTV recording.  Those are almost
always marked as damaged as they typically stop well before the
expected end time for the program in the EPG, so they get marked as
having a huge gap at the end of the recording.

This command will show all the recordings in the current
mythbackend.log file where the overall_quality value is not 1:

grep -a "overall_score=\"0" /var/log/mythtv/mythbackend.log

I run this command daily and manually re-schedule any damaged
recordings that have not reached the limit for automatically being
marked as damaged.

In Ubuntu, to add the "-v record" option, create or edit this file:

/etc/mythtv/additional.args

and put a line like this in it:

ADDITIONAL_ARGS=-v record

Set the ownership and permissions:

sudo chown:mythtv:mythtv /etc/mythtv/additional.args
sudo chmod u=rw,g=rw,o=r /etc/mythtv/additional.args

Then (when it is not recording) restart mythbackend:

sudo systemctl restart mythtv-backend