[mythtv-users] HDHR offline but not really

[DryHeat122]

On Fri, Sep 4, 2020, 3:05 AM Stephen Worthington <stephen_agent at jsw.gen.nz>
wrote:

> 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.
>

FWIW I set it up per suggestions, and haven't had problems since.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200904/4e629f02/attachment.htm>