<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 2, 2023 at 11:50 PM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz">stephen_agent@jsw.gen.nz</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 Mon, 2 Jan 2023 22:30:54 -0500, you wrote:<br>
<br>
>On Mon, Jan 2, 2023 at 9:48 PM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz" target="_blank">stephen_agent@jsw.gen.nz</a>><br>
>wrote:<br>
><br>
>> What I would do with this sort of setup would be to not use link-local<br>
>> addressing as it is always a dodgy business with IPv4. Especially<br>
>> when you want to use multiple network ports. The right way to do this<br>
>> is to assign real IP addresses using one of the private address ranges<br>
>> (<a href="http://10.0.0.0/8" rel="noreferrer" target="_blank">10.0.0.0/8</a>, <a href="http://172.16.0.0/12" rel="noreferrer" target="_blank">172.16.0.0/12</a>, <a href="http://192.168.0.0/16" rel="noreferrer" target="_blank">192.168.0.0/16</a>). Most home routers use a<br>
>> block of the <a href="http://192.168.0.0/16" rel="noreferrer" target="_blank">192.168.0.0/16</a> range for their addresses, so you would<br>
>> normally use a different block in that range. Say your router is<br>
>> using <a href="http://192.168.1.0/24" rel="noreferrer" target="_blank">192.168.1.0/24</a>, then you could use <a href="http://192.168.99.0/24" rel="noreferrer" target="_blank">192.168.99.0/24</a> for your HDHR<br>
>> subnet. So you might set the Ethernet port to be a static address of<br>
>> 192.168.99.254, and then set up DHCP addressing for anything that<br>
>> connects to that Ethernet port to use addresses<br>
>> 192.168.99.100-192.168.99.200. And then find out the MAC addresses of<br>
>> your HDHR devices and manually assign them a DHCP address that is<br>
>> outside the automatic DHCP address range, so use 192.168.99.1,<br>
>> 192.168.99.2 and so on.<br>
>><br>
>> With all of that working, then you can just go back to using a ping of<br>
>> the HDHR IP address to delay mythbackend startup. And it should be<br>
>> completely reliable.<br>
>><br>
><br>
>Stephen, In this case one ethernet port is connected to a router and has a<br>
>Reserved IP in that router so it's like a static ip. The HDHR is connected<br>
>directly to the other ethernet port. The reason for this is the HDHR tuners<br>
>in my house do not play well with others and must be isolated somehow. I've<br>
>tried using name brand consumer switches and forming a logic tree with the<br>
>top switch connecting to the AP/router. I've heard the AP/routers don't<br>
>handle switching traffic between their lan ports well so I have the GbE<br>
>switches do that. But with all that work I still get errors with my HDHR<br>
>tuners on recordings that don't get errors on a PCIe card tuner.<br>
><br>
>So I went down the path of directly connecting them and that works great.<br>
>I've never seen an error in a recording yet using this method. I just need<br>
>the boot up timing issues to be resolved. Once I could get<br>
>"hdhomerun_config discover" on the local-link port connection to only<br>
>return the IPv4 address of the device, then I was set using<br>
>hdhomerun_check.py. If the discover command returned 2 devices one IPv4<br>
>and one IPv6 for the same tuner, then it caused the mythbackend to fail.<br>
><br>
>I guess it would be possible for the PC with the 2 NICs to run bridge and<br>
>dhcp server for that 2nd port but I don't know how to do that if it's even<br>
>possible.<br>
<br>
You do not want to bridge the Ethernet ports. There is no need for<br>
that and it endlessly complicates things. Bridging is best done in a<br>
switch anyway - PCs with multiple network ports are routers, not<br>
switches. All you need is routing (layer 3) not bridging (layer 2).<br>
<br>
My guess as the to cause of your original problem with recording from<br>
HDHRs connected to your main subnet is simply too much traffic. If<br>
you are using an Ethernet port on your MythTV box for both recording<br>
traffic from HDHRs and general traffic such as file copying or MythTV<br>
playback on frontends, there will be periods when the HDHR traffic is<br>
fighting for the available bandwidth with other very high bandwidth<br>
use. The classic example is if you copy a recording file or video<br>
file to another device over that port. Since hard drives and SSDs now<br>
have faster transfer rates than a 1 Gbit/s Ethernet port, just copying<br>
a large file uses all the available bandwidth on that port. So other<br>
traffic has to fight for bandwidth. If everything is working right,<br>
the different streams of traffic on that port will eventually get<br>
sorted out and all share the bandwidth, but the TCP/IP mechanism that<br>
does that relies on lost packets happening to tell it that there is a<br>
bandwidth problem. And the sorting out takes a while - it can take<br>
many seconds. So the effect of that on an HDHR recording stream is<br>
that if UDP is being used, the dropped packets will simply be gone as<br>
there is no recovery method available to get them retransmitted. More<br>
recent HDHRs offer the option of TCP connections instead of UDP, and<br>
TCP connections will (eventually) re-transmit dropped packets. I do<br>
not know if MythTV uses TCP yet, but even if it does, the long time<br>
taken to sort out bandwidth conflicts can be so long that TCP's<br>
automatic retransmissions of lost packets will be overwhelmed and the<br>
TCP connection will be dropped. The best way to handle bandwidth<br>
conflicts like this is to use the DSCP priority bits on IP packets, to<br>
mark the HDHR traffic as high priority and hence not to be dropped -<br>
other lower priority traffic will be dropped instead. I believe that<br>
HDHRs do in fact tag their packets with a high priority DSCP tag, but<br>
most normal Linux setups are not configured to actually use the DSCP<br>
tags to prioritise traffic so their Ethernet ports just ignore the<br>
tags. And if the HDHR traffic goes via a router, that would also need<br>
to be set up to use DSCP and consumer grade routers are often not able<br>
to be set up for DSCP either.<br>
<br>
This bandwidth problem is the reason I prefer not to use network<br>
tuners, even though my router is configured to do DSCP properly. I<br>
would always recommend anyone using HDHRs to have them on a separate<br>
Ethernet port, as you are trying to do.<br>
<br>
To get a second Ethernet port to set up with a static IP address is<br>
normally a standard part of the GUI now in Linux where NetworkManager<br>
is used. Exactly how varies depending on the version of Linux and the<br>
GUI being used. It is easy in Ubuntu using the standard Gnome<br>
Settings > Network options. Getting a DHCPv4 server set up on an<br>
Ethernet port is rather more difficult, and I have not in fact done<br>
that using NetworkManager. On PCs where I have done that, it was well<br>
in the past when NetworkManager was unable to be configured to do it,<br>
so I just installed the isc-dhcp-server package and configured its<br>
text config files. I am unsure if NetworkManager is actually capable<br>
of doing DHCP server setup even now, even though the underlying<br>
dnsmasq software it normally uses is capable.<br>
<br>
Here is an example of a setup I have used in the past for my<br>
/etc/dhcp/dhcpd.conf file with the ISC DHCP server:<br>
<br>
option domain-name "<a href="http://jsw.gen.nz" rel="noreferrer" target="_blank">jsw.gen.nz</a>";<br>
option domain-name-servers <a href="http://ns1g.jsw.gen.nz" rel="noreferrer" target="_blank">ns1g.jsw.gen.nz</a>, <a href="http://ns2.jsw.gen.nz" rel="noreferrer" target="_blank">ns2.jsw.gen.nz</a>;<br>
<br>
default-lease-time 600;<br>
max-lease-time 7200;<br>
ddns-update-style none;<br>
authoritative;<br>
<br>
host gt70 {<br>
hardware ethernet 8c:89:a5:01:24:b5;<br>
fixed-address 192.168.100.14;<br>
}<br>
<br>
subnet 192.168.100.0 netmask 255.255.255.0 {<br>
option routers <a href="http://lith.jsw.gen.nz" rel="noreferrer" target="_blank">lith.jsw.gen.nz</a>;<br>
pool {<br>
range 192.168.100.100 192.168.100.200;<br>
}<br>
}<br>
<br>
What that config does is to set up a DHCP server for an Ethernet card<br>
configured to use a static IP address from <a href="http://192.168.100.0/24" rel="noreferrer" target="_blank">192.168.100.0/24</a> - I think<br>
I will have used 192.168.100.254 as .254 is what I use for my default<br>
for things that are acting as routers. dhcpd will find the Ethernet<br>
card to use by its IP address. The "host" section supplies a fixed IP<br>
address for my laptop when connected to that Ethernet port. You would<br>
need a host section for each HDHR to fix their addresses. The name<br>
used in a host section should be the DNS hostname of the device, if it<br>
has one. Otherwise, just make up a name. The "subnet" section tells<br>
dhcpd the settings for supplying DHCP addresses to that subnet. The<br>
"options" lines specify various data that the DHCP server will supply<br>
to the DHCP clients when it gives them their IP addresses, such as the<br>
domain name and DNS server addresses. If you do not run your own DNS<br>
servers, you would not use the "domain-name" option and would set the<br>
"domain-name-servers" option to whatever your router is sending in its<br>
DHCP packets - likely your ISP's DNS servers. Or you could just use<br>
8.8.8.8 and 8.8.4.4 for Google's servers. You do need to remember to<br>
change these settings if you ever change ISPs.<br>
<br>
There are heaps of other options available, but you should not need<br>
them for a simple setup for running HDHRs.<br></blockquote><div><br></div><div>Stephen,</div><div><br></div><div>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.</div><div><br></div><div>I may play some with the DHCP server idea more for education than need.</div><div><br></div><div>I've been comparing what worked out of the box on my Raspberry PI4 (RPI4) and what didn't on my Intel NUC.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><span style="font-family:monospace"><span style="color:rgb(0,0,0)"> sudo nmcli con modify 'Direct HDHR connection' ipv6.method "disabled"
</span><br> sudo nmcli connection up 'Direct HDHR connection'<br></span></div><div><span style="font-family:monospace"> Reboot may have been needed as well.</span></div><div>I could run hdhomerun_config discover and only get the one device ID with the IPv4 address.<br></div><div><br></div><div>This problem occurred with both hdhomerun_check.py and HDHR_Delay_tool.py which both loop on hdhomerun_config discover.</div><div><br></div><div>Jim A</div></div></div>