<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 3, 2023 at 11:55 AM Mike Perkins <<a href="mailto:mikep@randomtraveller.org.uk">mikep@randomtraveller.org.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 03/01/2023 12:27, James Abernathy wrote:<br>
> <br>
> Stephen,<br>
> <br>
> As always, I really appreciate when you detail out a lot of the technical<br>
> information in your answers. It really helps me understand a<br>
> problem/solution. Network traffic conflict may have been the problem when<br>
> the HDHR tuners were on the network.  A typical night involves both my wife<br>
> and me streaming videos from services like Disney+, or Hulu+Live, while<br>
> Mythtv is recording 2 or 3 programs. When I was testing the networked<br>
> tuners I'd record the same shows as the Production Mythtv-backend which<br>
> uses a PCIe Hauppauge WinTV HD Quad card. All tuners are connected to the<br>
> same antenna via a splitter. So when I saw a lot of Yellow on the program<br>
> listing of the HDHR mythtv and none on the WinTV mythtv, I knew I had some<br>
> HDHR issue.<br>
> <br>
> I may play some with the DHCP server idea more for education than need.<br>
> <br>
> I've been comparing what worked out of the box on my Raspberry PI4 (RPI4)<br>
> and what didn't on my Intel NUC.<br>
> <br>
> One key is on the RPI4, it only has one ethernet port and one WiFi port. So<br>
> I set up Wifi to talk to my router and I set the Wired port to ipv4 manual,<br>
> static IP 169.254.0.1, Netmask 255.255.0.0. I didn't mess with the IPV6 tab<br>
> so it was left at automatic.  In this case the "hdhomerun_config discover"<br>
> only returned the device ID with an IPv4 address.<br>
> <br>
> On the NUC since it had 2 NICs and one WiFi, I only configured the 2 NICs.<br>
> At first just as I did on the RPI4. I use NM gui.  But in this setup<br>
> hdhomerun_config discover returns 2 devices, the first was the correct HDHR<br>
> ID with IPv6 address and the second device was the same HDHR ID but with<br>
> the IPv4 address.<br>
> <br>
> Whatever happened in that case made the discover command return a good exit<br>
> code and mythtv-backend.service was started  too early. Once I did:<br>
>     sudo nmcli con modify 'Direct HDHR connection' ipv6.method "disabled"<br>
>     sudo nmcli connection up 'Direct HDHR connection'<br>
>     Reboot may have been needed as well.<br>
> I could run hdhomerun_config discover and only get the one device ID with<br>
> the IPv4 address.<br>
> <br>
> This problem occurred with both hdhomerun_check.py and HDHR_Delay_tool.py<br>
> which both loop on hdhomerun_config discover.<br>
> <br>
I should point out that if you are using your backend host purely as a mythtv server then you really <br>
don't need NetworkManager at all. NetworkManager is really designed for laptops and like devices <br>
where connections can come and go - while you're on the go. It makes no sense for a server and just <br>
adds complications.<br>
<br>
You really should not need to use the autodiscovery mechanism (169.254.x.x) either. That is designed <br>
for people who plug odd things into and out of their network all the time. Where you have <br>
essentially a static setup HDHR(s) -> mythtv server -> mythtv front-end(s) then it is simpler just <br>
to assign everything a static address in the first place.<br>
<br>
Get rid of NetworkManager and edit /etc/network/interfaces. Give every host an IP address in the <br>
range 192.168.x.y, subnet 255.255.255.0 (or 192.168.x.y/24), and there should be no confusion about <br>
what everything is and where it is. The hosts know what they are, no faffing about with DHCP or <br>
autodiscovery, they just start up. Job done.<br>
<br>
In my case, I /do/ use DHCP for my two HDHR dual network tuners[1]. Neither is mislaid whenever I <br>
bring everything up after maintenance. I didn't have to fiddle with systemd either.<br>
<br>
[1] My primary router/firewall is a self-built box with 6 ports and runs pfSense. It handles DHCP <br>
for almost everything[2] on my extensive network, which comprises a number of different subnets, all <br>
firewalled off from each other. I wouldn't touch an ISP-provided router with a bargepole. (In my <br>
view, pfSense has one of the easiest to use GUIs for configuring rules, DHCP, etc.)<br>
<br>
My mythtv network is one of those subnets and all the hosts plug into an 8-port Gigabit TP-Link <br>
switch. I have often recorded five programs at once and have never suffered any network congestion. <br>
Why two dual HDHRs instead of a quad? I have the option of another aerial pointing in a different <br>
direction to get different local programs. If I do that I'd need to set up a separate mythtv source <br>
and assign one of the boxes to it.<br>
<br>
[2] /One/ of the smart switches sends DHCP requests for its own address down /all/ of the VLANs <br>
configured on it. For that one box I have had to give it a hard-coded address to reduce the chaos.<br>
<br>
-- <br>
<br>
Mike Perkins<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.  </div><div><br></div><div>Jim A</div><div><br></div></div></div>