[mythtv-users] Delaying until HDHR tuners are up before starting mythtv-backend

[Stephen Worthington]

On Mon, 2 Jan 2023 22:30:54 -0500, you wrote:

>On Mon, Jan 2, 2023 at 9:48 PM Stephen Worthington <stephen_agent at jsw.gen.nz>
>wrote:
>
>> What I would do with this sort of setup would be to not use link-local
>> addressing as it is always a dodgy business with IPv4.  Especially
>> when you want to use multiple network ports.  The right way to do this
>> is to assign real IP addresses using one of the private address ranges
>> (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).  Most home routers use a
>> block of the 192.168.0.0/16 range for their addresses, so you would
>> normally use a different block in that range.  Say your router is
>> using 192.168.1.0/24, then you could use 192.168.99.0/24 for your HDHR
>> subnet.  So you might set the Ethernet port to be a static address of
>> 192.168.99.254, and then set up DHCP addressing for anything that
>> connects to that Ethernet port to use addresses
>> 192.168.99.100-192.168.99.200.  And then find out the MAC addresses of
>> your HDHR devices and manually assign them a DHCP address that is
>> outside the automatic DHCP address range, so use 192.168.99.1,
>> 192.168.99.2 and so on.
>>
>> With all of that working, then you can just go back to using a ping of
>> the HDHR IP address to delay mythbackend startup.  And it should be
>> completely reliable.
>>
>
>Stephen,  In this case one ethernet port is connected to a router and has a
>Reserved IP in that router so it's like a static ip.  The HDHR is connected
>directly to the other ethernet port. The reason for this is the HDHR tuners
>in my house do not play well with others and must be isolated somehow. I've
>tried using name brand consumer switches and forming a logic tree with the
>top switch connecting to the AP/router. I've heard the AP/routers don't
>handle switching traffic between their lan ports well so I have the GbE
>switches do that.  But with all that work I still get errors with my HDHR
>tuners on recordings that don't get errors on a PCIe card tuner.
>
>So I went down the path of directly connecting them and that works great.
>I've never seen an error in a recording yet using this method.  I just need
>the boot up timing issues to be resolved. Once I could get
>"hdhomerun_config discover" on the local-link port connection to only
>return the IPv4 address of the device, then I was set using
>hdhomerun_check.py.  If the discover command returned 2 devices one IPv4
>and one IPv6 for the same tuner, then it caused the mythbackend to fail.
>
>I guess it would be possible for the PC with the 2 NICs to run bridge and
>dhcp server for that 2nd port but I don't know how to do that if it's even
>possible.

You do not want to bridge the Ethernet ports.  There is no need for
that and it endlessly complicates things.  Bridging is best done in a
switch anyway - PCs with multiple network ports are routers, not
switches.  All you need is routing (layer 3) not bridging (layer 2).

My guess as the to cause of your original problem with recording from
HDHRs connected to your main subnet is simply too much traffic.  If
you are using an Ethernet port on your MythTV box for both recording
traffic from HDHRs and general traffic such as file copying or MythTV
playback on frontends, there will be periods when the HDHR traffic is
fighting for the available bandwidth with other very high bandwidth
use.  The classic example is if you copy a recording file or video
file to another device over that port.  Since hard drives and SSDs now
have faster transfer rates than a 1 Gbit/s Ethernet port, just copying
a large file uses all the available bandwidth on that port.  So other
traffic has to fight for bandwidth.  If everything is working right,
the different streams of traffic on that port will eventually get
sorted out and all share the bandwidth, but the TCP/IP mechanism that
does that relies on lost packets happening to tell it that there is a
bandwidth problem.  And the sorting out takes a while - it can take
many seconds.  So the effect of that on an HDHR recording stream is
that if UDP is being used, the dropped packets will simply be gone as
there is no recovery method available to get them retransmitted.  More
recent HDHRs offer the option of TCP connections instead of UDP, and
TCP connections will (eventually) re-transmit dropped packets.  I do
not know if MythTV uses TCP yet, but even if it does, the long time
taken to sort out bandwidth conflicts can be so long that TCP's
automatic retransmissions of lost packets will be overwhelmed and the
TCP connection will be dropped.  The best way to handle bandwidth
conflicts like this is to use the DSCP priority bits on IP packets, to
mark the HDHR traffic as high priority and hence not to be dropped -
other lower priority traffic will be dropped instead.  I believe that
HDHRs do in fact tag their packets with a high priority DSCP tag, but
most normal Linux setups are not configured to actually use the DSCP
tags to prioritise traffic so their Ethernet ports just ignore the
tags.  And if the HDHR traffic goes via a router, that would also need
to be set up to use DSCP and consumer grade routers are often not able
to be set up for DSCP either.

This bandwidth problem is the reason I prefer not to use network
tuners, even though my router is configured to do DSCP properly.  I
would always recommend anyone using HDHRs to have them on a separate
Ethernet port, as you are trying to do.

To get a second Ethernet port to set up with a static IP address is
normally a standard part of the GUI now in Linux where NetworkManager
is used.  Exactly how varies depending on the version of Linux and the
GUI being used.  It is easy in Ubuntu using the standard Gnome
Settings > Network options.  Getting a DHCPv4 server set up on an
Ethernet port is rather more difficult, and I have not in fact done
that using NetworkManager.  On PCs where I have done that, it was well
in the past when NetworkManager was unable to be configured to do it,
so I just installed the isc-dhcp-server package and configured its
text config files.  I am unsure if NetworkManager is actually capable
of doing DHCP server setup even now, even though the underlying
dnsmasq software it normally uses is capable.

Here is an example of a setup I have used in the past for my
/etc/dhcp/dhcpd.conf file with the ISC DHCP server:

option domain-name "jsw.gen.nz";
option domain-name-servers ns1g.jsw.gen.nz, ns2.jsw.gen.nz;

default-lease-time 600;
max-lease-time 7200;
ddns-update-style none;
authoritative;

host gt70 {
  hardware ethernet 8c:89:a5:01:24:b5;
  fixed-address 192.168.100.14;
}

subnet 192.168.100.0 netmask 255.255.255.0 {
        option routers lith.jsw.gen.nz;
        pool {
                range 192.168.100.100 192.168.100.200;
        }
}

What that config does is to set up a DHCP server for an Ethernet card
configured to use a static IP address from 192.168.100.0/24 - I think
I will have used 192.168.100.254 as .254 is what I use for my default
for things that are acting as routers.  dhcpd will find the Ethernet
card to use by its IP address.  The "host" section supplies a fixed IP
address for my laptop when connected to that Ethernet port.  You would
need a host section for each HDHR to fix their addresses.  The name
used in a host section should be the DNS hostname of the device, if it
has one.  Otherwise, just make up a name.  The "subnet" section tells
dhcpd the settings for supplying DHCP addresses to that subnet.  The
"options" lines specify various data that the DHCP server will supply
to the DHCP clients when it gives them their IP addresses, such as the
domain name and DNS server addresses.  If you do not run your own DNS
servers, you would not use the "domain-name" option and would set the
"domain-name-servers" option to whatever your router is sending in its
DHCP packets - likely your ISP's DNS servers.  Or you could just use
8.8.8.8 and 8.8.4.4 for Google's servers.  You do need to remember to
change these settings if you ever change ISPs.

There are heaps of other options available, but you should not need
them for a simple setup for running HDHRs.