[mythtv-users] Upgrade to Mint 21 broke mythweb
stephen_agent at jsw.gen.nz
Fri Apr 14 09:47:54 UTC 2023
On Thu, 13 Apr 2023 21:07:25 -0700, you wrote:
>On 4/13/23 20:52, Stephen Worthington wrote:
>> On Thu, 13 Apr 2023 19:32:58 -0700, you wrote:
>>> On 4/10/23 13:42, Jay Harbeston wrote:
>>>>> On Apr 10, 2023, at 3:28 PM, Douglas Peale <Douglas_Peale at Comcast.net> wrote:
>>>>> I have upgraded my computer to Mint 21
>>>>> MythTV front end and back end are working
>>>>> Browser says "Unable to connect" when trying to access https://localhost/mythweb/
>>>> Sounds like apache service is not running. That would be the first step.
>>> Update to this issue:
>>> I have done a clean install of mint 21, and restored my home directory (that was a nightmare caused by odd behavior of "BackInTime")
>>> I have installed the ppa for MythTV 33, and installed mythTV
>>> I have restored the database to MythTV and adjusted the passwords as required.
>>> Everything appears to be working, including mythweb.
>>> I did have a bit of trouble with the network tuners not being found, fixed after re-scanning for channels.
>>> has the race between MythBackEnd starting and the network starting been fixed in 33? or do I need to look through my notes on
>>> how to fix that?
>> No, the network race condition has not been fixed. The systemd unit
>> mythtv-backend.service as installed by the packages is designed to
>> work with the majority of systems where they do not use network tuners
>> or have external frontends. So if you do need mythbackend to wait for
>> the network to be fully up, you still need to do a fix for that.
>> However, mythbackend now does signal to systemd that it has fully
>> started up, so things that need to wait for mythbackend can now rely
>> on waiting for systemd to tell them that the mythtv-backend unit has
>> started. To make it do this, you need to change the Type= line in the
>> [service] section to "Type=notify" (do this in an override file).
>> After that change, you will notice that when you manually run
>> "systemctl start mythtv-backend", the command will not return until
>> mythbackend has fully started up, so it will take much longer to get a
>> command prompt back again.
>Is there a document that shows the best way to fix the race condition?
>Last time I did this there was a bit of an argument going on about how to do it the correct way.
>I think I solved it last time with a simple delay which annoyed some people.
Simple delays never actually solve race conditions. They just make
them much more unlikely to happen, until something changes which
affects the timing enough (such as an automatic fsck happening at boot
time). To fix a race condition, you need to wait for the necessary
resource(s) to actually be available.
There are two fairly obvious ways of doing this if you have HDHR
tuners. One is to wait for the HDHR tuners to be ready, for example
using Bill Meek's hdhomerun_check.py program in the current thread
titled "HDHomerun" which started on 2023-04-14 with a post from Daryl
The other way (which I use as I do not use HDHR tuners, but do use
remote frontends) is to wait until I can ping my Ethernet switch. You
can use anything that is part of your network infrastructure that is
pingable and will be up before you boot your MythTV box. I use my
switch as it is a smart one that is pingable and is the lowest level
of my network infrastructure - if it is not up, the network does not
exist. For instructions on how to use this method, go to the mailing
and search for "local-network-pingable.service", which should lead you
to this thread:
My method is more general, as it creates a systemd service that any
other systemd unit can also wait on, and I do have other units on that
box that also need to wait for the network to be up, such as my Bind 9
secondary DNS server.
More information about the mythtv-users