Mailing List Archive

MythTV backend starts before HDHR tuners are available
Hi folks,

I recently updated my MythTV system to Ubuntu 22.04, and I've noticed
that when I power on the system there's a very high chance that there
will be zero tuners detected. If I restart the MythTV backend after the
system is running, my HDHR device is detected as 3 network tuners. My
network is provided via a WiFi adapter, as opposed to a wired connection
these days, in case it matter.

On a clean boot, I'll see something like this:
recorders/hdhrstreamhandler.cpp:393 (Connect) HDHRSH[0](131F1E8E): Added
0 devices from 131F1E8E
recorders/hdhrstreamhandler.cpp:401 (Connect) HDHRSH[0](131F1E8E):
Unable to find a free device
recorders/channelbase.cpp:806 (CreateChannel) ChannelBase:
CreateChannel() Error: Failed to open device 131F1E8E
main_helpers.cpp:234 (setupTVs) Problem with capture cards. Card 5
failed init
recorders/hdhrstreamhandler.cpp:393 (Connect) HDHRSH[0](131F1E8E): Added
0 devices from 131F1E8E
recorders/hdhrstreamhandler.cpp:401 (Connect) HDHRSH[0](131F1E8E):
Unable to find a free device
recorders/channelbase.cpp:806 (CreateChannel) ChannelBase:
CreateChannel() Error: Failed to open device 131F1E8E
main_helpers.cpp:234 (setupTVs) Problem with capture cards. Card 7
failed init
recorders/hdhrstreamhandler.cpp:393 (Connect) HDHRSH[0](131F1E8E): Added
0 devices from 131F1E8E
recorders/hdhrstreamhandler.cpp:401 (Connect) HDHRSH[0](131F1E8E):
Unable to find a free device
recorders/channelbase.cpp:806 (CreateChannel) ChannelBase:
CreateChannel() Error: Failed to open device 131F1E8E
main_helpers.cpp:234 (setupTVs) Problem with capture cards. Card 9
failed init
main_helpers.cpp:249 (setupTVs) MythBackend: No valid capture cards are
defined in the database.

Based on some searches, I've heard that there can be a race condition
where the backend starts before the network is entirely up and running.
Given that Linux distros are a moving target with respect to how they
start up, I seem to not be having much luck finding advice that aligns
with a stock-ish Ubuntu 22.04 system. Specifically I found
<https://www.mythtv.org/wiki/Systemd_mythbackend_Configuration#Delay_starting_the_backend_until_network_has_initialized>,
but pingnetwork.service is not a valid service on my system. So as a
compromise I tried customizing my
/etc/systemd/system/multi-user.target.wants/mythtv-backend.service file
to have:
After=mysql.service network.target network.target network-online.target
Wants=network.target network-online.target

But that had no effect on the system.

So my questions at this point are:

1) Is "Added 0 devices from <DeviceName>" a symptom of the MythTV
backend starting up before the network is fully up?

2) If 1) is true, what is an appropriate way to get an Ubuntu 22.04
system to start MythTV only after the network is fully up and running?


Thanks
-WD


_______________________________________________
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
Re: MythTV backend starts before HDHR tuners are available [ In reply to ]
On Thu, Nov 16, 2023 at 5:44?PM Will Dormann <wdormann@gmail.com> wrote:

> 2) If 1) is true, what is an appropriate way to get an Ubuntu 22.04
> system to start MythTV only after the network is fully up and running?

"Fully up and running" is not a well defined term
when if comes to Linux and Network connectivity.

Some discussion:
https://systemd.io/NETWORK_ONLINE/

Sometimes adding a Wants= and After=network-online.target
(along with time-sync.target) to the MythTV backend
service file will help (if you have the correct other
services enabled that network-online.target itself
will wait for, such as systemd-networkd-wait-online.service
if you are using systemd-networkd).

The "cheap" way would be something like a
ExecStartPre=-/usr/bin/sleep 10

If you go through the list archives you will
find others who create various scripts that
either try to connect to the HDHR, or ping
some external device. All can work some of
the time depending on what you mean by
the network being up.

There is also a 3rd party application called
HDHRUtil-Tuner-waitOnline that can be used
to wait for a HDHR to become available and
used either as an ExecStartPre or an instanced
service file with an After (likely one would
create an instanced service file if you wanted
to wait for a number of different HDHRs, but
in reality, if one is available, that would usually
mean all are). Be aware that if the HDHR does
not actually become available that particular
app will exit with an error, so you need to
accommodate that with a '-' if you use
ExecStartPre
_______________________________________________
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
Re: MythTV backend starts before HDHR tuners are available [ In reply to ]
On Thu, Nov 16, 2023 at 1:33?PM Gary Buhrmaster <gary.buhrmaster@gmail.com>
wrote:

> On Thu, Nov 16, 2023 at 5:44?PM Will Dormann <wdormann@gmail.com> wrote:
>
> > 2) If 1) is true, what is an appropriate way to get an Ubuntu 22.04
> > system to start MythTV only after the network is fully up and running?
>
> "Fully up and running" is not a well defined term
> when if comes to Linux and Network connectivity.
>
> Some discussion:
> https://systemd.io/NETWORK_ONLINE/
>
> Sometimes adding a Wants= and After=network-online.target
> (along with time-sync.target) to the MythTV backend
> service file will help (if you have the correct other
> services enabled that network-online.target itself
> will wait for, such as systemd-networkd-wait-online.service
> if you are using systemd-networkd).
>
> The "cheap" way would be something like a
> ExecStartPre=-/usr/bin/sleep 10
>
> If you go through the list archives you will
> find others who create various scripts that
> either try to connect to the HDHR, or ping
> some external device. All can work some of
> the time depending on what you mean by
> the network being up.
>
> There is also a 3rd party application called
> HDHRUtil-Tuner-waitOnline that can be used
> to wait for a HDHR to become available and
> used either as an ExecStartPre or an instanced
> service file with an After (likely one would
> create an instanced service file if you wanted
> to wait for a number of different HDHRs, but
> in reality, if one is available, that would usually
> mean all are). Be aware that if the HDHR does
> not actually become available that particular
> app will exit with an error, so you need to
> accommodate that with a '-' if you use
> ExecStartPre
>


At the end of the post below is how to do it.

https://forum.mythtv.org/viewtopic.php?f=46&t=5531

Jim A
Re: MythTV backend starts before HDHR tuners are available [ In reply to ]
On 11/16/23 1:29 PM, Gary Buhrmaster wrote:

> The "cheap" way would be something like a
> ExecStartPre=-/usr/bin/sleep 10

Thanks! This indeed mitigated the problem for me. At least out of a
handful of cold boots to test it.



-WD

_______________________________________________
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
Re: MythTV backend starts before HDHR tuners are available [ In reply to ]
On 11/16/23 2:15 PM, James Abernathy wrote:
>
> At the end of the post below is how to do it.
>
> https://forum.mythtv.org/viewtopic.php?f=46&t=5531
> <https://forum.mythtv.org/viewtopic.php?f=46&t=5531>
>


Thanks as well! While a time-based delay worked fine for me, this seems
a touch more polished as it's based on the status of the device, as
opposed to wall-clock time.


-WD

_______________________________________________
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
Re: MythTV backend starts before HDHR tuners are available [ In reply to ]
On Thu, Nov 16, 2023, 2:51 PM Will Dormann <wdormann@gmail.com> wrote:

> On 11/16/23 2:15 PM, James Abernathy wrote:
> >
> > At the end of the post below is how to do it.
> >
> > https://forum.mythtv.org/viewtopic.php?f=46&t=5531
> > <https://forum.mythtv.org/viewtopic.php?f=46&t=5531>
> >
>
>
> Thanks as well! While a time-based delay worked fine for me, this seems
> a touch more polished as it's based on the status of the device, as
> opposed to wall-clock time.
>
>
> -WD
>


I've seen the delay be from 10 to 26 seconds

Jim A
Re: MythTV backend starts before HDHR tuners are available [ In reply to ]
On Thu, Nov 16, 2023 at 12:40:26PM -0500, Will Dormann wrote:
> So my questions at this point are:
>
> 1) Is "Added 0 devices from <DeviceName>" a symptom of the MythTV backend
> starting up before the network is fully up?
>
> 2) If 1) is true, what is an appropriate way to get an Ubuntu 22.04 system
> to start MythTV only after the network is fully up and running?

I have the following in my mythbackend.service file. 192.168.1.24 is
one of my HDHRs.

ExecStartPre=timeout 30 sh -c "while ! ping -c1 192.168.1.24 ; do sleep 1 ; done"

David
--
David Engel
david@istwok.net
_______________________________________________
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
Re: MythTV backend starts before HDHR tuners are available [ In reply to ]
On Thu, 16 Nov 2023 18:29:38 +0000, you wrote:

>The "cheap" way would be something like a
>ExecStartPre=-/usr/bin/sleep 10

Please never recommend using a delay to fix a race condition. It
almost always fails to fix the problem properly - something else
happens that changes the timing of the race condition and you will get
a failure again. The proper fix for any race condition is to wait for
the thing that is slow to come up to actually be up. So in this case,
for HDHR tuners, you make it wait for the tuners to actually be
available and responding.

In the more general case of the network being up so mythbackend will
bind to the IP address of the backend box, and then will be available
for external frontends to connect to, you need to ping something
outside the backend box and only allow mythbackend to be started after
you get a ping reply. Waiting for an HDHR tuner to be available meets
that condition, but you can just ping a router or switch or something
on your network that responds to ping requests. That is what I do on
Ubuntu 22.04, and I have a systemd unit that does the pings and then
can be used by any other systemd unit to check if the network is fully
up:

root@mypvr:~# systemctl cat local-network-pingable.service
# /etc/systemd/system/local-network-pingable.service
[Unit]
Description=Wait for the local network to be pingable
After=network.target

[Service]
Type=simple
ExecStartPre=/bin/bash -c "/usr/local/bin/wait-until-pingable.py
switch.jsw.gen.nz 30"
ExecStart=/bin/true

[Install]
WantedBy=multi-user.target

(Sorry for the line wrap - my email client has no way turn of line
wrapping. So the ExecStartPre= line is actually one line, not two.)

You can get a copy of my wait-until-pingable.py program from my web
server:

http://www.jsw.gen.nz/mythtv/wait-until-pingable.py

Then you create an override file for mythtv-backend.service:

sudo systemctl edit mythtv-backend.service

and put this in it:

[Unit]

Wants=local-network-pingable.service
After=local-network-pingable.service

Or add that to an existing override file. Then do:

sudo systemctl daemon-reload

I have other things that also need to wait for the network to be up,
so I use a separate systemd unit. If you only have mythbackend
needing that, you can just put an appropriate ping command into the
mythtv-backend.service config in an override file.
_______________________________________________
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