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

James Abernathy jfabernathy at gmail.com
Sun May 8 12:39:11 UTC 2022


On Sun, May 8, 2022 at 5:44 AM James Abernathy <jfabernathy at gmail.com>
wrote:

>
>
> On Sat, May 7, 2022 at 7:42 AM Stephen Worthington <
> stephen_agent at jsw.gen.nz> wrote:
>
>> 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
>>
>
> 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.
>
> 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.
>
> Jim A
>

Results of my first test of the Hauppauge WinTV Quad HD in a new system
with Ubuntu 20.04.3 LTS and mythtv v31.

I installed Ubuntu 20.04.3 minimal and added the apt repository for v31.
The install was as expected and I setup the 4 tuners to correspond to the
Quad tuner PCIe card.

I used a table top antenna in my lab since I didn't have a tap for the big
attic antenna.  I could not get the PBS station 40 miles away as expected
but the nearby stations all scanned.  While watching LiveTV, I noticed that
the signal strength displayed was 80-100% instead of 40-50% in V32 Ubuntu
22.04, my production backend.

I'll try later today or tomorrow to move the test PC to a room that can
access the same 8-way splitter that all my other tuners and tvs are
connected to.  At this point it's looking like the difference between v31
and v32 or Ubuntu 20.04 and 22.04.

Where I'm located with respect to the TV towers you can get great signals
with a coat hanger jammed into the F-connector.

Jim A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20220508/eb47105d/attachment.htm>


More information about the mythtv-users mailing list