[mythtv-users] Lose TV tuners after PC reboot

[Stephen Worthington]

On Tue, 24 Apr 2018 12:59:29 -0500, you wrote:

>On 04/24/2018 11:43 AM, Mike Bibbings wrote:
>> On 24/04/18 16:52, Curtis Gedak wrote:
>>> Hi Justin,
>>>
>>> I believe that Stephen's suggestion is correct.  That is that the MythTV
>>> backend is starting up before either the TCP/IP network or the network
>>> tuner (HDHomeRun) is up and running.
>>>
>>> I encountered this issue on a PVR I build for a family member.  While I
>>> was unable to get a 100% reliable solution I did find that delaying the
>>> startup of the MythTV backend improved the situation immensely.
>>>
>>> If you are curious about the things I tried, I wrote an article on it.
>>> Please note that the article was on Mythbuntu 14.04 with MythTV 0.27, so
>>> the exact steps would not apply for your Mythbuntu 16.04 installation.
>>>
>>> How to Fix HDHomeRun Connect Not Starting MythTV Recordings or Live TV
>>> http://gedakc.users.sourceforge.net/display-doc.php?name=pvr-hdhomerun-not-recording
>>>
>>> Regards,
>>> Curtis

>> This is what I use on systems using systemd (*ubuntu 16.04, 18.04, Debian Stretch)
>> 
>> # setup mythtv-backend.service startup delay
>> In a terminal on the machine running mythtv backend:
>> 
>> sudo systemctl edit mythtv-backend.service # and add the following three lines
>> 
>> # Delay mythbackend startup to allow network and tuners to fully stabilise
>> [Service]
>> ExecStartPre=/bin/sleep 20
>> 
>> 
>> Then exit from the edit screen (it uses nano by default, so Ctrl+x, then
>> y, then Return key) then  reboot the machine
>> 
>> Mike
>
>The sleep works A-OK. Another HDHR network solution is here:
>
>     https://forum.mythtv.org/viewtopic.php?f=29&t=1467&p=7138#p7138
>
>which is harder to do. Truth be told, when I check the log file
>created by the new service, the delay is usually around 17 seconds.

Due to my email server having died, I have only just started catching
up with these threads.

Using a sleep delay is never a good idea with race conditions. Someone
always suggests it, and it does work, but only until something else
changes.  For example, what happens when a disk needs an fsck on
startup?  That completely changes the timings of when things happen
during startup, and can easily break a sleep fix.  Please, this is a
solved problem - if you are using a sleep timer, change to using the
proper fix I have posted about many times now:

https://lists.gt.net/mythtv/users/609209#609209

This fix makes mythbackend correctly wait for the network to be up and
ready for access by external frontends and for access to networked
tuners.

The fix that creates an hdhomerun.service looks like it is an even
better fix, for people with HDHomerun tuners, as it makes mythbackend
be started only after the HDHR tuners are actually available, not just
after networking is up properly.  My fix is more general and will work
for other network tuners, and will also work where external frontends
are used and mythbackend comes up too early to bind the external
network interface, preventing the external frontends from connecting
to it.

If you are using internal tuners, you should also be waiting for them
to be ready.  To do that, you need to create a file like this:

root at mypvr:/etc/udev/rules.d# cat 99-tuner.rules
#
# Create systemd device units for capture devices
#
SUBSYSTEM=="video4linux", TAG+="systemd"
SUBSYSTEM=="dvb", TAG+="systemd"
SUBSYSTEM=="firewire", TAG+="systemd"

Those rules make systemd see the tuner devices coming up and creates
events for them.  The 99-tuner-rules file needs to be chown root:root
and chmod u=rw,g=r,o=r.  In your
/etc/systemd/system/mythtv-backend-service.d/mythtv-backend-override.conf
file, you add rules like these for my five DVB-T2 tuners:

[Unit]
Wants=dev-dvb-adapter0-frontend0.device
After=dev-dvb-adapter0-frontend0.device
Wants=dev-dvb-adapter1-frontend0.device
After=dev-dvb-adapter1-frontend0.device
Wants=dev-dvb-adapter2-frontend0.device
After=dev-dvb-adapter2-frontend0.device
Wants=dev-dvb-adapter3-frontend0.device
After=dev-dvb-adapter3-frontend0.device
Wants=dev-dvb-adapter4-frontend0.device
After=dev-dvb-adapter4-frontend0.device

Those rules correspond to the /dev/dvb/adapter<x> devices.

And finally, you might also want to have mythbackend wait for the hard
drives where your recordings go to be mounted.  This is less important
as mythbackend always checks the drives before each recording.  But
this is what I have for my seven recording drives:

[Unit]
Wants=mnt-rec1.mount
After=mnt-rec1.mount
Wants=mnt-rec2.mount
After=mnt-rec2.mount
Wants=mnt-rec3.mount
After=mnt-rec3.mount
Wants=mnt-rec4.mount
After=mnt-rec4.mount
Wants=mnt-rec5.mount
After=mnt-rec5.mount
Wants=mnt-rec6.mount
After=mnt-rec6.mount
Wants=mnt-rec7.mount
#After=mnt-rec7.mount

Note that the rec7 partition (mounted on /mnt/rec7) has its "After"
line commented out.  The "Wants" line will get systemd to mount rec7
if it is available, but without the "After" line, mythbackend will not
wait for it to be mounted.  I have it that way as rec7 has been moved
to a four drive eSATA external mount which occasionally is
disconnected to be used elsewhere.