<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 4, 2020, 3:05 AM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz">stephen_agent@jsw.gen.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 3 Sep 2020 12:11:47 -0700, you wrote:<br>
<br>
>On 9/3/20 1:59 AM, Stephen Worthington wrote:<br>
>> On Wed, 2 Sep 2020 21:30:00 -0700, you wrote:<br>
>><br>
>>> I have followed the instructions you gave me a while ago. This seems to be working. I left the delay in place because it is not<br>
>>> hurting anything.<br>
>>><br>
>>> Thank you for the instructions.<br>
>> The extra delay does hurt your bootup time, but apart from that does<br>
>> no damage.  But as I have on a number of occasions found myself<br>
>> booting up just before a recording is due to start, I would recommend<br>
>> removing the extra delay.  It is very annoying missing the start of a<br>
>> recording.  <br>
<br>
>My system is set up to automatically boot itself about 30 minutes before a recording. The 30 second delay will not be a problem.<br>
><br>
>It occurred to me that this setup has a 30 second timeout, and will continue booting after 30 seconds even if the network is not up.<br>
><br>
>This means that it is no more effective at avoiding problems than a fixed 30 second delay.<br>
><br>
>It is a better solution than a 30 second delay in that it does not have to wait the full 30 seconds if the network is up.<br>
<br>
Yes, exactly.  If the delay needed is more than 30 seconds,<br>
mythbackend will be started anyway, but will not see the slow<br>
tuner(s).  No-one has yet reported needing more than 30 seconds<br>
though.  You can see the actual time taken in the logs.  This is from<br>
/var/log/syslog for my most recent reboot:<br>
<br>
Sep  3 23:26:55 mypvr systemd[1]: Starting Wait for the local network<br>
to be pingable...<br>
Sep  3 23:26:55 mypvr /wait-until-pingable.py: Starting<br>
Sep  3 23:26:55 mypvr /wait-until-pingable.py: ping of<br>
<a href="http://switch.jsw.gen.nz" rel="noreferrer noreferrer" target="_blank">switch.jsw.gen.nz</a> succeeded<br>
Sep  3 23:26:55 mypvr /wait-until-pingable.py: Exiting<br>
Sep  3 23:26:55 mypvr systemd[1]: Started Wait for the local network<br>
to be pingable.<br>
<br>
So by the time systemd started wait-until-pingable.py, the network was<br>
up as the ping succeeded immediately.  That PC has my secondary<br>
nameserver on it, so the lookup of the name <a href="http://switch.jsw.gen.nz" rel="noreferrer noreferrer" target="_blank">switch.jsw.gen.nz</a> happened<br>
almost instantly and did not delay things either.<br>
<br>
>Perhaps a much better solution would be if MythTV would re-try the network tuners every minute or so if it can't access the<br>
>tuners it has been told are there.<br>
<br>
Absolutely.  The gold standard way of doing this is for a program to<br>
register itself with the system to get all messages about network<br>
interfaces going up and down and then when it sees a message about a<br>
relevant interface or IP address, it will retry any connections it<br>
needs to make.  This is a tricky bit of code, but programs like MySQL<br>
and MariaDB operate like this, so it is clearly possible to do it.<br>
<br>
Mythbackend however does not have any mechanism for finding tuners<br>
except at startup.  If a tuner fails I think it may still keep on<br>
trying to use it.  At best it will mark it as bad and not use it after<br>
that, but then it would never use it ever again until the next time it<br>
was started up.  But if it keeps on trying to use a bad tuner, you<br>
will keep on getting missed recordings that might have been able to be<br>
recorded on another tuner.  I do know that if a recording is failing<br>
on a tuner, mythbackend will start another back-to-back recording<br>
using the same tuner and will have that recording also fail.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">FWIW I set it up per suggestions, and haven't had problems since.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div></div>