Mailing List Archive

> On 3 Jan 2023, at 6:27 am, James Abernathy <jfabernathy@gmail.com> wrote:
>
> When I have my HDHR Quatro tuner connected to my router I'd just use a local-network-pingable service to wait until the tuners were pingable.
> That works, but to reduce a lot of the network errors I was getting with the HDHR tuners I've been directly connecting them. That's been working great with no errors due to the connection. But I've been restarting the backend manually to make sure the tuners were up.
>
> You can't use the pingable method of delaying the backend because the 169.254.x.x IP of the HDHR changes every boot. This doesn't affect mythtv-backend because it uses the tuner ID so I need a new method of waiting on the tuners.

Jim I don't know how you do DNS. I use dnsmasq but every router/modem I've seen also allows you to assign a mac address to an IP so you always get the same IP on the same device
James

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Mon, Jan 2, 2023 at 5:42 PM James <jam@tigger.ws> wrote:

>
>
> > On 3 Jan 2023, at 6:27 am, James Abernathy <jfabernathy@gmail.com>
> wrote:
> >
> > When I have my HDHR Quatro tuner connected to my router I'd just use a
> local-network-pingable service to wait until the tuners were pingable.
> > That works, but to reduce a lot of the network errors I was getting with
> the HDHR tuners I've been directly connecting them. That's been working
> great with no errors due to the connection. But I've been restarting the
> backend manually to make sure the tuners were up.
> >
> > You can't use the pingable method of delaying the backend because the
> 169.254.x.x IP of the HDHR changes every boot. This doesn't affect
> mythtv-backend because it uses the tuner ID so I need a new method of
> waiting on the tuners.
>
> Jim I don't know how you do DNS. I use dnsmasq but every router/modem I've
> seen also allows you to assign a mac address to an IP so you always get the
> same IP on the same device
> James
>
> If I was connected to a router that is what I do. In this case I'm
directly connecting the HDHR tuner to a 2nd port on my NUC PC. In that case
the HDHR will assign itself an IP of 169.254.x.x randomly on the x's. I
just set up my PC port to a static IP of 169.254.0.1 with a subnet mask of
255.255.0.0. That all works, it is just the delaying function that is
killing me. I guess I could do a delay on the mythtv-backend to wait for a
mythtv-backend.timer to start 1 minute after boot. But who wants to
introduce a race condition.

On 1/2/23 16:55, James Abernathy wrote:
>
>
> On Mon, Jan 2, 2023 at 5:42 PM James <jam@tigger.ws <mailto:jam@tigger.ws>> wrote:
>
>
>
> > On 3 Jan 2023, at 6:27 am, James Abernathy <jfabernathy@gmail.com <mailto:jfabernathy@gmail.com>> wrote:
> >
> > When I have my HDHR Quatro tuner connected to my router I'd just use a local-network-pingable service to wait until the tuners were
> pingable.
> > That works, but to reduce a lot of the network errors I was getting with the HDHR tuners I've been directly connecting them. That's been
> working great with no errors due to the connection. But I've been restarting the backend manually to make sure the tuners were up.
> >
> > You can't use the pingable method of delaying the backend because the 169.254.x.x IP of the HDHR changes every boot. This doesn't affect
> mythtv-backend because it uses the tuner ID so I need a new method of waiting on the tuners.
>
> Jim I don't know how you do DNS. I use dnsmasq but every router/modem I've seen also allows you to assign a mac address to an IP so you
> always get the same IP on the same device
> James
>
> If I was connected to a router that is what I do.  In this case I'm directly connecting the HDHR tuner to a 2nd port on my NUC PC. In that case
> the HDHR will assign itself an IP of 169.254.x.x randomly on the x's. I just set up my PC port to a static IP of 169.254.0.1 with a subnet mask
> of 255.255.0.0. That all works, it is just the delaying function that is killing me. I guess I could do a delay on the mythtv-backend to wait
> for a mythtv-backend.timer to start 1 minute after boot. But who wants to introduce a race condition.
IPv4 Link Local on the host shouldn't have an address assigned either.
The two ends will figure their addresses out. Link Local should be an
option if you're setting the NIC up with some tool.

I DON'T think this is the issue, but it's the right thing to do.

Try:

hdhomerun_config 1074C841 get /tuner0/status

the above after a restart and successful MANUAL discover command.

I'd disable backend startup to test ideas that prove tuners are
available (which is what the backend log is complaining about:

... Added 0 devices from 1074C841 ...



Bill

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Mon, Jan 2, 2023 at 6:44 PM Bill Meek <keemllib@gmail.com> wrote:

> On 1/2/23 16:55, James Abernathy wrote:
> >
> >
> > On Mon, Jan 2, 2023 at 5:42 PM James <jam@tigger.ws <mailto:
> jam@tigger.ws>> wrote:
> >
> >
> >
> > > On 3 Jan 2023, at 6:27 am, James Abernathy <jfabernathy@gmail.com
> <mailto:jfabernathy@gmail.com>> wrote:
> > >
> > > When I have my HDHR Quatro tuner connected to my router I'd just
> use a local-network-pingable service to wait until the tuners were
> > pingable.
> > > That works, but to reduce a lot of the network errors I was
> getting with the HDHR tuners I've been directly connecting them. That's been
> > working great with no errors due to the connection. But I've been
> restarting the backend manually to make sure the tuners were up.
> > >
> > > You can't use the pingable method of delaying the backend because
> the 169.254.x.x IP of the HDHR changes every boot. This doesn't affect
> > mythtv-backend because it uses the tuner ID so I need a new method
> of waiting on the tuners.
> >
> > Jim I don't know how you do DNS. I use dnsmasq but every
> router/modem I've seen also allows you to assign a mac address to an IP so
> you
> > always get the same IP on the same device
> > James
> >
> > If I was connected to a router that is what I do. In this case I'm
> directly connecting the HDHR tuner to a 2nd port on my NUC PC. In that case
> > the HDHR will assign itself an IP of 169.254.x.x randomly on the x's. I
> just set up my PC port to a static IP of 169.254.0.1 with a subnet mask
> > of 255.255.0.0. That all works, it is just the delaying function that is
> killing me. I guess I could do a delay on the mythtv-backend to wait
> > for a mythtv-backend.timer to start 1 minute after boot. But who wants
> to introduce a race condition.
> IPv4 Link Local on the host shouldn't have an address assigned either.
> The two ends will figure their addresses out. Link Local should be an
> option if you're setting the NIC up with some tool.
>
> I DON'T think this is the issue, but it's the right thing to do.
>
> Try:
>
> hdhomerun_config 1074C841 get /tuner0/status
>
> the above after a restart and successful MANUAL discover command.
>
> I'd disable backend startup to test ideas that prove tuners are
> available (which is what the backend log is complaining about:
>
> ... Added 0 devices from 1074C841 ...
>
>
>
> Bill
>

Thanks, that will give me some stuff to try. I did play with the
hdhomerun_check.py program. After it had a successful "hdhomefun_config
discover" command I tried different sleep delays until I found what
worked. 10 seconds allowed the backend to connect with 2 tuners and 20
seconds found all 4.

I'll try working on some of your suggestions.

Jim A

On 1/2/23 17:51, James Abernathy wrote:
>
>
> On Mon, Jan 2, 2023 at 6:44 PM Bill Meek <keemllib@gmail.com <mailto:keemllib@gmail.com>> wrote:
>
> On 1/2/23 16:55, James Abernathy wrote:
> >
> >
> > On Mon, Jan 2, 2023 at 5:42 PM James <jam@tigger.ws <mailto:jam@tigger.ws> <mailto:jam@tigger.ws <mailto:jam@tigger.ws>>> wrote:
> >
> >
> >
> >      > On 3 Jan 2023, at 6:27 am, James Abernathy <jfabernathy@gmail.com <mailto:jfabernathy@gmail.com> <mailto:jfabernathy@gmail.com
> <mailto:jfabernathy@gmail.com>>> wrote:
> >      >
> >      > When I have my HDHR Quatro tuner connected to my router I'd just use a local-network-pingable service to wait until the tuners were
> >     pingable.
> >      > That works, but to reduce a lot of the network errors I was getting with the HDHR tuners I've been directly connecting them.
> That's been
> >     working great with no errors due to the connection. But I've been restarting the backend manually to make sure the tuners were up.
> >      >
> >      > You can't use the pingable method of delaying the backend because the 169.254.x.x IP of the HDHR changes every boot. This doesn't
> affect
> >     mythtv-backend because it uses the tuner ID so I need a new method of waiting on the tuners.
> >
> >     Jim I don't know how you do DNS. I use dnsmasq but every router/modem I've seen also allows you to assign a mac address to an IP so you
> >     always get the same IP on the same device
> >     James
> >
> > If I was connected to a router that is what I do.  In this case I'm directly connecting the HDHR tuner to a 2nd port on my NUC PC. In
> that case
> > the HDHR will assign itself an IP of 169.254.x.x randomly on the x's. I just set up my PC port to a static IP of 169.254.0.1 with a
> subnet mask
> > of 255.255.0.0. That all works, it is just the delaying function that is killing me. I guess I could do a delay on the mythtv-backend to
> wait
> > for a mythtv-backend.timer to start 1 minute after boot. But who wants to introduce a race condition.
> IPv4 Link Local on the host shouldn't have an address assigned either.
> The two ends will figure their addresses out. Link Local should be an
> option if you're setting the NIC up with some tool.
>
> I DON'T think this is the issue, but it's the right thing to do.
>
> Try:
>
>    hdhomerun_config 1074C841 get /tuner0/status
>
> the above after a restart and successful MANUAL discover command.
>
> I'd disable backend startup to test ideas that prove tuners are
> available (which is what the backend log is complaining about:
>
>    ... Added 0 devices from 1074C841 ...
>
>
>
> Bill
>
>
> Thanks, that will give me some stuff to try.  I did play with the hdhomerun_check.py program.  After it had a successful "hdhomefun_config
> discover" command I tried different sleep delays until I found what worked.  10 seconds allowed the backend to connect with 2 tuners and 20
> seconds found all 4.
>
> I'll try working on some of your suggestions.

The additional delay is interesting. I'd start with the Link Local fix.
Here's what NIC's settings look like:

[802-3-ethernet]
duplex=full
mac-address=00:AB:CD:EF:00:11

[connection]
id=eth1
uuid=very long hex string here
type=802-3-ethernet
timestamp=1386355229

[ipv6]
method=ignore

[ipv4]
method=link-local
dhcp-send-hostname=false

--
Bill

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Mon, Jan 2, 2023 at 7:05 PM Bill Meek <keemllib@gmail.com> wrote:

> On 1/2/23 17:51, James Abernathy wrote:
> >
> >
> > On Mon, Jan 2, 2023 at 6:44 PM Bill Meek <keemllib@gmail.com <mailto:
> keemllib@gmail.com>> wrote:
> >
> > On 1/2/23 16:55, James Abernathy wrote:
> > >
> > >
> > > On Mon, Jan 2, 2023 at 5:42 PM James <jam@tigger.ws <mailto:
> jam@tigger.ws> <mailto:jam@tigger.ws <mailto:jam@tigger.ws>>> wrote:
> > >
> > >
> > >
> > > > On 3 Jan 2023, at 6:27 am, James Abernathy <
> jfabernathy@gmail.com <mailto:jfabernathy@gmail.com> <mailto:
> jfabernathy@gmail.com
> > <mailto:jfabernathy@gmail.com>>> wrote:
> > > >
> > > > When I have my HDHR Quatro tuner connected to my router
> I'd just use a local-network-pingable service to wait until the tuners were
> > > pingable.
> > > > That works, but to reduce a lot of the network errors I
> was getting with the HDHR tuners I've been directly connecting them.
> > That's been
> > > working great with no errors due to the connection. But I've
> been restarting the backend manually to make sure the tuners were up.
> > > >
> > > > You can't use the pingable method of delaying the backend
> because the 169.254.x.x IP of the HDHR changes every boot. This doesn't
> > affect
> > > mythtv-backend because it uses the tuner ID so I need a new
> method of waiting on the tuners.
> > >
> > > Jim I don't know how you do DNS. I use dnsmasq but every
> router/modem I've seen also allows you to assign a mac address to an IP so
> you
> > > always get the same IP on the same device
> > > James
> > >
> > > If I was connected to a router that is what I do. In this case
> I'm directly connecting the HDHR tuner to a 2nd port on my NUC PC. In
> > that case
> > > the HDHR will assign itself an IP of 169.254.x.x randomly on the
> x's. I just set up my PC port to a static IP of 169.254.0.1 with a
> > subnet mask
> > > of 255.255.0.0. That all works, it is just the delaying function
> that is killing me. I guess I could do a delay on the mythtv-backend to
> > wait
> > > for a mythtv-backend.timer to start 1 minute after boot. But who
> wants to introduce a race condition.
> > IPv4 Link Local on the host shouldn't have an address assigned
> either.
> > The two ends will figure their addresses out. Link Local should be an
> > option if you're setting the NIC up with some tool.
> >
> > I DON'T think this is the issue, but it's the right thing to do.
> >
> > Try:
> >
> > hdhomerun_config 1074C841 get /tuner0/status
> >
> > the above after a restart and successful MANUAL discover command.
> >
> > I'd disable backend startup to test ideas that prove tuners are
> > available (which is what the backend log is complaining about:
> >
> > ... Added 0 devices from 1074C841 ...
> >
> >
> >
> > Bill
> >
> >
> > Thanks, that will give me some stuff to try. I did play with the
> hdhomerun_check.py program. After it had a successful "hdhomefun_config
> > discover" command I tried different sleep delays until I found what
> worked. 10 seconds allowed the backend to connect with 2 tuners and 20
> > seconds found all 4.
> >
> > I'll try working on some of your suggestions.
>
> The additional delay is interesting. I'd start with the Link Local fix.
> Here's what NIC's settings look like:
>
> [802-3-ethernet]
> duplex=full
> mac-address=00:AB:CD:EF:00:11
>
> [connection]
> id=eth1
> uuid=very long hex string here
> type=802-3-ethernet
> timestamp=1386355229
>
> [ipv6]
> method=ignore
>
> [ipv4]
> method=link-local
> dhcp-send-hostname=false
>
> --
> Bill
>

Thanks, the Direct connection is set to local-link and works.

With the mythtv-backend disabled at boot, I logged in and opened a terminal
then did:

[jim@den-pc ~]$ hdhomerun_config 1074c841 get /tuner0/status
unable to connect to device
[jim@den-pc ~]$ hdhomerun_config 1074c841 get /tuner0/status
unable to connect to device
[jim@den-pc ~]$ hdhomerun_config 1074c841 get /tuner0/status
unable to connect to device
[jim@den-pc ~]$ hdhomerun_config 1074c841 get /tuner0/status
ch=none lock=none ss=0 snq=0 seq=0 bps=0 pps=0
[jim@den-pc ~]$ hdhomerun_config discover
hdhomerun device 1074C841 found at fe80::218:ddff:fe07:4c84%2
hdhomerun device 1074C841 found at 169.254.208.100

As you can see even after all that time it still has problems getting
status. Maybe I should use the get status command in the hdhomerun_check.py
command as a test?

Jim A

On 1/2/23 18:18, James Abernathy wrote:
>
>
> On Mon, Jan 2, 2023 at 7:05 PM Bill Meek <keemllib@gmail.com <mailto:keemllib@gmail.com>> wrote:
>
> On 1/2/23 17:51, James Abernathy wrote:
> >
> >
> > On Mon, Jan 2, 2023 at 6:44 PM Bill Meek <keemllib@gmail.com <mailto:keemllib@gmail.com> <mailto:keemllib@gmail.com
> <mailto:keemllib@gmail.com>>> wrote:
> >
> >     On 1/2/23 16:55, James Abernathy wrote:
> >      >
> >      >
> >      > On Mon, Jan 2, 2023 at 5:42 PM James <jam@tigger.ws <mailto:jam@tigger.ws> <mailto:jam@tigger.ws <mailto:jam@tigger.ws>>
> <mailto:jam@tigger.ws <mailto:jam@tigger.ws> <mailto:jam@tigger.ws <mailto:jam@tigger.ws>>>> wrote:
> >      >
> >      >
> >      >
> >      >      > On 3 Jan 2023, at 6:27 am, James Abernathy <jfabernathy@gmail.com <mailto:jfabernathy@gmail.com>
> <mailto:jfabernathy@gmail.com <mailto:jfabernathy@gmail.com>> <mailto:jfabernathy@gmail.com <mailto:jfabernathy@gmail.com>
> >     <mailto:jfabernathy@gmail.com <mailto:jfabernathy@gmail.com>>>> wrote:
> >      >      >
> >      >      > When I have my HDHR Quatro tuner connected to my router I'd just use a local-network-pingable service to wait until the
> tuners were
> >      >     pingable.
> >      >      > That works, but to reduce a lot of the network errors I was getting with the HDHR tuners I've been directly connecting them.
> >     That's been
> >      >     working great with no errors due to the connection. But I've been restarting the backend manually to make sure the tuners were up.
> >      >      >
> >      >      > You can't use the pingable method of delaying the backend because the 169.254.x.x IP of the HDHR changes every boot. This
> doesn't
> >     affect
> >      >     mythtv-backend because it uses the tuner ID so I need a new method of waiting on the tuners.
> >      >
> >      >     Jim I don't know how you do DNS. I use dnsmasq but every router/modem I've seen also allows you to assign a mac address to an
> IP so you
> >      >     always get the same IP on the same device
> >      >     James
> >      >
> >      > If I was connected to a router that is what I do.  In this case I'm directly connecting the HDHR tuner to a 2nd port on my NUC PC. In
> >     that case
> >      > the HDHR will assign itself an IP of 169.254.x.x randomly on the x's. I just set up my PC port to a static IP of 169.254.0.1 with a
> >     subnet mask
> >      > of 255.255.0.0. That all works, it is just the delaying function that is killing me. I guess I could do a delay on the
> mythtv-backend to
> >     wait
> >      > for a mythtv-backend.timer to start 1 minute after boot. But who wants to introduce a race condition.
> >     IPv4 Link Local on the host shouldn't have an address assigned either.
> >     The two ends will figure their addresses out. Link Local should be an
> >     option if you're setting the NIC up with some tool.
> >
> >     I DON'T think this is the issue, but it's the right thing to do.
> >
> >     Try:
> >
> >         hdhomerun_config 1074C841 get /tuner0/status
> >
> >     the above after a restart and successful MANUAL discover command.
> >
> >     I'd disable backend startup to test ideas that prove tuners are
> >     available (which is what the backend log is complaining about:
> >
> >         ... Added 0 devices from 1074C841 ...
> >
> >
> >
> >     Bill
> >
> >
> > Thanks, that will give me some stuff to try.  I did play with the hdhomerun_check.py program.  After it had a successful "hdhomefun_config
> > discover" command I tried different sleep delays until I found what worked.  10 seconds allowed the backend to connect with 2 tuners and 20
> > seconds found all 4.
> >
> > I'll try working on some of your suggestions.
>
> The additional delay is interesting. I'd start with the Link Local fix.
> Here's what NIC's settings look like:
>
> [802-3-ethernet]
> duplex=full
> mac-address=00:AB:CD:EF:00:11
>
> [connection]
> id=eth1
> uuid=very long hex string here
> type=802-3-ethernet
> timestamp=1386355229
>
> [ipv6]
> method=ignore
>
> [ipv4]
> method=link-local
> dhcp-send-hostname=false
>
> --
> Bill
>
>
> Thanks, the Direct connection is set to local-link and works.
>
> With the mythtv-backend disabled at boot, I logged in and opened a terminal then did:
> [jim@den-pc ~]$ hdhomerun_config 1074c841 get /tuner0/status
> unable to connect to device
> [jim@den-pc ~]$ hdhomerun_config 1074c841 get /tuner0/status
> unable to connect to device
> [jim@den-pc ~]$ hdhomerun_config 1074c841 get /tuner0/status
> unable to connect to device
> [jim@den-pc ~]$ hdhomerun_config 1074c841 get /tuner0/status
> ch=none lock=none ss=0 snq=0 seq=0 bps=0 pps=0
> [jim@den-pc ~]$ hdhomerun_config discover
> hdhomerun device 1074C841 found at fe80::218:ddff:fe07:4c84%2
> hdhomerun device 1074C841 found at 169.254.208.100
>
> As you can see even after all that time it still has problems getting status. Maybe I should use the get status command in the
> hdhomerun_check.py command as a test?
>
> Jim A

In the configuration for the NIC, can you set IPv6 to off?
I've never used mine with it. An IPv6 address starting with
fe80:: is also for Link Local.

If you added the get /tuner/status to the script, you'd need to
capture the 1074C841 from its output. Or [ugh!] hard code it.

IPv6 can be turned off for eth0 with sysctl. Yours must be on

sysctl --all --pattern net.ipv6.conf.eth0.disable_ipv6


--
Bill

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Mon, Jan 2, 2023 at 7:30 PM Bill Meek <keemllib@gmail.com> wrote:

> On 1/2/23 18:18, James Abernathy wrote:
> >
> >
> > On Mon, Jan 2, 2023 at 7:05 PM Bill Meek <keemllib@gmail.com <mailto:
> keemllib@gmail.com>> wrote:
> >
> > On 1/2/23 17:51, James Abernathy wrote:
> > >
> > >
> > > On Mon, Jan 2, 2023 at 6:44 PM Bill Meek <keemllib@gmail.com
> <mailto:keemllib@gmail.com> <mailto:keemllib@gmail.com
> > <mailto:keemllib@gmail.com>>> wrote:
> > >
> > > On 1/2/23 16:55, James Abernathy wrote:
> > > >
> > > >
> > > > On Mon, Jan 2, 2023 at 5:42 PM James <jam@tigger.ws
> <mailto:jam@tigger.ws> <mailto:jam@tigger.ws <mailto:jam@tigger.ws>>
> > <mailto:jam@tigger.ws <mailto:jam@tigger.ws> <mailto:jam@tigger.ws
> <mailto:jam@tigger.ws>>>> wrote:
> > > >
> > > >
> > > >
> > > > > On 3 Jan 2023, at 6:27 am, James Abernathy <
> jfabernathy@gmail.com <mailto:jfabernathy@gmail.com>
> > <mailto:jfabernathy@gmail.com <mailto:jfabernathy@gmail.com>>
> <mailto:jfabernathy@gmail.com <mailto:jfabernathy@gmail.com>
> > > <mailto:jfabernathy@gmail.com <mailto:jfabernathy@gmail.com>>>>
> wrote:
> > > > >
> > > > > When I have my HDHR Quatro tuner connected to my
> router I'd just use a local-network-pingable service to wait until the
> > tuners were
> > > > pingable.
> > > > > That works, but to reduce a lot of the network
> errors I was getting with the HDHR tuners I've been directly connecting
> them.
> > > That's been
> > > > working great with no errors due to the connection.
> But I've been restarting the backend manually to make sure the tuners were
> up.
> > > > >
> > > > > You can't use the pingable method of delaying the
> backend because the 169.254.x.x IP of the HDHR changes every boot. This
> > doesn't
> > > affect
> > > > mythtv-backend because it uses the tuner ID so I need
> a new method of waiting on the tuners.
> > > >
> > > > Jim I don't know how you do DNS. I use dnsmasq but
> every router/modem I've seen also allows you to assign a mac address to an
> > IP so you
> > > > always get the same IP on the same device
> > > > James
> > > >
> > > > If I was connected to a router that is what I do. In this
> case I'm directly connecting the HDHR tuner to a 2nd port on my NUC PC. In
> > > that case
> > > > the HDHR will assign itself an IP of 169.254.x.x randomly
> on the x's. I just set up my PC port to a static IP of 169.254.0.1 with a
> > > subnet mask
> > > > of 255.255.0.0. That all works, it is just the delaying
> function that is killing me. I guess I could do a delay on the
> > mythtv-backend to
> > > wait
> > > > for a mythtv-backend.timer to start 1 minute after boot.
> But who wants to introduce a race condition.
> > > IPv4 Link Local on the host shouldn't have an address
> assigned either.
> > > The two ends will figure their addresses out. Link Local
> should be an
> > > option if you're setting the NIC up with some tool.
> > >
> > > I DON'T think this is the issue, but it's the right thing to
> do.
> > >
> > > Try:
> > >
> > > hdhomerun_config 1074C841 get /tuner0/status
> > >
> > > the above after a restart and successful MANUAL discover
> command.
> > >
> > > I'd disable backend startup to test ideas that prove tuners
> are
> > > available (which is what the backend log is complaining about:
> > >
> > > ... Added 0 devices from 1074C841 ...
> > >
> > >
> > >
> > > Bill
> > >
> > >
> > > Thanks, that will give me some stuff to try. I did play with the
> hdhomerun_check.py program. After it had a successful "hdhomefun_config
> > > discover" command I tried different sleep delays until I found
> what worked. 10 seconds allowed the backend to connect with 2 tuners and 20
> > > seconds found all 4.
> > >
> > > I'll try working on some of your suggestions.
> >
> > The additional delay is interesting. I'd start with the Link Local
> fix.
> > Here's what NIC's settings look like:
> >
> > [802-3-ethernet]
> > duplex=full
> > mac-address=00:AB:CD:EF:00:11
> >
> > [connection]
> > id=eth1
> > uuid=very long hex string here
> > type=802-3-ethernet
> > timestamp=1386355229
> >
> > [ipv6]
> > method=ignore
> >
> > [ipv4]
> > method=link-local
> > dhcp-send-hostname=false
> >
> > --
> > Bill
> >
> >
> > Thanks, the Direct connection is set to local-link and works.
> >
> > With the mythtv-backend disabled at boot, I logged in and opened a
> terminal then did:
> > [jim@den-pc ~]$ hdhomerun_config 1074c841 get /tuner0/status
> > unable to connect to device
> > [jim@den-pc ~]$ hdhomerun_config 1074c841 get /tuner0/status
> > unable to connect to device
> > [jim@den-pc ~]$ hdhomerun_config 1074c841 get /tuner0/status
> > unable to connect to device
> > [jim@den-pc ~]$ hdhomerun_config 1074c841 get /tuner0/status
> > ch=none lock=none ss=0 snq=0 seq=0 bps=0 pps=0
> > [jim@den-pc ~]$ hdhomerun_config discover
> > hdhomerun device 1074C841 found at fe80::218:ddff:fe07:4c84%2
> > hdhomerun device 1074C841 found at 169.254.208.100
> >
> > As you can see even after all that time it still has problems getting
> status. Maybe I should use the get status command in the
> > hdhomerun_check.py command as a test?
> >
> > Jim A
>
> In the configuration for the NIC, can you set IPv6 to off?
> I've never used mine with it. An IPv6 address starting with
> fe80:: is also for Link Local.
>
> If you added the get /tuner/status to the script, you'd need to
> capture the 1074C841 from its output. Or [ugh!] hard code it.
>
> IPv6 can be turned off for eth0 with sysctl. Yours must be on
>
> sysctl --all --pattern net.ipv6.conf.eth0.disable_ipv6
>
>
> --
> Bill
>
>
Under /etc/NetworkManager/system-connections I have one file for each
NIC. The one for direct connection to the HDHR is call:
'Direct HDHR connection.nmconnection' and contains:
[connection]
id=Direct HDHR connection
uuid=b33af363-242f-4e2a-921e-3e445bb93369
type=ethernet

[ethernet]
auto-negotiate=true
mac-address=A8:A1:59:6B:0A:44

[ipv4]
may-fail=false
method=link-local

[ipv6]
method=ignore

[proxy]

I tried
# sysctl --all --pattern net.ipv6.conf.eno1.disable_ipv6
it returned: net.ipv6.conf.eno1.disable_ipv6 = 0

The discover still show both:
hdhomerun device 1074C841 found at fe80::218:ddff:fe07:4c84%2
hdhomerun device 1074C841 found at 169.254.208.100

Thanks for all your help. I got something to work with now. Just need to
modify the code for the delay.

Jim A

BTW, using the "hdhomerun_config 1074c841 get /tuner0/status"
instead of the "hdhomerun_config discover" worked.

Looping on that command seemed to exit with the tuner in a state that
mythbackend liked.

Jim A

On Mon, Jan 2, 2023 at 8:20 PM James Abernathy <jfabernathy@gmail.com>
wrote:

> BTW, using the "hdhomerun_config 1074c841 get /tuner0/status"
> instead of the "hdhomerun_config discover" worked.
>
> Looping on that command seemed to exit with the tuner in a state that
> mythbackend liked.
>
> Jim A
>
>
So I think IPV6 was the issue. I'm using EndeavourOS which is Archlinux.
I searched their wiki and found a way to disable ipv6 using nmcli. Once
that took, I ran hdhomerun_config discover and it returned just one device
and it was using an ipv4 address Then I could put the discover command back
in the python program and it worked properly. I guess I didn't have this
issue on the Raspberry Pi due to different hardware?? It is running EOS
ARM. so the OS should be close to what I have on this Intel NUC.

Jim A

> On 3 Jan 2023, at 7:44 am, Bill Meek <keemllib@gmail.com> wrote:
>
> On 1/2/23 16:55, James Abernathy wrote:
>> On Mon, Jan 2, 2023 at 5:42 PM James <jam@tigger.ws <mailto:jam@tigger.ws>> wrote:
>> > On 3 Jan 2023, at 6:27 am, James Abernathy <jfabernathy@gmail.com <mailto:jfabernathy@gmail.com>> wrote:
>> >
>> > When I have my HDHR Quatro tuner connected to my router I'd just use a local-network-pingable service to wait until the tuners were
>> pingable.
>> > That works, but to reduce a lot of the network errors I was getting with the HDHR tuners I've been directly connecting them. That's been
>> working great with no errors due to the connection. But I've been restarting the backend manually to make sure the tuners were up.
>> >
>> > You can't use the pingable method of delaying the backend because the 169.254.x.x IP of the HDHR changes every boot. This doesn't affect
>> mythtv-backend because it uses the tuner ID so I need a new method of waiting on the tuners.
>> Jim I don't know how you do DNS. I use dnsmasq but every router/modem I've seen also allows you to assign a mac address to an IP so you
>> always get the same IP on the same device
>> James
>> If I was connected to a router that is what I do. In this case I'm directly connecting the HDHR tuner to a 2nd port on my NUC PC. In that case the HDHR will assign itself an IP of 169.254.x.x randomly on the x's. I just set up my PC port to a static IP of 169.254.0.1 with a subnet mask of 255.255.0.0. That all works, it is just the delaying function that is killing me. I guess I could do a delay on the mythtv-backend to wait for a mythtv-backend.timer to start 1 minute after boot. But who wants to introduce a race condition.
> IPv4 Link Local on the host shouldn't have an address assigned either.
> The two ends will figure their addresses out. Link Local should be an
> option if you're setting the NIC up with some tool.
>
> I DON'T think this is the issue, but it's the right thing to do.
>
> Try:
>
> hdhomerun_config 1074C841 get /tuner0/status
>
> the above after a restart and successful MANUAL discover command.
>
> I'd disable backend startup to test ideas that prove tuners are
> available (which is what the backend log is complaining about:
>
> ... Added 0 devices from 1074C841 …


I’ve not done it, so this is hearsay, but with ARP you can find the ip of a mac address

James
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

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.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Mon, Jan 2, 2023 at 10:29 PM James Abernathy <jfabernathy@gmail.com> wrote:

> Any Ideas?

For those that are using a single nic(*) (which is generally the
recommended solution as current HDHR's need access to
the Internet for certain functionality), the 3rd party tool
HDHRUtil-Tuner-waitOnline may be useful (it should be
obvious as to how to create the appropriate systemd service
files).


(*) Functionality of the utility for multiple nics (and IPv6) is
specified as a future enhancement.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Mon, Jan 2, 2023 at 9:48 PM Stephen Worthington <stephen_agent@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.

Jim A

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

>On Mon, Jan 2, 2023 at 9:48 PM Stephen Worthington <stephen_agent@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.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Mon, Jan 2, 2023 at 11:50 PM Stephen Worthington <
stephen_agent@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@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.
>

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.

Jim A

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


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Tue, Jan 3, 2023 at 11:55 AM Mike Perkins <mikep@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