On Mon, 31 Oct 2016 20:28:37 +1300, you wrote:
>Hi,
>
>
>
>I have an ongoing saga with my Myth setup and HD HomeRun.
>
>
>
>I have two HDHRs and so trying to pin down absolutely that it is not in some
>way my MythSvr I did an experiment. I created a quick and dirty NextPVR
>install on an old Windows laptop and connected it to one HDHR and left Myth
>with the other HDHR.
>
>
>
>Myth continued to have pretty consistent and really annoying pixelation
>while the NextPVR didn't. Today I swapped the tuners and got the same result
>though this time I notice I did get some, though not nearly as much,
>pixelation with the NextPVR. The two HDHRs are connected to the same
>splitter, I haven't so much as turned them off.
>
>
>
>Remembering I have an old 0.25 Myth which had been working fine up till the
>last few months and I have spent what I consider a reasonable amount,
>approx. $300, on the TV guy.
>
>
>
>Any idea why Myth should produce a file that has more pixelation. I have
>tested both using VLC on my Windows machine
>
>
>
>Cheers
The obvious candidate for causing problems on the new MythTV box but
not on a different Windows box or older MythTV box would be the
network. What Ethernet card does the MythTV box have? Some Linux
Ethernet drivers are not the best, although the one I had problems
with (Realtek 8111E) seems to be improved in the 4.4 kernels.
The first thing I would recommend doing is turning on a higher level
of logging of recordings in mythbackend by adding the "-v record"
option to its command line. In Mythbuntu 16.04, you do that by
creating a /etc/mythtv/additional.args file containing this:
ADDITIONAL_ARGS=-v record
Make the file chown mythtv:mythtv. That causes log messages such as
this to be reported at the end of each recording:
Oct 31 22:34:01 mypvr mythbackend: mythbackend[4711]: I TVRecEvent
tv_rec.cpp:849 (FinishedRecording) TVRec[2]:
FinishedRecording(1001_2016-10-31T08:29:00Z) good
recq:<RecordingQuality overall_score="1"
key="1001_2016-10-31T08:29:00Z" countinuity_error_count="0"
packet_count="18048565" />
and like this if there are any errors that mythbackend detected:
Oct 26 01:54:00 mypvr mythbackend: mythbackend[8727]: I TVRecEvent
tv_rec.cpp:849 (FinishedRecording) TVRec[27]:
FinishedRecording(4092_2016-10-25T11:59:00Z) good
recq:<RecordingQuality overall_score="0.987"
key="4092_2016-10-25T11:59:00Z" countinuity_error_count="93"
packet_count="4122578">#012 <Gap start="2016-10-25T12:20:41Z"
end="2016-10-25T12:20:51Z" duration="10" />#012 <Gap
start="2016-10-25T12:21:36Z" end="2016-10-25T12:21:39Z" duration="3"
/>#012 <Gap start="2016-10-25T12:34:43Z" end="2016-10-25T12:34:46Z"
duration="2" />#012 <Gap start="2016-10-25T12:40:48Z"
end="2016-10-25T12:40:51Z" duration="3" />#012 <Gap
start="2016-10-25T12:41:01Z" end="2016-10-25T12:41:11Z" duration="10"
/>#012</RecordingQuality>
This command will show any recent recordings with errors:
grep "overall_score=\"0" /var/log/mythtv/mythbackend.log
In my experience the timestamps that mythbackend reports for gaps
correspond exactly to where I notice a short gap in a recording, or a
little pixellation or an audio blip. However, not all pixellation
results in a gap message.
Then I would install Wireshark and set it up to record all the traffic
between the MythTV box and an HDHR tuner. Since I do not have an
HDHR, I can not advise on exactly what capture filters would be
needed, but I think a simple "host <HDHR IP address>" should suffice.
With Wireshark running, do a recording that gets errors, and then
match the error timestamps from mythbackend with the Wireshark
captures to see if there are any network problems at that time.
Doing a capture of all the packets for a full recording will create
quite a big capture file (order of magnitude the same as for the
recording file mythbackend will be writing), so make sure it is
getting stored to a location with enough space and will not cause too
much disk activity that might interfere with the recording process or
database updating.
If your MythTV box has spare slots and you have an Ethernet card you
can put in one, even if it is a PCI card instead of a PCIe one, it
would be worth trying that card instead of the motherboard Ethernet
port for talking to the HDHRs. I believe HDHRs only use 100 Mbit/s
Ethernet, so even an old 100 Mbit/s PCI card would be useful for
testing this, especially if it is one that has known good Linux
drivers, such as most Intel chipsets.
_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz Archives
http://www.gossamer-threads.com/lists/mythtv/mythtvnz/