[mythtv-users] Signal strength now reporting 50% instead of 100%

[Stephen Worthington]

On Sat, 7 May 2022 06:49:27 -0400, you wrote:

>Since I'm getting no errors in recording, no listing of programs in the
>library that have the text in Yellow indicating excessive errors, I'm going
>to assume I have no problem at all, but I'll investigate. I could always
>install Kubuntu 21.10 and MythTV v32 on a USB3 SSD and boot that to test if
>it's a software thing.
>
>Jim A

The yellow of excessive errors is indicating a bad problem.  If you
want to see if there are any errors at all, then you can add the "-v
record" option to the mythbackend command line to get more detailed
logging.  In Ubuntu, you do that in the /etc/mythtv/additional.args
file.  This is what I have:

root at mypvr:/etc/mythtv# cat additional.args
ADDITIONAL_ARGS=-v record,dvbcam

After restarting mythbackend, you will then get messages like this at
the end of each perfect recording:

May  2 23:29:29 mypvr mythbackend: mythbackend[1869365]: I TVRecEvent
tv_rec.cpp:841 (FinishedRecording) TVRec[2]:
FinishedRecording(1013_2022-05-02T10:28:00Z) good
recq:#012<RecordingQuality overall_score="1"
key="1013_2022-05-02T10:28:00Z" continuity_error_count="0"
packet_count="15777135" />

And when there are errors, you get messages like this:

May  2 23:29:00 mypvr mythbackend: mythbackend[1869365]: I TVRecEvent
tv_rec.cpp:841 (FinishedRecording) TVRec[96]:
FinishedRecording(10070_2022-05-02T10:29:00Z) good
recq:#012<RecordingQuality overall_score="1"
key="10070_2022-05-02T10:29:00Z" continuity_error_count="1"
packet_count="14706294" />

In that case, there was a continuity error - as I understand it, that
means that a packet was received with a packet number that was larger
than 1 higher than the last packet received of the same type, so it
indicates a possible missing or corrupt packet.  As there was only 1
such error, mythbackend did not calculate its overall_score value as
less than 1.0.

Here is another:

May  2 20:34:02 mypvr mythbackend: mythbackend[1869365]: I TVRecEvent
tv_rec.cpp:841 (FinishedRecording) TVRec[90]:
FinishedRecording(10072_2022-05-02T07:29:00Z) good
recq:#012<RecordingQuality overall_score="1"
key="10072_2022-05-02T07:29:00Z" continuity_error_count="28"
packet_count="18970429" />

I am a bit surprised by that one, as I would have expected that 28
continuity errors would have caused the overall_score to drop.

Here is one with a gap at the start of the recording:

Apr 27 21:34:00 mypvr mythbackend: mythbackend[1127578]: I TVRecEvent
tv_rec.cpp:841 (FinishedRecording) TVRec[1]:
FinishedRecording(1001_2022-04-27T08:30:00Z) damaged
recq:#012<RecordingQuality overall_score="0.986667"
key="1001_2022-04-27T08:30:00Z" continuity_error_count="0"
packet_count="17123216">#012    <Gap start="2022-04-27T08:30:00Z"
end="2022-04-27T08:30:16Z" duration="16" />#012</RecordingQuality>

Gaps almost always cause the overall_score to decrease.  In this case,
the 16 second gap at the start of the recording is measured from the
starttime for the recording, not from when the tuner started its
pre-roll, so in my case with 60 s of pre-roll, it is actually a 76
second gap before the recording started properly.  That is something
that my system does, probably due to a problem with the database
housekeeper task running and overloading my system.  It only seems to
happen on systems with large databases - mine is huge.

Here is a recording that never started:

Apr 16 11:04:00 mypvr mythbackend: mythbackend[1291924]: I TVRecEvent
tv_rec.cpp:841 (FinishedRecording) TVRec[90]:
FinishedRecording(10072_2022-04-15T22:29:00Z) damaged
recq:#012<RecordingQuality overall_score="0"
key="10072_2022-04-15T22:29:00Z" continuity_error_count="0"
packet_count="7257810">#012    <Gap start="2022-04-15T22:30:00Z"
end="2022-04-15T22:39:49Z" duration="589" />#012</RecordingQuality>

On my system, that can happen at that time of the week as that is when
the weekly database check and backup is done and the load of that,
like the housekeeper task, can stop mythbackend from working properly.
Such recordings do not always show up as marked in yellow.  If a 0
byte recording file was created, then that will enable a yellow
listing, but if no recording file was ever created, there is nothing
to be marked in yellow and so you have to watch out for things like
that some other way.

To check for these messages, these commands are useful:

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

That will find any overall_score value that starts with a 0, so any
where mythbackend calculated the value as less than 1.0.

And this will find any non-zero continuity_error_count messages:

grep -a "continuity_error_count=\"[1-9]"
/var/log/mythtv/mythbackend.log