Mailing List Archive

1 2  View All
Re: Upgrade to Mint 21 broke mythweb [ In reply to ]
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@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@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Upgrade to Mint 21 broke mythweb [ In reply to ]
On Fri, Apr 14, 2023 at 12:09?AM Douglas Peale <Douglas_Peale@comcast.net>
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@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.
>
>
Since I use networked tuners like HDHomerun on my network as well as
directly connected to a spare RJ45 ethernet port on my computers, I use a
method that supports both. If you look at the last section of this Mythtv
Forum post you will see the section that talks about fixing the delay.

https://forum.mythtv.org/viewtopic.php?f=46&t=5225

Jim A
Re: Upgrade to Mint 21 broke mythweb [ In reply to ]
On Fri, 14 Apr 2023 21:47:54 +1200, you wrote:

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

Oops, I just noticed that the thread name has a typo in it - search
for "HDHomewrun".
_______________________________________________
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
Re: Upgrade to Mint 21 broke mythweb [ In reply to ]
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@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@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.
Re: Upgrade to Mint 21 broke mythweb [ In reply to ]
On Friday 14 April 2023 01:08:45 PM (-05:00), Douglas Peale wrote:

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



No idea how your script is called, but if in an override file for
mythtv-backend.serevice, then ExecStartPre
(etc.) prevents the service from failing because there's a dash before the
path:



[Service]

ExecStartPre=-/path/to/some_script_name

Cares for my case where 'I just want to watch recordings' as mentioned
above.

--
Bill
_______________________________________________
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

1 2  View All