On Thu, 3 Sep 2020 12:11:47 -0700, you wrote:
>On 9/3/20 1:59 AM, Stephen Worthington wrote:
>> On Wed, 2 Sep 2020 21:30:00 -0700, you wrote:
>>
>>> 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
>>> hurting anything.
>>>
>>> Thank you for the instructions.
>> The extra delay does hurt your bootup time, but apart from that does
>> no damage. But as I have on a number of occasions found myself
>> booting up just before a recording is due to start, I would recommend
>> removing the extra delay. It is very annoying missing the start of a
>> recording.
>My system is set up to automatically boot itself about 30 minutes before a recording. The 30 second delay will not be a problem.
>
>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.
>
>This means that it is no more effective at avoiding problems than a fixed 30 second delay.
>
>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.
Yes, exactly. If the delay needed is more than 30 seconds,
mythbackend will be started anyway, but will not see the slow
tuner(s). No-one has yet reported needing more than 30 seconds
though. You can see the actual time taken in the logs. This is from
/var/log/syslog for my most recent reboot:
Sep 3 23:26:55 mypvr systemd[1]: Starting Wait for the local network
to be pingable...
Sep 3 23:26:55 mypvr /wait-until-pingable.py: Starting
Sep 3 23:26:55 mypvr /wait-until-pingable.py: ping of
switch.jsw.gen.nz succeeded
Sep 3 23:26:55 mypvr /wait-until-pingable.py: Exiting
Sep 3 23:26:55 mypvr systemd[1]: Started Wait for the local network
to be pingable.
So by the time systemd started wait-until-pingable.py, the network was
up as the ping succeeded immediately. That PC has my secondary
nameserver on it, so the lookup of the name switch.jsw.gen.nz happened
almost instantly and did not delay things either.
>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
>tuners it has been told are there.
Absolutely. The gold standard way of doing this is for a program to
register itself with the system to get all messages about network
interfaces going up and down and then when it sees a message about a
relevant interface or IP address, it will retry any connections it
needs to make. This is a tricky bit of code, but programs like MySQL
and MariaDB operate like this, so it is clearly possible to do it.
Mythbackend however does not have any mechanism for finding tuners
except at startup. If a tuner fails I think it may still keep on
trying to use it. At best it will mark it as bad and not use it after
that, but then it would never use it ever again until the next time it
was started up. But if it keeps on trying to use a bad tuner, you
will keep on getting missed recordings that might have been able to be
recorded on another tuner. I do know that if a recording is failing
on a tuner, mythbackend will start another back-to-back recording
using the same tuner and will have that recording also fail.
_______________________________________________
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