[mythtv-users] Corrupt recording using HDHR Quatro

[Stephen Worthington]

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.