[mythtv-users] Upgrade to Mint 21 broke mythweb

[Douglas Peale]

On 4/14/23 02:47, Stephen Worthington wrote:
> 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?
>>>>
>>>>
>>>> Thanks.
>>> 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
> McDonald.
>
> 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
> list archives:
>
> https://lists.archive.carbon60.com/mythtv/users/
>
> and search for "local-network-pingable.service", which should lead you
> to this thread:
>
> https://lists.archive.carbon60.com/mythtv/users/625987
>
> 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.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

I implemented a method that checks to see if it can access one of my HDHomeRun tuners. it has a 30 second time out.

The only way it is better than a fixed timeout is that it will return sooner if the HDHomeRun is accessible. I have four 
HDHomeRun tuners in my system, Sometimes they are offline. I don't want MythTV not to start because one tuner box is down, so I 
can't wait forever.

You are correct that a delay does not solve a race condition, but in this case, solving the race condition "correctly" can get 
you locked out of mythTV if what you are waiting for never happens. For example, I might want to watch a recorded TV show while 
waiting for a replacement network switch to arrive. Something to do when I have no network connectivity. If MythTV is stuck 
waiting for the network to connect, I would not be able to do that.

In any case, my "incorrect" solution appears to be working.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x7B9B5178E6AE112A.asc
Type: application/pgp-keys
Size: 2452 bytes
Desc: OpenPGP public key
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20230414/671a63e7/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20230414/671a63e7/attachment.sig>