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

Tue Jan 3 17:09:05 UTC 2023

On Tue, Jan 3, 2023 at 11:55 AM Mike Perkins <mikep at randomtraveller.org.uk>
wrote:

> On 03/01/2023 12:27, James Abernathy wrote:
> >
> > Stephen,
> >
> > 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 169.254.0.1, Netmask 255.255.0.0. 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.
> >
> I should point out that if you are using your backend host purely as a
> mythtv server then you really
> don't need NetworkManager at all. NetworkManager is really designed for
> laptops and like devices
> where connections can come and go - while you're on the go. It makes no
> sense for a server and just
> adds complications.
>
> You really should not need to use the autodiscovery mechanism
> (169.254.x.x) either. That is designed
> for people who plug odd things into and out of their network all the time.
> Where you have
> essentially a static setup HDHR(s) -> mythtv server -> mythtv front-end(s)
> then it is simpler just
> to assign everything a static address in the first place.
>
> Get rid of NetworkManager and edit /etc/network/interfaces. Give every
> host an IP address in the
> range 192.168.x.y, subnet 255.255.255.0 (or 192.168.x.y/24), and there
> should be no confusion about
> what everything is and where it is. The hosts know what they are, no
> faffing about with DHCP or
> autodiscovery, they just start up. Job done.
>
> In my case, I /do/ use DHCP for my two HDHR dual network tuners[1].
> Neither is mislaid whenever I
> bring everything up after maintenance. I didn't have to fiddle with
> systemd either.
>
> [1] My primary router/firewall is a self-built box with 6 ports and runs
> pfSense. It handles DHCP
> for almost everything[2] on my extensive network, which comprises a number
> of different subnets, all
> firewalled off from each other. I wouldn't touch an ISP-provided router
> with a bargepole. (In my
> view, pfSense has one of the easiest to use GUIs for configuring rules,
> DHCP, etc.)
>
> My mythtv network is one of those subnets and all the hosts plug into an
> 8-port Gigabit TP-Link
> switch. I have often recorded five programs at once and have never
> suffered any network congestion.
> Why two dual HDHRs instead of a quad? I have the option of another aerial
> pointing in a different
> direction to get different local programs. If I do that I'd need to set up
> a separate mythtv source
> and assign one of the boxes to it.
>
> [2] /One/ of the smart switches sends DHCP requests for its own address
> down /all/ of the VLANs
> configured on it. For that one box I have had to give it a hard-coded
> address to reduce the chaos.
>
> --
>
> Mike Perkins
>

Thanks for all the great information.  This Intel NUC once setup will be
moved to my RV camper where it will be used as a central desktop PC as well
as as a combo MythTV frontend/backend. So I'll keep NetworkManager for now.

In the RV I have a small GL.iNet GL-AR750S-Ext (Slate) Gigabit Travel AC
VPN Router that I could connect up the PC and the HDHR, but past experience
with HDHR says to use direct connection and eliminates all the problems
I've been having. Now that I know to eliminate IPv6 on the port for direct
connection to the HDHR ,my delay for the mythbackend systemd startup
works.

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