[mythtv-users] mythbackend Start-up issue - possible race with dvb device firmware loading

[Stephen Worthington]

On Wed, 18 Nov 2020 09:34:06 +0000, you wrote:

>After power on, about 1 in 20 mythbackend startups are failing for me.
>
>Symptoms are that the backend is running, as reported by *systemctl status,*
>but is unresponsive. The mythbackend logfile starts normally but stops
>after about 10 seconds with no error
>
>Recordings and frontend connections fail and manual intervention is
>required to recover.
>
>*systemctl restart mythbackend* succeeds after a long delay (more than a
>minute) and the backend then starts normally.
>
>
>The best clue I have is this, from the system journal
>
>...
>Nov 16 21:09:57 localhost.localdomain kernel: si2168 4-0064: downloading
>firmware from file 'dvb-demod-si2168-b40-01.fw'
>Nov 16 21:09:58 localhost.localdomain kernel: si2168 4-0064: firmware
>version: B 4.0.11
>Nov 16 21:09:58 localhost.localdomain kernel: si2157 5-0060: firmware
>version: 3.0.5
>...
>
>is happening at the same time as this, in the mythbackend log
>...
>2020-11-16 21:09:58.235627 I [2496/2496] CoreContext cardutil.cpp:1189
>(SetDeliverySystem) - CardUtil[2]: Set delivery system: DVB-T2
>2020-11-16 21:09:58.296591 D [2496/2496] CoreContext
>recorders/dtvchannel.cpp:295 (SetChannelByString) -
>DTVChan[2](/dev/dvb/adapter292e/frontend0): SetChannelByString(1):
>Initialize multiplex options m_tunerType:34 mplexid:8
>2020-11-16 21:09:58.321345 D [2496/2558] TVRecEvent portchecker.cpp:75
>(checkPort) - PortChecker::checkPort(): host 127.0.0.1 port 3306 timeLimit
>30000 linkLocalOnly 1
>
>...which is where the backend log stops.
>
>On successful startups the firmware load appears to complete during the
>second before the mythbacked access.
>
>I have a udev rule on the usb DVB capture device to create a meaningful
>name as below.
>
>SUBSYSTEM=="dvb", ATTRS{idProduct}=="025f", PROGRAM="/bin/sh -c 'K=%k;
>K=$${K#dvb}; printf dvb/adapter292e/%%s $${K#*.}'", SYMLINK+="%c",
>TAG+="systemd"
>
>and the following wait commands in /etc/systemd/system/mythbackend.service
>
>Wants=dev-dvb-adapter292e-frontend0.device
>After=dev-dvb-adapter292e-frontend0.device
>
>As far as I can tell this is not a problem.  journalctl reports
>
>Nov 16 21:09:12 localhost.localdomain systemd[1]: Found device
>/dev/dvb/adapter292e/frontend0.
>
>Which is 45s before mythbackend log starts and 55s before it stops (so the
>udev wait is probably unnecessary and may not work if required?)
>
>Assuming that this is the problem, how do I delay starting mythbackend
>until the dvb device firmware has loaded?
>
>
>I'm running Fedora FC32 with MythTV 32 on a Zotac Ion.
>
>I have two usb dvb-t capture devices, a nanostick 290 and a nanostick
>292e.  The 290 does not appear to require a firmware download.  It is the
>292e which is apparently causing the trouble.
>
>Thanks in advance,
>
>D

If you are correct about it being a problem with firmware loading,
then you probably want to trigger the firmware to be loaded before you
start mythbackend.  To do that, you would want to make the tuner tune
to a channel and start playing from that channel.  You can do that
using command line tools such as dvbv5-zap to tune, then copy data
from the tuner.  So something like this might work:

dvbv5-zap -r -o /dev/null -t 2 -a <adapter no.> -c <channels file>
<channel name>

Then you could run that command in a systemd unit at startup and have
the mythtv-backend unit wait on that unit before starting.  You would
need to check that the /usr/share/dvb/dvb-t files have file with a
channel you can use for this, or create your own file in that format
with the correct data for a channel.  I am not sure where Fedora will
put those files, but if you search for a file "uk-Oxford" you should
find them ("locate uk-Oxford" if you have mlocate installed).

Note that I have never actually done this, so YMMV.  Please ask if you
need more detailed help.

One thing you probably should also do is to fix the shutting down of
mythbackend.  Like all MythTV programs, it suffers from a bug where it
fails to shut down properly when requested to do so externally using a
normal kill (= kill -15 = kill -SIGTERM), which is what systemd does.
One thread is left running, and systemd will then wait for 30 seconds
before finally killing it with a kill -9.  But if you do two normal
kills with a short delay between them, it will shut down instantly
after the second kill.  You can find instructions for my fix for this
in this thread:

https://lists.archive.carbon60.com/mythtv/users/627998

by searching for "mythbackendstop.sh".

Doing that fix should solve your problem where stopping mythbackend
takes >30 seconds.  It normally shuts down for me in <2 seconds.  This
fix also speeds up system shutdown and reboot times by 30 seconds if
mythbackend is running.