<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 7, 2022 at 7:42 AM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz">stephen_agent@jsw.gen.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, 7 May 2022 06:49:27 -0400, you wrote:<br>
<br>
>Since I'm getting no errors in recording, no listing of programs in the<br>
>library that have the text in Yellow indicating excessive errors, I'm going<br>
>to assume I have no problem at all, but I'll investigate. I could always<br>
>install Kubuntu 21.10 and MythTV v32 on a USB3 SSD and boot that to test if<br>
>it's a software thing.<br>
><br>
>Jim A<br>
<br>
The yellow of excessive errors is indicating a bad problem.  If you<br>
want to see if there are any errors at all, then you can add the "-v<br>
record" option to the mythbackend command line to get more detailed<br>
logging.  In Ubuntu, you do that in the /etc/mythtv/additional.args<br>
file.  This is what I have:<br>
<br>
root@mypvr:/etc/mythtv# cat additional.args<br>
ADDITIONAL_ARGS=-v record,dvbcam<br>
<br>
After restarting mythbackend, you will then get messages like this at<br>
the end of each perfect recording:<br>
<br>
May  2 23:29:29 mypvr mythbackend: mythbackend[1869365]: I TVRecEvent<br>
tv_rec.cpp:841 (FinishedRecording) TVRec[2]:<br>
FinishedRecording(1013_2022-05-02T10:28:00Z) good<br>
recq:#012<RecordingQuality overall_score="1"<br>
key="1013_2022-05-02T10:28:00Z" continuity_error_count="0"<br>
packet_count="15777135" /><br>
<br>
And when there are errors, you get messages like this:<br>
<br>
May  2 23:29:00 mypvr mythbackend: mythbackend[1869365]: I TVRecEvent<br>
tv_rec.cpp:841 (FinishedRecording) TVRec[96]:<br>
FinishedRecording(10070_2022-05-02T10:29:00Z) good<br>
recq:#012<RecordingQuality overall_score="1"<br>
key="10070_2022-05-02T10:29:00Z" continuity_error_count="1"<br>
packet_count="14706294" /><br>
<br>
In that case, there was a continuity error - as I understand it, that<br>
means that a packet was received with a packet number that was larger<br>
than 1 higher than the last packet received of the same type, so it<br>
indicates a possible missing or corrupt packet.  As there was only 1<br>
such error, mythbackend did not calculate its overall_score value as<br>
less than 1.0.<br>
<br>
Here is another:<br>
<br>
May  2 20:34:02 mypvr mythbackend: mythbackend[1869365]: I TVRecEvent<br>
tv_rec.cpp:841 (FinishedRecording) TVRec[90]:<br>
FinishedRecording(10072_2022-05-02T07:29:00Z) good<br>
recq:#012<RecordingQuality overall_score="1"<br>
key="10072_2022-05-02T07:29:00Z" continuity_error_count="28"<br>
packet_count="18970429" /><br>
<br>
I am a bit surprised by that one, as I would have expected that 28<br>
continuity errors would have caused the overall_score to drop.<br>
<br>
Here is one with a gap at the start of the recording:<br>
<br>
Apr 27 21:34:00 mypvr mythbackend: mythbackend[1127578]: I TVRecEvent<br>
tv_rec.cpp:841 (FinishedRecording) TVRec[1]:<br>
FinishedRecording(1001_2022-04-27T08:30:00Z) damaged<br>
recq:#012<RecordingQuality overall_score="0.986667"<br>
key="1001_2022-04-27T08:30:00Z" continuity_error_count="0"<br>
packet_count="17123216">#012    <Gap start="2022-04-27T08:30:00Z"<br>
end="2022-04-27T08:30:16Z" duration="16" />#012</RecordingQuality><br>
<br>
Gaps almost always cause the overall_score to decrease.  In this case,<br>
the 16 second gap at the start of the recording is measured from the<br>
starttime for the recording, not from when the tuner started its<br>
pre-roll, so in my case with 60 s of pre-roll, it is actually a 76<br>
second gap before the recording started properly.  That is something<br>
that my system does, probably due to a problem with the database<br>
housekeeper task running and overloading my system.  It only seems to<br>
happen on systems with large databases - mine is huge.<br>
<br>
Here is a recording that never started:<br>
<br>
Apr 16 11:04:00 mypvr mythbackend: mythbackend[1291924]: I TVRecEvent<br>
tv_rec.cpp:841 (FinishedRecording) TVRec[90]:<br>
FinishedRecording(10072_2022-04-15T22:29:00Z) damaged<br>
recq:#012<RecordingQuality overall_score="0"<br>
key="10072_2022-04-15T22:29:00Z" continuity_error_count="0"<br>
packet_count="7257810">#012    <Gap start="2022-04-15T22:30:00Z"<br>
end="2022-04-15T22:39:49Z" duration="589" />#012</RecordingQuality><br>
<br>
On my system, that can happen at that time of the week as that is when<br>
the weekly database check and backup is done and the load of that,<br>
like the housekeeper task, can stop mythbackend from working properly.<br>
Such recordings do not always show up as marked in yellow.  If a 0<br>
byte recording file was created, then that will enable a yellow<br>
listing, but if no recording file was ever created, there is nothing<br>
to be marked in yellow and so you have to watch out for things like<br>
that some other way.<br>
<br>
To check for these messages, these commands are useful:<br>
<br>
grep -a "overall_score=\"0" /var/log/mythtv/mythbackend.log<br>
<br>
That will find any overall_score value that starts with a 0, so any<br>
where mythbackend calculated the value as less than 1.0.<br>
<br>
And this will find any non-zero continuity_error_count messages:<br>
<br>
grep -a "continuity_error_count=\"[1-9]"<br>
/var/log/mythtv/mythbackend.log<br></blockquote><div><br></div><div>This sounds like a good technique I should add to my backend.  Since I have a spare HDHomeRun Quatro, I reconfigured my backend to only have that networked tuner and I removed the PCIe tuner from the system.  Everything is back to normal as to signal strength and good recordings. </div><div><br></div><div>I will install the PCIe tuner in an older test system and install Ubuntu 20.04 LTS and MythTVB v31 and see what the signal strength looks like then.  If it's still 50%, I'll assume the card is failing and trash it. I was looking for an excuse to buy a new ATSC 3.0 tuner and this is almost a justification if I stretch the reasoning.</div><div><br></div><div>Jim A</div><div><br></div></div></div>