Mailing List Archive

On Fri, 6 May 2022 at 22:16, James Abernathy <jfabernathy@gmail.com> wrote:

> I've been on v32 for sometime now. Today I was watching live TV via
> Mythfrontend and noticed that all my stations' signal strength reported in
> the 40-50% when they normally report 90-100%. I'm about 10 miles from the
> antenna farm in Garner, NC where all the major stations locally have their
> towers. So signal strength has never been a problem. I do not have any
> issues with breaking-up of my pictures or errors in my recordings. My
> antenna is in the attic and it, the cabling or the Hauppauge WinTV Quad
> tuner cards have not been disturbed.
>
> The odd thing is I also have a HDHomeRun Duo connected to the same antenna
> and its signal strengths are still high like they used to be.
>
> Has something changed in the way Mythtv calculated signal % for the
> display on Live TV?
>
> Nothing has changed in this part of the software recently as far as I
know. I have not really been looking at this for a while but it is always
possible that something has been changed accidentally. It could also be
that there has been a change in the Hauppauge driver or in the Linux DVB
software that causes this. The HDHomeRun devices compute the signal
strength all by themselves and MythTV just receives the number. If that is
still the same then your antenna signal is most likely also still
completely OK.

Klaas.

On Fri, May 6, 2022 at 4:53 PM Klaas de Waal <klaas.de.waal@gmail.com>
wrote:

>
>
> On Fri, 6 May 2022 at 22:16, James Abernathy <jfabernathy@gmail.com>
> wrote:
>
>> I've been on v32 for sometime now. Today I was watching live TV via
>> Mythfrontend and noticed that all my stations' signal strength reported in
>> the 40-50% when they normally report 90-100%. I'm about 10 miles from the
>> antenna farm in Garner, NC where all the major stations locally have their
>> towers. So signal strength has never been a problem. I do not have any
>> issues with breaking-up of my pictures or errors in my recordings. My
>> antenna is in the attic and it, the cabling or the Hauppauge WinTV Quad
>> tuner cards have not been disturbed.
>>
>> The odd thing is I also have a HDHomeRun Duo connected to the same
>> antenna and its signal strengths are still high like they used to be.
>>
>> Has something changed in the way Mythtv calculated signal % for the
>> display on Live TV?
>>
>> Nothing has changed in this part of the software recently as far as I
> know. I have not really been looking at this for a while but it is always
> possible that something has been changed accidentally. It could also be
> that there has been a change in the Hauppauge driver or in the Linux DVB
> software that causes this. The HDHomeRun devices compute the signal
> strength all by themselves and MythTV just receives the number. If that is
> still the same then your antenna signal is most likely also still
> completely OK.
>
> Klaas.
>
> _______________________________________________
>
> Could it be the on-board amplifier of your Quad tuner?

On Fri, May 6, 2022 at 9:38 PM Daryl McDonald <darylangela@gmail.com> wrote:

>
>
> On Fri, May 6, 2022 at 4:53 PM Klaas de Waal <klaas.de.waal@gmail.com>
> wrote:
>
>>
>>
>> On Fri, 6 May 2022 at 22:16, James Abernathy <jfabernathy@gmail.com>
>> wrote:
>>
>>> I've been on v32 for sometime now. Today I was watching live TV via
>>> Mythfrontend and noticed that all my stations' signal strength reported in
>>> the 40-50% when they normally report 90-100%. I'm about 10 miles from the
>>> antenna farm in Garner, NC where all the major stations locally have their
>>> towers. So signal strength has never been a problem. I do not have any
>>> issues with breaking-up of my pictures or errors in my recordings. My
>>> antenna is in the attic and it, the cabling or the Hauppauge WinTV Quad
>>> tuner cards have not been disturbed.
>>>
>>> The odd thing is I also have a HDHomeRun Duo connected to the same
>>> antenna and its signal strengths are still high like they used to be.
>>>
>>> Has something changed in the way Mythtv calculated signal % for the
>>> display on Live TV?
>>>
>>> Nothing has changed in this part of the software recently as far as I
>> know. I have not really been looking at this for a while but it is always
>> possible that something has been changed accidentally. It could also be
>> that there has been a change in the Hauppauge driver or in the Linux DVB
>> software that causes this. The HDHomeRun devices compute the signal
>> strength all by themselves and MythTV just receives the number. If that is
>> still the same then your antenna signal is most likely also still
>> completely OK.
>>
>> Klaas.
>>
>> _______________________________________________
>>
>> Could it be the on-board amplifier of your Quad tuner?
>
>
>
1. I'm using the standard Kubuntu 22.04 kernel 5.15.0-27-generic. So I'm
not using the special Hauppauge kernel. I've been doing this for several
years. I don't think there is anything in the Hauppauge kernel that is not
in the main kernel.
2. I'm not sure how I would test the on-board amplifier. At this point I'd
lean toward it being a display software issue because in the past if the
signal on Live TV showed 50% or less I could not lock the signal enough to
view it. At this point I get no errors on any channel and the signals are
mostly in the 50s. My PBS station 40 miles away is usually around 50 now
reads 25 and it's coming in clear.

Jim A

On Fri, 6 May 2022 22:05:30 -0400, you wrote:

>1. I'm using the standard Kubuntu 22.04 kernel 5.15.0-27-generic. So I'm
>not using the special Hauppauge kernel. I've been doing this for several
>years. I don't think there is anything in the Hauppauge kernel that is not
>in the main kernel.
>2. I'm not sure how I would test the on-board amplifier. At this point I'd
>lean toward it being a display software issue because in the past if the
>signal on Live TV showed 50% or less I could not lock the signal enough to
>view it. At this point I get no errors on any channel and the signals are
>mostly in the 50s. My PBS station 40 miles away is usually around 50 now
>reads 25 and it's coming in clear.
>
>Jim A

MythTV just reports the signal strength values it receives from the
tuner. It does no calculations. It is not possible to compare the
signal strength reports between different types of tuners (even from
the same manufacturer) as they are not calibrated, so you do not know
what the numbers actually mean. There has always been significant
difference between various tuners as to what they report from the same
aerial connection. Your getting 90-100% from the HDHRs and only
40-50% from the WinTV Quads is quite normal. The only thing that the
signal level reports can be used for is to compare with previous
reports from the exact same tuner. If the WinTV Quad tuners are now
reporting a different signal strength when the HDHRs are not, either
there has been a change in your aerial system (maybe you have a
splitter that is going bad), or the WinTV drivers have been updated to
cause the change. If you are actually getting a lower signal on the
WinTV Quad tuners, but are still getting good recordings, that is
possible as TV tuners have a very wide range of signal levels that
they operate over, and the modern tuners typically have an even wider
range than older ones.

Tuners can also report signal to noise ratios and bit error rates. The
bit error rates (if reported), are the most important - if there are
any errors, you have a problem that needs fixing as your signal is bad
enough that the digital side of the receiver is seeing errors. The
signal to noise ratio values are also calculated by the tuner and are
uncalibrated, but they are usually a better indicator of reality as
they are a ratio which is therefore less affected by the lack of
calibration. But in order to interpret them, you have to know the
characteristics of the specific tuner (what s/n ratio it needs to
perform properly), and that data is almost never provided by the
manufacturer.

In the case of the modern multi-tuner devices like the WinTV Quad, the
aerial input goes through an onboard low noise amplifier (LNA), and
then into a splitter that sends the signal to the individual tuners.
Normally, for a 4 tuner device, the LNA will amplify the incoming
signals to 4 times the level plus a little, so that when it is split 4
ways to the individual tuners, each tuner will receive the same level
that is seen at the aerial input before the LNA. But it is also
possible to design the individual tuners to have a different
sensitivity so that they expect a larger or smaller level in their
individual inputs compared to the aerial input, and then adjust the
amplification in the LNA to match that sensitivity.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Fri, May 6, 2022 at 11:57 PM Stephen Worthington <
stephen_agent@jsw.gen.nz> wrote:

> On Fri, 6 May 2022 22:05:30 -0400, you wrote:
>
> >1. I'm using the standard Kubuntu 22.04 kernel 5.15.0-27-generic. So I'm
> >not using the special Hauppauge kernel. I've been doing this for several
> >years. I don't think there is anything in the Hauppauge kernel that is
> not
> >in the main kernel.
> >2. I'm not sure how I would test the on-board amplifier. At this point I'd
> >lean toward it being a display software issue because in the past if the
> >signal on Live TV showed 50% or less I could not lock the signal enough to
> >view it. At this point I get no errors on any channel and the signals are
> >mostly in the 50s. My PBS station 40 miles away is usually around 50 now
> >reads 25 and it's coming in clear.
> >
> >Jim A
>
> MythTV just reports the signal strength values it receives from the
> tuner. It does no calculations. It is not possible to compare the
> signal strength reports between different types of tuners (even from
> the same manufacturer) as they are not calibrated, so you do not know
> what the numbers actually mean. There has always been significant
> difference between various tuners as to what they report from the same
> aerial connection. Your getting 90-100% from the HDHRs and only
> 40-50% from the WinTV Quads is quite normal. The only thing that the
> signal level reports can be used for is to compare with previous
> reports from the exact same tuner. If the WinTV Quad tuners are now
> reporting a different signal strength when the HDHRs are not, either
> there has been a change in your aerial system (maybe you have a
> splitter that is going bad), or the WinTV drivers have been updated to
> cause the change. If you are actually getting a lower signal on the
> WinTV Quad tuners, but are still getting good recordings, that is
> possible as TV tuners have a very wide range of signal levels that
> they operate over, and the modern tuners typically have an even wider
> range than older ones.
>
> Tuners can also report signal to noise ratios and bit error rates. The
> bit error rates (if reported), are the most important - if there are
> any errors, you have a problem that needs fixing as your signal is bad
> enough that the digital side of the receiver is seeing errors. The
> signal to noise ratio values are also calculated by the tuner and are
> uncalibrated, but they are usually a better indicator of reality as
> they are a ratio which is therefore less affected by the lack of
> calibration. But in order to interpret them, you have to know the
> characteristics of the specific tuner (what s/n ratio it needs to
> perform properly), and that data is almost never provided by the
> manufacturer.
>
> In the case of the modern multi-tuner devices like the WinTV Quad, the
> aerial input goes through an onboard low noise amplifier (LNA), and
> then into a splitter that sends the signal to the individual tuners.
> Normally, for a 4 tuner device, the LNA will amplify the incoming
> signals to 4 times the level plus a little, so that when it is split 4
> ways to the individual tuners, each tuner will receive the same level
> that is seen at the aerial input before the LNA. But it is also
> possible to design the individual tuners to have a different
> sensitivity so that they expect a larger or smaller level in their
> individual inputs compared to the aerial input, and then adjust the
> amplification in the LNA to match that sensitivity.
>

In the past both the HDHR Quatro and WinTV Quad all had about the same
signal strength reported between 90 and 100%. Except for the PBS station 40
miles away which was 50-60 depending on weather and which tuner.

To debug this, I guess for starters I could take the splitter out of the
loop and cable the antenna to the WinTV Quad directly and then to the HDHR
Quatro and see if things change.

My location is unique in the sense that I can literally see the flashing
aircraft warning lights on the TV towers about 10 miles away. The issue
has always been to turn the antenna 25 to 40 degrees away from the straight
line of sight from those towers so I could get a signal from the PBS
station at all. If I point the antenna directly at the TV tower farm I get
100 percent on all signal, quality, and symbol quality on all channels but
can't get PBS.

Not sure when this all changes, but this is the first time I've noticed the
reduction of WinTV Quad signal. The only change is I've upgraded my v32
Kubuntu 21.10 to Kubuntu 22.04.

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

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@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
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Sat, May 7, 2022 at 7:42 AM Stephen Worthington <stephen_agent@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@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

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

>
>
> On Sat, May 7, 2022 at 7:42 AM Stephen Worthington <
> stephen_agent@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@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

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

>
> 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
>

I've narrowed down when the signal reporting gets changed. On my newly
built test system with MythTV v31 on Ubuntu 20.04.3 LTS my signals were
reported as ~100% on most of my channels using my Hauppauge WinTV quadTV as
it had for years on my production backend.

I added the ppa:mythbuntu/32 repository and upgraded to v32. The system
updated all 21 packages and everything was working as before but now on v32.

But when I use Watch Live TV all my reported signal strengths were between
40-50%. So the change is MythTV v32 related and not the version of Ubuntu.
The OS remained at Ubuntu 20.04 with latest patches without any package
updates to Linux during this test.

Jim A

On 09/05/2022 11:41, James Abernathy wrote:
>
>
> On Sun, May 8, 2022 at 8:39 AM James Abernathy <jfabernathy@gmail.com
> <mailto:jfabernathy@gmail.com>> wrote:
>
>
> 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
>
>
> I've narrowed down when the signal reporting gets changed. On my newly
> built test system with MythTV v31 on Ubuntu 20.04.3 LTS my signals were
> reported as ~100% on most of my channels using my Hauppauge WinTV quadTV
> as it had for years on my production backend.
>
> I added the ppa:mythbuntu/32 repository and upgraded to v32. The system
> updated all 21 packages and everything was working as before but now on v32.
>
> But when I use Watch Live TV all my reported signal strengths were
> between 40-50%.  So the change is MythTV v32 related and not the version
> of Ubuntu. The OS remained at Ubuntu 20.04 with latest patches without
> any package updates to Linux during this test.
>
> Jim A

So the comparison is between the base distro v31 and current 32 fixes,
and quite a lot may have happened over that span. But I think you are
giving the number too much significance. IMHO it's primarily for antenna
alignment, and a bigger number in the same setup is better, but the
absolute value probably doesn't mean much; particularly with an indoor
antenna, a complicated feed system of passive splitters and maybe badly
terminated cable runs. And the trees round me are coming into leaf...

Cheers,

John P
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 09/05/2022 12:11, John Pilkington wrote:
> On 09/05/2022 11:41, James Abernathy wrote:
>>
>>
>> On Sun, May 8, 2022 at 8:39 AM James Abernathy <jfabernathy@gmail.com
>> <mailto:jfabernathy@gmail.com>> wrote:
>>
>>
>>     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
>>
>>
>> I've narrowed down when the signal reporting gets changed. On my newly built test system with
>> MythTV v31 on Ubuntu 20.04.3 LTS my signals were reported as ~100% on most of my channels using my
>> Hauppauge WinTV quadTV as it had for years on my production backend.
>>
>> I added the ppa:mythbuntu/32 repository and upgraded to v32. The system updated all 21 packages
>> and everything was working as before but now on v32.
>>
>> But when I use Watch Live TV all my reported signal strengths were between 40-50%.  So the change
>> is MythTV v32 related and not the version of Ubuntu. The OS remained at Ubuntu 20.04 with latest
>> patches without any package updates to Linux during this test.
>>
>> Jim A
>
> So the comparison is between the base distro v31 and current 32 fixes, and quite a lot may  have
> happened over that span.  But I think you are giving the number too much significance. IMHO it's
> primarily for antenna alignment, and a bigger number in the same setup is better, but the absolute
> value probably doesn't mean much; particularly with an indoor antenna, a complicated feed system of
> passive splitters and maybe badly terminated cable runs.  And the trees round me are coming into
> leaf...
>
But he's reporting identical setup conditions with nothing changed except the mythv version. The
hardware is immaterial here. It is *just* possible that trees may have come into leaf between his
testing with V31 and the upgrade to V32, but I'm not buying that.

--

Mike Perkins

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 09/05/2022 11:41, James Abernathy wrote:

>
>
> On Sun, May 8, 2022 at 8:39 AM James Abernathy <jfabernathy@gmail.com>
> wrote:
>
>
> 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
>
>
> I've narrowed down when the signal reporting gets changed. On my newly
> built test system with MythTV v31 on Ubuntu 20.04.3 LTS my signals
> were reported as ~100% on most of my channels using my Hauppauge WinTV
> quadTV as it had for years on my production backend.
>
> I added the ppa:mythbuntu/32 repository and upgraded to v32. The
> system updated all 21 packages and everything was working as before
> but now on v32.
>
> But when I use Watch Live TV all my reported signal strengths were
> between 40-50%.  So the change is MythTV v32 related and not the
> version of Ubuntu. The OS remained at Ubuntu 20.04 with latest patches
> without any package updates to Linux during this test.
>
> Jim A
>

Could be this commit which changed the signal strength range for DVBv5 :-

https://github.com/MythTV/mythtv/commit/5d76841b8c1878


You could  try starting the backend with --dvbv3 to see what you get
with the old DVB v3 API.


Like other have said if it not causing you any problems then I wouldn't
worry to much about it.


Paul H.

On Mon, May 9, 2022 at 7:41 AM Paul Harrison <mythtv@mythqml.net> wrote:

> On 09/05/2022 11:41, James Abernathy wrote:
>
>
>
> On Sun, May 8, 2022 at 8:39 AM James Abernathy <jfabernathy@gmail.com>
> wrote:
>
>>
>> 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
>>
>
> I've narrowed down when the signal reporting gets changed. On my newly
> built test system with MythTV v31 on Ubuntu 20.04.3 LTS my signals were
> reported as ~100% on most of my channels using my Hauppauge WinTV quadTV as
> it had for years on my production backend.
>
> I added the ppa:mythbuntu/32 repository and upgraded to v32. The system
> updated all 21 packages and everything was working as before but now on v32.
>
> But when I use Watch Live TV all my reported signal strengths were between
> 40-50%. So the change is MythTV v32 related and not the version of Ubuntu.
> The OS remained at Ubuntu 20.04 with latest patches without any package
> updates to Linux during this test.
>
> Jim A
>
>
> Could be this commit which changed the signal strength range for DVBv5 :-
>
> https://github.com/MythTV/mythtv/commit/5d76841b8c1878
>
>
> You could try starting the backend with --dvbv3 to see what you get with
> the old DVB v3 API.
>
>
> Like other have said if it not causing you any problems then I wouldn't
> worry to much about it.
>
>
> Paul H.
>
You are correct. Starting the mythtv-backend with --dvbv3 does restore the
signal strength to what I was seeing on v31.

So what I'm hearing is by default in v32 the signal strength is based on
dbm instead of %. Are there any problems using --dvbv3 instead of the
default??

Jim A

On Mon, May 9, 2022 at 8:33 AM James Abernathy <jfabernathy@gmail.com>
wrote:

>
>
> On Mon, May 9, 2022 at 7:41 AM Paul Harrison <mythtv@mythqml.net> wrote:
>
>> Could be this commit which changed the signal strength range for DVBv5 :-
>>
>> https://github.com/MythTV/mythtv/commit/5d76841b8c1878
>>
>>
>> You could try starting the backend with --dvbv3 to see what you get with
>> the old DVB v3 API.
>>
>>
>> Like other have said if it not causing you any problems then I wouldn't
>> worry to much about it.
>>
>>
>> Paul H.
>>
> You are correct. Starting the mythtv-backend with --dvbv3 does restore the
> signal strength to what I was seeing on v31.
>
> So what I'm hearing is by default in v32 the signal strength is based on
> dbm instead of %. Are there any problems using --dvbv3 instead of the
> default??
>
> Jim A
>

The problem I see with this new change in dvbv5 is the screen display still
says "%" after the number. There is no way this makes sense to me compared
to other tuners. Now that I know I can follow it. but in a system with a
HDHomeRun tuner and a DVB tuner on the same antenna the concept of one
tuner at 100% and another at 50% is confusing.

Jim A

On 09/05/2022 13:33, James Abernathy wrote:

>
>
> On Mon, May 9, 2022 at 7:41 AM Paul Harrison <mythtv@mythqml.net> wrote:
>
> On 09/05/2022 11:41, James Abernathy wrote:
>
>>
>>
>> On Sun, May 8, 2022 at 8:39 AM James Abernathy
>> <jfabernathy@gmail.com> wrote:
>>
>>
>> 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
>>
>>
>> I've narrowed down when the signal reporting gets changed. On my
>> newly built test system with MythTV v31 on Ubuntu 20.04.3 LTS my
>> signals were reported as ~100% on most of my channels using my
>> Hauppauge WinTV quadTV as it had for years on my production backend.
>>
>> I added the ppa:mythbuntu/32 repository and upgraded to v32. The
>> system updated all 21 packages and everything was working as
>> before but now on v32.
>>
>> But when I use Watch Live TV all my reported signal strengths
>> were between 40-50%.  So the change is MythTV v32 related and not
>> the version of Ubuntu. The OS remained at Ubuntu 20.04 with
>> latest patches without any package updates to Linux during this test.
>>
>> Jim A
>>
>
> Could be this commit which changed the signal strength range for
> DVBv5 :-
>
> https://github.com/MythTV/mythtv/commit/5d76841b8c1878
>
>
> You could  try starting the backend with --dvbv3 to see what you
> get with the old DVB v3 API.
>
>
> Like other have said if it not causing you any problems then I
> wouldn't worry to much about it.
>
>
> Paul H.
>
> You are correct. Starting the mythtv-backend with --dvbv3 does restore
> the signal strength to what I was seeing on v31.
>
> So what I'm hearing is by default in v32 the signal strength is based
> on dbm instead of %. Are there any problems using --dvbv3 instead of
> the default??
>
> Jim A
>
>

The value is still calculated as a percent in the range 0 to 100% it's
just the range of values accepted from the driver has been increased.


It was   -100dBm to -20dBm it is now -100dBm to 0dBm. Previously any
value between -20dBm and 0dBm was being rejected and I think it would
fall back to the DVB v3 legacy driver and use the value from that which
will be the same value you got by forcing the use of  DVBv3.


I think because you are in a very strong signal area the signal strength
was probably outside the previous allowed range but is now inside the
new range. I tried to find any documentation related to what the range
should be but a quick Google didn't find anything so no idea which value
is correct \0/ I recall there is a DVB tool called  femon that you can
use to monitor the signal input which may be useful to compare the output.


Paul H.

On 09/05/2022 13:44, James Abernathy wrote:

>
>
> On Mon, May 9, 2022 at 8:33 AM James Abernathy <jfabernathy@gmail.com>
> wrote:
>
>
>
> On Mon, May 9, 2022 at 7:41 AM Paul Harrison <mythtv@mythqml.net>
> wrote:
>
> Could be this commit which changed the signal strength range
> for DVBv5 :-
>
> https://github.com/MythTV/mythtv/commit/5d76841b8c1878
>
>
> You could  try starting the backend with --dvbv3 to see what
> you get with the old DVB v3 API.
>
>
> Like other have said if it not causing you any problems then I
> wouldn't worry to much about it.
>
>
> Paul H.
>
> You are correct. Starting the mythtv-backend with --dvbv3 does
> restore the signal strength to what I was seeing on v31.
>
> So what I'm hearing is by default in v32 the signal strength is
> based on dbm instead of %. Are there any problems using --dvbv3
> instead of the default??
>
> Jim A
>
>
> The problem I see with this new change in dvbv5 is the screen display
> still says "%" after the number.  There is no way this makes sense to
> me compared to other tuners. Now that I know I can follow it. but in a
> system with a HDHomeRun tuner and a DVB tuner on the same antenna the
> concept of one tuner at 100% and another at 50% is confusing.
>
> Jim A
>
>
Unfortunately you can't compare the signal levels from different devices
like that they all report the signal levels differently. Even DVB cards
from the same manufacturer can report signal levels differently.


Paul H.

On 10/05/2022 16:13, Paul Harrison wrote:
> On 09/05/2022 13:44, James Abernathy wrote:
>
>>
>>
>> On Mon, May 9, 2022 at 8:33 AM James Abernathy <jfabernathy@gmail.com>
>> wrote:
>>
>>
>>
>> On Mon, May 9, 2022 at 7:41 AM Paul Harrison <mythtv@mythqml.net>
>> wrote:
>>
>> Could be this commit which changed the signal strength range
>> for DVBv5 :-
>>
>> https://github.com/MythTV/mythtv/commit/5d76841b8c1878
>>
>>
>> You could  try starting the backend with --dvbv3 to see what
>> you get with the old DVB v3 API.
>>
>>
>> Like other have said if it not causing you any problems then I
>> wouldn't worry to much about it.
>>
>>
>> Paul H.
>>
>> You are correct. Starting the mythtv-backend with --dvbv3 does
>> restore the signal strength to what I was seeing on v31.
>>
>> So what I'm hearing is by default in v32 the signal strength is
>> based on dbm instead of %. Are there any problems using --dvbv3
>> instead of the default??
>>
>> Jim A
>>
>>
>> The problem I see with this new change in dvbv5 is the screen display
>> still says "%" after the number.  There is no way this makes sense to
>> me compared to other tuners. Now that I know I can follow it. but in a
>> system with a HDHomeRun tuner and a DVB tuner on the same antenna the
>> concept of one tuner at 100% and another at 50% is confusing.
>>
>> Jim A
>>
>>
> Unfortunately you can't compare the signal levels from different devices
> like that they all report the signal levels differently. Even DVB cards
> from the same manufacturer can report signal levels differently.
>
>
> Paul H.

All my tuners are fed via splitters from a single antenna-preamp, so
absolute signal-strenth percentages mean even less; but big-is-better
should still apply (and is used in Klaas's updates) except in
close-to-the-transmitter use-the-antenna-to-power-the-kettle situations.
Signal-to-noise ratio should be more important, but again measurements
are unlikely to be consistent across devices and manufacturers.

John P

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Tue, 10 May 2022 16:08:21 +0100, you wrote:

>On 09/05/2022 13:33, James Abernathy wrote:
>
>>
>>
>> On Mon, May 9, 2022 at 7:41 AM Paul Harrison <mythtv@mythqml.net> wrote:
>>
>> On 09/05/2022 11:41, James Abernathy wrote:
>>
>>>
>>>
>>> On Sun, May 8, 2022 at 8:39 AM James Abernathy
>>> <jfabernathy@gmail.com> wrote:
>>>
>>>
>>> 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
>>>
>>>
>>> I've narrowed down when the signal reporting gets changed. On my
>>> newly built test system with MythTV v31 on Ubuntu 20.04.3 LTS my
>>> signals were reported as ~100% on most of my channels using my
>>> Hauppauge WinTV quadTV as it had for years on my production backend.
>>>
>>> I added the ppa:mythbuntu/32 repository and upgraded to v32. The
>>> system updated all 21 packages and everything was working as
>>> before but now on v32.
>>>
>>> But when I use Watch Live TV all my reported signal strengths
>>> were between 40-50%.? So the change is MythTV v32 related and not
>>> the version of Ubuntu. The OS remained at Ubuntu 20.04 with
>>> latest patches without any package updates to Linux during this test.
>>>
>>> Jim A
>>>
>>
>> Could be this commit which changed the signal strength range for
>> DVBv5 :-
>>
>> https://github.com/MythTV/mythtv/commit/5d76841b8c1878
>>
>>
>> You could? try starting the backend with --dvbv3 to see what you
>> get with the old DVB v3 API.
>>
>>
>> Like other have said if it not causing you any problems then I
>> wouldn't worry to much about it.
>>
>>
>> Paul H.
>>
>> You are correct. Starting the mythtv-backend with --dvbv3 does restore
>> the signal strength to what I was seeing on v31.
>>
>> So what I'm hearing is by default in v32 the signal strength is based
>> on dbm instead of %. Are there any problems using --dvbv3 instead of
>> the default??
>>
>> Jim A
>>
>>
>
>The value is still calculated as a percent in the range 0 to 100% it's
>just the range of values accepted from the driver has been increased.
>
>
>It was ? -100dBm to -20dBm it is now -100dBm to 0dBm. Previously any
>value between -20dBm and 0dBm was being rejected and I think it would
>fall back to the DVB v3 legacy driver and use the value from that which
>will be the same value you got by forcing the use of? DVBv3.
>
>
>I think because you are in a very strong signal area the signal strength
>was probably outside the previous allowed range but is now inside the
>new range. I tried to find any documentation related to what the range
>should be but a quick Google didn't find anything so no idea which value
>is correct \0/ I recall there is a DVB tool called? femon that you can
>use to monitor the signal input which may be useful to compare the output.
>
>
>Paul H.

With DVBAPI v5, femon is superceded by the -m option of the
dvb-fe-tool program. This is from one of my DVB-T tuners:

root@mypvr:~# dvb-fe-tool -a 17 -m
Lock (0x1f) Signal= -50.00dBm C/N= 36.25dB
Layer A: Signal= 49.05% C/N= 72.57%
Lock (0x1f) Signal= -50.00dBm C/N= 36.25dB
Layer A: Signal= 49.05% C/N= 72.57%
Lock (0x1f) Signal= -50.00dBm C/N= 36.50dB
Layer A: Signal= 49.05% C/N= 73.07%

The femon program still works, but I think it uses DVBAPI v3:

root@mypvr:~# femon -a 17 -H
FE: Turbosight TBS 6209 (Octa DVB-T/T2/C/C2/ISDB-T) (DVBT)
status SCVYL | signal 49% | snr 73% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal 49% | snr 73% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal 49% | snr 73% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal 49% | snr 72% | ber 0 | unc 0 | FE_HAS_LOCK

It does report the BER (bit error rate) values though, which is a
useful number, unlike most of the others.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Sat, May 7, 2022 at 7:42 AM Stephen Worthington <stephen_agent@jsw.gen.nz>
wrote:

>
> 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
>

Stephen, I've added your-v record to a test mythtv-backend that uses only
the HDHR Quatro. I set up 2 recordings.
The 2 recordings from station 11701 are the ones in the log below that
concern me. The earlier one is the one that was flagged in Yellow test in
the media listing.

I ran the 2 commands you gave me and the results are below for 2
recordings. only the 2 from Station 11701 are of concern since they were
both Prime time HD programs on a good signal station. Is there a way to
tell if these problems were Tuner or Network traffic related??

grep -a "overall_score=\"0" /var/log/mythtv/mythbackend.log
May 12 16:10:39 rpi4-mythtv mythbackend: mythbackend[941]: I TVRecEvent
tv_rec.cpp:841 (FinishedRecording) TVRec[1]:
FinishedRecording(15001_2022-05-12T20:10:00Z) damaged
recq:#012<RecordingQuality overall_score="0.25"
key="15001_2022-05-12T20:10:00Z" continuity_error_count="0"
packet_count="73579">#012 <Gap start="2022-05-12T20:10:00Z"
end="2022-05-12T20:10:19Z" duration="19" />#012</RecordingQuality>
May 15 22:00:00 rpi4-mythtv mythbackend: mythbackend[974]: I
HDHRStreamHandler tv_rec.cpp:841 (FinishedRecording) TVRec[1]:
FinishedRecording(11701_2022-05-16T01:00:00Z) damaged
recq:#012<RecordingQuality overall_score="0.9"
key="11701_2022-05-16T01:00:00Z" continuity_error_count="9387"
packet_count="23833584" />
May 15 23:00:00 rpi4-mythtv mythbackend: mythbackend[974]: I TVRecEvent
tv_rec.cpp:841 (FinishedRecording) TVRec[1]:
FinishedRecording(11701_2022-05-16T02:00:00Z) damaged
recq:#012<RecordingQuality overall_score="0.9"
key="11701_2022-05-16T02:00:00Z" continuity_error_count="4954"
packet_count="25284058" />
May 16 22:00:00 rpi4-mythtv mythbackend: mythbackend[6529]: I
HDHRStreamHandler tv_rec.cpp:841 (FinishedRecording) TVRec[1]:
FinishedRecording(11701_2022-05-17T01:00:00Z) damaged
recq:#012<RecordingQuality overall_score="0.9"
key="11701_2022-05-17T01:00:00Z" continuity_error_count="9826"
packet_count="24994436" />
pi@rpi4-mythtv:~ $ grep -a "continuity_error_count=\"[1-9]"
/var/log/mythtv/mythbackend.log
May 15 22:00:00 rpi4-mythtv mythbackend: mythbackend[974]: I
HDHRStreamHandler tv_rec.cpp:841 (FinishedRecording) TVRec[1]:
FinishedRecording(11701_2022-05-16T01:00:00Z) damaged
recq:#012<RecordingQuality overall_score="0.9"
key="11701_2022-05-16T01:00:00Z" continuity_error_count="9387"
packet_count="23833584" />
May 15 23:00:00 rpi4-mythtv mythbackend: mythbackend[974]: I TVRecEvent
tv_rec.cpp:841 (FinishedRecording) TVRec[1]:
FinishedRecording(11701_2022-05-16T02:00:00Z) damaged
recq:#012<RecordingQuality overall_score="0.9"
key="11701_2022-05-16T02:00:00Z" continuity_error_count="4954"
packet_count="25284058" />
May 16 22:00:00 rpi4-mythtv mythbackend: mythbackend[6529]: I
HDHRStreamHandler tv_rec.cpp:841 (FinishedRecording) TVRec[1]:
FinishedRecording(11701_2022-05-17T01:00:00Z) damaged
recq:#012<RecordingQuality overall_score="0.9"
key="11701_2022-05-17T01:00:00Z" continuity_error_count="9826"
packet_count="24994436" />
May 16 23:00:00 rpi4-mythtv mythbackend: mythbackend[6529]: I TVRecEvent
tv_rec.cpp:841 (FinishedRecording) TVRec[1]:
FinishedRecording(11701_2022-05-17T02:00:00Z) good
recq:#012<RecordingQuality overall_score="1"
key="11701_2022-05-17T02:00:00Z" continuity_error_count="257"
packet_count="25125088" />

Jim A

> On May 17, 2022, at 7:12 AM, James Abernathy <jfabernathy@gmail.com> wrote:
>
>
>
> On Sat, May 7, 2022 at 7:42 AM Stephen Worthington <stephen_agent@jsw.gen.nz <mailto:stephen_agent@jsw.gen.nz>> wrote:
>
> 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
>
> Stephen, I've added your-v record to a test mythtv-backend that uses only the HDHR Quatro. I set up 2 recordings.
> The 2 recordings from station 11701 are the ones in the log below that concern me. The earlier one is the one that was flagged in Yellow test in the media listing.
>
> I ran the 2 commands you gave me and the results are below for 2 recordings. only the 2 from Station 11701 are of concern since they were both Prime time HD programs on a good signal station. Is there a way to tell if these problems were Tuner or Network traffic related??

As far as I know, the only way to check network problems is using the hdhomerun_config command to dump video to null and watch for errors in the output. I am pasting excepts from silicon dust on how to see the status during recording: Network errors will show up as ’n’ in the output below.

excerpted from https://info.hdhomerun.com/info/hdhomerun_config :

Note that to use the below to set a frequency/channel for the tuner to capture from below:

Tuning a physical channel
----------------------------

To set a channel use the set channel command:

format: hdhomerun_config <id> set /tuner<n>/channel <modulation>:<frequency>
format: hdhomerun_config <id> set /tuner<n>/channel <modulation>:<channel>
eg: hdhomerun_config FFFFFFFF set /tuner0/channel auto:651000000
eg: hdhomerun_config FFFFFFFF set /tuner0/channel auto:60

Supported modulation types can be queried with the get sys-features command:

hdhomerun_config <id> get /sys/features

To stop the tuner set the channel to none:

format: hdhomerun_config <id> set /tuner<n>/channel none
eg: hdhomerun_config FFFFFFFF set /tuner0/channel none


Saving a stream
---------------------------------------

The hdhomerun_config command can be used to automate the process of saving to the local filesystem:

format: hdhomerun_config <id> save /tuner<n> <filename>
eg: hdhomerun_config FFFFFFFF save /tuner0 capture.ts

While saving the stream, a single period “.” will be displayed every second. Additionally, as of the 20080609 release, the hdhomerun_config will detect reception and network errors, replacing the “.” with an alternative character to indicate the problem.

Example output:

............n...............................n..........ts..........
-- Video statistics --
23323 packets recieved, 2 network errors, 1 transport errors, 1 sequence errors

Advanced: A filename of “null” indicates no file should be created, allowing the use of the save command as a diagnostic tool.

Advanced: “-” may be used as a filename to indicate standard output, allowing the save command to be used as a pipe on supported platforms.

eg: hdhomerun_config FFFFFFFF save /tuner0 - | vlc -