[mythtv-users] Corrupt recording using HDHR Quatro

[Jim Abernathy]

On 12/20/19 7:39 AM, Stephen Worthington wrote:
> On Fri, 20 Dec 2019 07:07:42 -0500, you wrote:
>
>> I was experiencing a lot of corrupted recordings that my Raspberry Pi4
>> mythtv-backend was making from my HDHR Quatro tuner. I tested by also
>> recording the same program on another Mythtv backend using a PCIe tuner
>> card and saw no issues there.
>>
>> If you do the math, 4 HDTV OTA mpeg2 streams from a HDHR should be no
>> more than ~50Mb/s.  The HDHR has a 100Mb/s port. So I thought that it
>> shouldn't be a problem to have that network traffic on a network that
>> was all Gbe devices except for the HDHR.
>>
>> But I tried a test by putting in a Gbe switch with just the HDHR Quatro,
>> the RPi4 and an uplink connection to the main switch.  I recorded 4 HDTV
>> programs at the same time all during prime time last night and no
>> corruptions.
>>
>> In the original configuration the RPi4 and my Shield TV were on a
>> network segment with a Gbe switch linked to the main home network switch
>> and the HDHR was on that same main home switch.  So 2 HDTV streams from
>> Youtube.TV were going through the main switch that the HDHR was on and
>> one of those HDTV stream went to the Shield TV on the same network
>> segment as the RPi4 recording all the HDHR traffic.
>>
>> I still think the math works out but maybe the 100Mb/s HDHR port
>> degrades the switches so all traffic is affected???
>>
>> Jim A
> No, having a 100 Mbit/s device on one port of a switch will not
> degrade any other port.  All that will happen is that the traffic on
> the 100 Mbit/s connection will be received and transmitted at that
> rate.  The packets will be buffered in the switch and it will transmit
> them at 1 gigabit/s to the other ports.
>
> What other traffic is happening on your network?  If you are copying
> things between the RPi4 and other devices on the network at the same
> time as the HDHR traffic, they all compete for use of the one gigabit
> port on the RPi4.  Copying a file from a fast hard drive to a fast
> hard drive is now capable of using up all of the available 1 gigabit/s
> bandwidth of that port.  So is other similar traffic.  So unless your
> switch is capable of according the HDHR traffic higher priority on
> that port, you may be losing some of the UDP packets for the recording
> traffic from the HDHR.  If a TCP connection loses a packet, it will
> just be resent, and that process will probably cause the TCP
> connection to do a bit of contention processing where it will back off
> its speed.  But if a UDP packet for a recording goes missing, the HDHR
> has no protocol to resend it and it is lost.  And the recording gets
> damaged.
>
> The HDHR traffic is marked with a DSCP flag saying that the packets
> are higher priority.  However, that only helps if everything that
> transmits those packets checks and obeys the DSCP field in the IP
> header.  If your switch is a normal home user type, it will not be
> doing any DSCP priority checking, so it will receive the HDHR packets
> and send them on in the same way it does with all other packets, and
> they will have to contend for the bandwidth on the transmitter of the
> switch port that connects to the RPi4.  If, however, you have a
> commercial grade switch, they almost all support doing DSCP priority,
> and you should enable that option.  With DSCP priority enabled, the
> higher priority HDHR packets will be sent, and if there is then
> insufficient bandwidth for the lower priority packets that are
> flooding the connection, some of them will be dropped.  But as long as
> the HDHR traffic remains less than the 1 gigabit/s capability of the
> port, those packets will never be dropped.

Well my switches are the home category so no prioritizing of DSCP traffic.

I thought Mythtv v30 used the TCP/IP method of talking to the HDHR so 
the ports could be properly shared between devices on the whole 
network?  As far as I know there was no other traffic in the house 
talking to any other HDHR certainly not the Quatro under test as all 
it's ports were busy with my RPi4.

Your explanation of how it's supposed to work is my understanding as well.

If you look at YouTube.TV's requirements according to them if there is 
other traffic on the network you need 13+ Mbps for a HD show.  Most 
evenings we have a Roku and Shield TV both streaming Youtube.TV content. 
My original configuration would have had the RPi4 receiving ~50Mbps from 
the HDHR and the Shield receiving 13 Mbps from the internet in the same 
network segment through the Gbe switch.  So the math still seems like I 
should not have a problem.

However, putting the HDHR and the RPi4 on the same segment solved the 
problem, I think. More testing to be done.

I've never research home network switches before, just went to Amazon 
and ordered a name brand that's cheap and 1000b/s. Could I have a switch 
that doesn't buffer the 100b/s traffic like your described?

Jim A