[mythtv-users] Recording failure.

Stephen Worthington stephen_agent at jsw.gen.nz
Fri Jan 18 04:17:20 UTC 2019


On Thu, 17 Jan 2019 13:09:28 -0800, you wrote:

>Now twice I have had a recording failure where every recording after that
>time fails.  The first time I thought the HDHR Power Supply might be bad so
>I replaced it. This time I had failures on HDHR1 and HDHR3 so I think that
>rules out a single point of failure involving the HDHR.  The other symptom
>was that the IR remote did not work.
>
>One thing in common is that both of these are initialized in rc.local.
>
>
>*echo -n 15  > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold*
>*hdhomerun_config 10137DC1 set /ir/target "192.168.1.111:5000
><http://192.168.1.111:5000> no_clear"*
>*#this is a hack.  I don't know what is starting lircd*
>*killall lircd*
>*lircd -H udp -d 5000*
>*exit 0*
>
>I know rc.local is out of favor but I am old school and it worked 10 years
>ago so I just used it again when I upgraded my system this year.
>
>The failure is first evidenced in the backend log with this entry
>
>*Jan 15 23:35:00 NewMyth mythbackend: mythbackend[1183]: I TVRecEvent
>tv_rec.cpp:3686 (TuningFrequency) TVRec[1]: TuningFrequency*
>*Jan 15 23:35:03 NewMyth mythbackend: mythbackend[1183]: E TVRecEvent
>recorders/hdhrstreamhandler.cpp:382 (TunerGet) HDHRSH(10137DC1-0): Get
>request failed#012#011#011#011eno: Resource temporarily unavailable (11)*
>And then a series of error messages and repeats of the "Resource
>temporarily unavailable"
>
>The scheduled recording the next morning failed as well and as that is my
>wife's morning show, I was summoned to fix it which I did by restarting the
>computer but not the HDHRs.
>
>The IR remote works through the HDHR so that seems to be the common
>element. I am guessing it is resetting or at least losing the connection
>that is initialized by the rc.local script.
>
>I am considering adding the config to a cron job and running that before my
>wife's show starts but is there something else I might do? Suggestions
>welcome.
>
>Allen

The biggest problem with using re.local is that any command that fails
instantly terminates rc.local - no further commands are executed.  So
doing a series of commands as you are in rc.local is not a good idea.
It is much better to get rc.local to run a separate script.  So you
would put your commands in a script such as
/usr/local/bin/start-hdhrs.sh, and then run that from rc.local like
this:

/usr/local/bin/start-hdhrs.sh &

Putting the & at the end of the command line will run that script in
parallel with any further commands in rc.local, and any failures of
commands in the script will not affect rc.local.

Or even better, you could run your script from a systemd .service unit
that you create in /etc/systemd/system.  Then you could make the
mythtv-backend.service unit wait until your script completed
successfully before it started.

Here is a simple hdhr-startup.service file to run such a script:

[Unit]
Description=Start the HDHR tuners.
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/bin/bash -c "/usr/local/bin/start-hdhrs.sh"

[Install]
WantedBy=multi-user.target

But I think that the HDHRs need more of the network working than you
get with network-online.target, so if you are using NetworkManager for
your networking, you would probably want to do this:

sudo systemctl enable NetworkManager-wait-online.service

and then change "network-online.target" lines to
"NetworkManager-wait-online.service".

I have never had cause to use a "oneshot" unit before, so I might have
missed something in the .service file.  So if you want to try this,
please test it carefully.  I am at the beach this month, so I can not
do proper testing with just my laptop.


More information about the mythtv-users mailing list