[mythtv-users] Corrupt recording using HDHR Quatro

[Stephen Worthington]

On Fri, 20 Dec 2019 12:23:41 -0500, you wrote:

>
>
>
>> As far as I know, HDHRs do not have a TCP protocol option, ...
>
>Where I got my TCP information related to HDHR was back when you needed 
>to setup an External recorder to share the tuners using 
>https://www.mythtv.org/wiki/Mythhdhrrecorder
>
>The setup was written up by Gary Buhrmaster back when HDHR Premium 
>service was available I did all that minus the Premium part because I 
>wanted to share my tuners with other devices like a smart TV running the 
>HDHR app. This way you would not kill a recording by opening a TV or 
>phone app to use a tuner.
>
>Also I can watch live TV from my HDHR by opening in VLC media player a 
>URL like http://192.168.0.27:5004/auto/v5.1 I was under the impression 
>that the protocol was TCP.

Interesting.  I did not know that you could do HTTP streaming from an
HDHR.  Using that for recording would probably get around any problems
with random packet drops, but it would likely fail if there was an
extended period with high packet loss.

>Anyway prior to that Mythtv and the HDHR apps on Smart TV would fight.  
>Someone told me that V30 had all that fixed so I assumed they were using 
>whatever was implemented originally in the mythhdhrrecorder external 
>recorder.

I have not looked at the mythbackend code for IPTV recently, but when
I last did, it was set up to do RTSP/RTP protocol, which is what I was
assuming it used with the HDHRs.  It is what I use for my SAT>IP
tuners.  I do not know if it is (now or then) capable of doing
recordings from straight HTTP streams.

>SO back to my experiment. Are you saying adding the new switch with just 
>the RPi4 and the HDHR and an upstream link to the main switch doesn't 
>lessen the traffic that would interfere with the recording?

No, I am saying that while it does lessen the problems, it does not
completely cure them.

>Does this mean that it really may just be the original switch where the 
>RPi4 and the Shield TV were connected, while the HDHR was back on the 
>main house switch, being the source of the problem?
>
>I can always go back to my original setup and replace the old switch in 
>the Shield and RPi4 loop with the new switch.
>
>I thought switches came along to replace hubs because hubs shared all 
>the traffic everywhere on the network.  I thought a switch would isolate 
>traffic in a segment of the network if it could.

Correct, a switch sends the traffic between the ports that need that
traffic only, using direct port-to-port connections.  The problem you
are up against is that there seems to be enough traffic directed to
the RPi4 that at times it overloads the RPi4 port on the switch. Which
then has to drop packets.

The HDHR will be sending packets to the RPI4 from its switch port.
Then some other traffic happens to the RPi4.  For example, it may do
an automatic update check to see if there are any updated packages to
be installed.  So it connects to the Internet and for a little while
there will be a fair bit of traffic from the switch port your router
is connected to that also has to go through the RPi4's switch port.
There are all sorts of bits of traffic that happen like that, and
usually they are not enough to swamp a 1 gigabit/s port.  But if, for
example, you were to copy a large file to the RPi4 (say a video that
you have downloaded and want to play on the RPi4), that one copy
operation will normally create full speed traffic from its source port
on the switch to the RPi4's switch port.  And then, with that traffic
combined with the HDHR's traffic, there will be more than 1 gigabit/s
trying to be send on the RPi4's switch port - it will be overloaded,
and packets will be dropped.

>Meaning that if computers A and B were connected to the same switch and 
>computers C and D were connected to a different switch and the 2 
>switches were connected together that traffic between A and B would not 
>be seen by C and D.  So A and B could transfer at 1Gbs and not interfere 
>with C and D transferring at 1Gbs.  Is that right???

Yes, but it would work the same way on the ports of a single switch.
In an Ethernet switch, there is no contention when the traffic is
between different ports.  Only when it goes to the same port.

The problem is not traffic between other devices on your network, it
is traffic specifically being sent to the RPi4.  When the total
traffic from other switch ports to the RPi4 switch port exceeds 1
gigabit/s, at the RPi4 switch port there will be contention and packet
drops as the RPi4 port can only send 1 gigabit/s.  When the RPi4's
switch port receives more than 1 gigabit/s of traffic, the only thing
it can do is drop some of that traffic.

By using separate switches, as you have tried, when two or more
devices other than the HDHRs are sending to the RPi4, the traffic from
all those other devices is sent through just one port on the switch
the RPi4 is attached to.  So on the other switch where that traffic
meets on the switch port to be sent to the RPi4's switch, there is
contention and packet drops and only 1 gigabit/s gets sent to the
RPi4's switch.  That limits the problem - you only get contention at
the RPi4's port on its switch between up to 1 gigabit/s from the other
switch and the HDHR's traffic.  So the amount of traffic that needs to
be dropped in this case is the same amount as the HDHRs are sending.
So if the HDHRs are sending say 50 Mbit/s in total, 50 Mbits/s will
need to be dropped from the total traffic at the RPi4's switch port.
So that is 50 Mbit/s out of a total of 1 gigabit/s, or 5%.  You would
expect that 5% to be spread equally across all the source ports, so
numerically most of the dropped packets would be from the 1 gigabit/s
from the other switch.  But the HDHR traffic would still be losing 5%
also.

When all the devices are on the same switch, the RPi4's switch port
can theoretically be receiving up to 1 gigabit/s from all the other
ports on the switch.  So for a 5 port switch, it could be receiving up
to 3 gigabits/s on top of the HDHR traffic.  So it will need to drop
enough of that traffic to get the total down to 1 gigabit/s - so over
2 gigabits/s will be dropped.  Since all the packets are treated
equally, the same percentage will likely be dropped from each of the
ports it is receiving from.  So that percentage of the HDHR traffic
will be dropped.  Using the same example as above, if the HDHRs were
sending 50 Mbits/s and the other three ports on the 5 port switch were
sending 1 gigabit/s each (the worst case), then the total traffic to
the RPi4's port would be 3 gigabits/s + 50 Mbit/s = 3.05 gigabits/s.
Of that, 2.05 gigabit/s needs to be dropped, which is about 67%.  So
about 67% of each stream will be dropped.  So the HDHR traffic will be
losing 67% of its packets!

So with the setup of two separate switches and 50 Mbit/s of HDHR
traffic, you reduce the problem from potential 67% packet loss to only
potential 5% packet loss.  That is a lot better, but even one dropped
HDHR packet is a problem.