[mythtv-users] mythtv-users Digest, Vol 196, Issue 18
stephen_agent at jsw.gen.nz
Sat Jul 20 14:14:40 UTC 2019
On Sat, 20 Jul 2019 08:38:22 -0400, you wrote:
>On 7/20/19 8:00 AM, mythtv-users-request at mythtv.org wrote:
>> On Sat, 20 Jul 2019 09:37:03 +0100, you wrote:
>>> On 20/07/2019 09:15, Stephen Worthington wrote:
>>>> If this is your first network tuner, you may not have done the fix for
>>>> getting mythbackend to start up only after the network is actually
>>>> available. So every time you reboot, mythbackend will not see the
>>>> network tuner as it starts when only localhost is up. If it is unable
>>>> to test a tuner at startup, it marks it as bad and does not use it. To
>>>> test if this is your problem, just restart mythbackend, and as the
>>>> network is up now, it will see the network tuners and everything will
>>>> work unitl the next reboot.
>>>> If you need that fix, see my post on the recent "Need mythtv-backend
>>>> startup advice" thread.
>>> This is getting old. Is anyone going to fix the backend systemd service file so that it does the
>>> right thing - wait for the ACTUAL network to be up, not just localhost?
>>> That way, we won't keep getting puzzled calls from users whose systems can't find network tuners, etc.
>> There are plenty of users who do not need the full network to be up -
>> they do not have network tuners and are running just a combined
>> backend/frontend. For them, localhost is all they need. The
>> Mythbuntu install package already asks if you are going to need
>> outside access for frontends, or something like that, if I remember
>> correctly. It should change the question to make it clear that
>> network tuners are included, and when the answer to that question is
>> that the network is needed, it should install the proper systemd
>> setup. Anyone adding network tuners later would then only need to run
>> dpkg-reconfigure and change their answer to that question.
>Perhaps I did not make it clear enough. Immediately after I installed
>the tuner (which a replaced an broken HDHR) MythTV was working fine
>three weeks back. I tried Live TV after a recording was missed and found
>that MythTV was unabled to tune into HDHR.
>Also note that HDHR Config GUI on this box and another device on the
>network was able to tune into OTR channels fine.
And those are the exact symptoms of this race condition. It does not
always happen, depending on the timing of the startup of mythbackend.
When it does, mythbackend is unable to see the tuner at startup and
marks it bad. If you later use other software to talk to the tuner,
by then the network is up and it works. Did you try the test for
this, restarting mythbackend? If you manually restart mythbackend and
it then can use the tuner, that is pretty good diagnostic information
that says it was the race condition that caused this problem. Let me
be very clear here. ANYONE WHO IS USING NETWORK TUNERS NEEDS TO DO
THIS FIX! Or some other variant of it - there are different ways to
do this. So if you do not have a fix in place, please put one in
And also ANYONE WHO IS USING REMOTE FRONTENDS NEEDS TO DO THIS FIX.
When mythbackend starts up before the Ethernet interface(s) are up, it
will not bind the IP addresses on the Ethernet interfaces. So it will
not be listening for remote frontends talking to it, as it is unable
to talk to the network outside the local PC. Unlike some software
(such as MySQL/MariaDB), mythbackend does not check for changes to the
network interfaces that happen after it starts up. What it sees when
it starts is what it uses to work with. If the IP address(es) for the
Ethernet interfaces are not available when it starts, it will never
see them until it is started again.
The same applies if you want to access Webfrontend or the MythTV
Service APIs from outside the backend PC - you need to do this fix.
MythWeb is unaffected as that is run by Apache, which is like
MySQL/MariaDB and will see changes that happen on the network
interfaces after it starts up.
More information about the mythtv-users