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

James Abernathy jfabernathy at gmail.com
Tue Jan 3 12:27:18 UTC 2023

On Mon, Jan 2, 2023 at 11:50 PM Stephen Worthington <
stephen_agent at jsw.gen.nz> wrote:

> 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
> >> (,,  Most home routers use a
> >> block of the range for their addresses, so you would
> >> normally use a different block in that range.  Say your router is
> >> using, then you could use for your HDHR
> >> subnet.  So you might set the Ethernet port to be a static address of
> >>, and then set up DHCP addressing for anything that
> >> connects to that Ethernet port to use addresses
> >>  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,
> >> 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;
> }
> subnet netmask {
>         option routers lith.jsw.gen.nz;
>         pool {
>                 range;
>         }
> }
> What that config does is to set up a DHCP server for an Ethernet card
> configured to use a static IP address from - I think
> I will have used 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
> and 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.


As always, I really appreciate when you detail out a lot of the technical
information in your answers. It really helps me understand a
problem/solution. Network traffic conflict may have been the problem when
the HDHR tuners were on the network.  A typical night involves both my wife
and me streaming videos from services like Disney+, or Hulu+Live, while
Mythtv is recording 2 or 3 programs. When I was testing the networked
tuners I'd record the same shows as the Production Mythtv-backend which
uses a PCIe Hauppauge WinTV HD Quad card. All tuners are connected to the
same antenna via a splitter. So when I saw a lot of Yellow on the program
listing of the HDHR mythtv and none on the WinTV mythtv, I knew I had some
HDHR issue.

I may play some with the DHCP server idea more for education than need.

I've been comparing what worked out of the box on my Raspberry PI4 (RPI4)
and what didn't on my Intel NUC.

One key is on the RPI4, it only has one ethernet port and one WiFi port. So
I set up Wifi to talk to my router and I set the Wired port to ipv4 manual,
static IP, Netmask I didn't mess with the IPV6 tab
so it was left at automatic.  In this case the "hdhomerun_config discover"
only returned the device ID with an IPv4 address.

On the NUC since it had 2 NICs and one WiFi, I only configured the 2 NICs.
At first just as I did on the RPI4. I use NM gui.  But in this setup
hdhomerun_config discover returns 2 devices, the first was the correct HDHR
ID with IPv6 address and the second device was the same HDHR ID but with
the IPv4 address.

Whatever happened in that case made the discover command return a good exit
code and mythtv-backend.service was started  too early. Once I did:
   sudo nmcli con modify 'Direct HDHR connection' ipv6.method "disabled"
   sudo nmcli connection up 'Direct HDHR connection'
   Reboot may have been needed as well.
I could run hdhomerun_config discover and only get the one device ID with
the IPv4 address.

This problem occurred with both hdhomerun_check.py and HDHR_Delay_tool.py
which both loop on hdhomerun_config discover.

Jim A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20230103/1f0c55aa/attachment.htm>

More information about the mythtv-users mailing list