[mythtv-users] List of recordings with yellow text item?

Stephen Worthington stephen_agent at jsw.gen.nz
Wed Nov 22 15:09:23 UTC 2017


On Wed, 22 Nov 2017 14:38:55 +0000, you wrote:

>So I’m using the Mythbuntu 28.21 Theme and I have 0.28 with latest updates.
>
>When I look at my list of recorded TV programs, occasionally I’ll see one with it’s text in yellow instead of white.  What does that mean?  It seems to be recorded okay.
>
>Jim A

It means that the recording has damage sufficient to cause mythbackend
to think it needs re-recording, if possible.  If you add the option
"-v record" to your mythbackend command line, then you will get log
entries in mythbackend.log that explain the errors, such as these:

root at mypvr:/tmp# grep -a "overall_score=\"0"
/var/log/mythtv/mythbackend.log
Nov 20 19:34:00 mypvr mythbackend: mythbackend[3670]: I TVRecEvent
tv_rec.cpp:863 (FinishedRecording) TVRec[11]:
FinishedRecording(1003_2017-11-20T06:13:00Z) damaged
recq:<RecordingQuality overall_score="0.920588"
key="1003_2017-11-20T06:13:00Z" countinuity_error_count="0"
packet_count="8014505">#012    <Gap start="2017-11-20T06:13:00Z"
end="2017-11-20T06:13:27Z" duration="27" />#012</RecordingQuality>
Nov 20 19:34:01 mypvr mythbackend: mythbackend[3670]: I TVRecEvent
tv_rec.cpp:863 (FinishedRecording) TVRec[2]:
FinishedRecording(1001_2017-11-20T06:13:00Z) damaged
recq:<RecordingQuality overall_score="0.935294"
key="1001_2017-11-20T06:13:00Z" countinuity_error_count="0"
packet_count="6776134">#012    <Gap start="2017-11-20T06:13:00Z"
end="2017-11-20T06:13:22Z" duration="22" />#012</RecordingQuality>
Nov 21 22:34:00 mypvr mythbackend: mythbackend[3670]: I TVRecEvent
tv_rec.cpp:863 (FinishedRecording) TVRec[96]:
FinishedRecording(10208_2017-11-21T08:29:00Z) damaged
recq:<RecordingQuality overall_score="0"
key="10208_2017-11-21T08:29:00Z" countinuity_error_count="2"
packet_count="2801058">#012    <Gap start="2017-11-21T09:01:01Z"
end="2017-11-21T09:30:00Z" duration="1738" />#012</RecordingQuality>

The first two of those errors were when I had to reboot during those
two recordings, so they got cut off (I had a problem with a tuner
cable that caused the logs to fill the system drive).  These
recordings were not a real problem to lose, as they were just the
daily evening news recordings.  The last one was when minisatip seemed
to lose lock on the satellite tuning, and stopped sending data to
mythbackend for that recording.  In that case, it was automatically
re-recorded from a later repeat.

If you play a damaged recording, then you will normally see or hear
the results of that damage.  For example, a "gap" is visible as a jump
in the recording where the data is missing.  These can be OK
sometimes, but if they cause bits of dialogue to go missing they can
make it very hard to understand the program.  Continuity errors often
seem to cause more serious problems where there is visual or audible
crud that keeps on going for quite a while.  I have found that doing a
skip backwards when this happens will often clear the problem as it
restarts the decoding from a keyframe.  In any case, I think that if
there are any errors at all, it is best to re-record if there is a
repeat available.  On my pay satellite service, and a couple of the
local DVB-T channels, there are almost always at least three repeats
of any program, so re-recording is normally possible.  On the main
DVB-T channels, things are only broadcast once, so errors are much
more of a problem.  Fortunately, errors are extremely rare for me on
DVB-T, and rather more common from satellite.  Mythbackend will only
mark a recording as damaged (yellow) and re-record if the calculated
"overall_score" value is low enough.  I am not sure of the exact
threshold, but I would personally prefer that any errors at all caused
a re-recording, as I sometimes do not notice a recording that has been
danged to less than the threshold until after all the repeats have
been broadcast.


More information about the mythtv-users mailing list