Mailing List Archive

On Wed, 27 Apr 2022 18:31:04 -0500, you wrote:

>I have and existing Ubuntu 18.04/Mythtv V30 box, that works fine.? I
>just moved, so needed to change my listing setup; figured I would
>upgrade at the same time, so built a new box with Ubuntu 20.04 (Mate),
>Mythtv v32, and configured with one tuner of an HDHR Connect Quatro.?
>Installation went fine but thing were very unstable, downright flaky.
>
>Found two issues; there were two master backends on the same network,
>and there were two systemd scripts enabled on the new box. I unchecked
>the master backend selection in setup of the existing 18.04 backend, but
>the new box was still unstable.?? The scripts were mythbackend.service
>and mythtv-backend.service.? I disabled mythbackend.service and now it
>works fine.
>
>I came across a recommendation to use mythtv-backend on Ubuntu, but the
>Systemd mythbackend Configuration wiki seems to favor
>mythbackend.service.? Which is? the preferred script?

If you have installed the Ubuntu 20.04 MythTV packages from the main
Ubuntu repositories or the fixes packages from the Mythbuntu
repository, both sets of packages use mythtv-backend.service. It is
possible that Mate has different packages, but I do not know where
mythbackend.service will have come from. If you want to find out,
here are instructions for finding which package a file comes from:

https://linuxhint.com/find_which_package_contains_specific_file_ubuntu/

However, if you are using networked tuners, the standard
mythtv-backend.service file does not account for this as it starts
mythtbackend when networking is first available (when the localhost
interface is up), not when networking is fully up and network tuners
are actually available. Mythbackend tests tuners immediately after it
starts up and will not use any that do not work when tested, so it
will normally mark all network tuners as bad in that situation. So
you need to add an override file that makes the startup of mythbackend
wait until the network tuners are actually accessible. The usual way
to do that is to make the override file ping one of your network
tuners and get a response before it will allow mythbackend to start.
Instructions on how to do that are available on this list here:

https://lists.archive.carbon60.com/mythtv/users/625992
_______________________________________________
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

Stephen Worthington <stephen_agent@jsw.gen.nz> writes:

> On Wed, 27 Apr 2022 18:31:04 -0500, you wrote:
>
>>I have and existing Ubuntu 18.04/Mythtv V30 box, that works fine.  I
>>just moved, so needed to change my listing setup; figured I would
>>upgrade at the same time, so built a new box with Ubuntu 20.04 (Mate),
>>Mythtv v32, and configured with one tuner of an HDHR Connect Quatro. 
>>Installation went fine but thing were very unstable, downright flaky.
>>
>>Found two issues; there were two master backends on the same network,
>>and there were two systemd scripts enabled on the new box. I unchecked
>>the master backend selection in setup of the existing 18.04 backend, but
>>the new box was still unstable.   The scripts were mythbackend.service
>>and mythtv-backend.service.  I disabled mythbackend.service and now it
>>works fine.
>>
>>I came across a recommendation to use mythtv-backend on Ubuntu, but the
>>Systemd mythbackend Configuration wiki seems to favor
>>mythbackend.service.  Which is  the preferred script?
>
> If you have installed the Ubuntu 20.04 MythTV packages from the main
> Ubuntu repositories or the fixes packages from the Mythbuntu
> repository, both sets of packages use mythtv-backend.service. It is
> possible that Mate has different packages, but I do not know where
> mythbackend.service will have come from. If you want to find out,
> here are instructions for finding which package a file comes from:
>
> https://linuxhint.com/find_which_package_contains_specific_file_ubuntu/
>
> However, if you are using networked tuners, the standard
> mythtv-backend.service file does not account for this as it starts
> mythtbackend when networking is first available (when the localhost
> interface is up), not when networking is fully up and network tuners
> are actually available. Mythbackend tests tuners immediately after it
> starts up and will not use any that do not work when tested, so it
> will normally mark all network tuners as bad in that situation. So
> you need to add an override file that makes the startup of mythbackend
> wait until the network tuners are actually accessible. The usual way
> to do that is to make the override file ping one of your network
> tuners and get a response before it will allow mythbackend to start.
> Instructions on how to do that are available on this list here:
>
> https://lists.archive.carbon60.com/mythtv/users/625992

That's a good tip, but it may not be needed. I have the same
mythtv-backend.service file as the OP in that thread and I have never
had an issue with my hdhr tuner being marked as unavailable.

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

On Thu, 28 Apr 2022 06:13:42 -0500, you wrote:

>That's a good tip, but it may not be needed. I have the same
>mythtv-backend.service file as the OP in that thread and I have never
>had an issue with my hdhr tuner being marked as unavailable.

Until it happens. It is a race condition - it is likely that there is
something in your system that makes mythbackend start late enough that
networking is up. Most of the time. But with race conditions,
eventually something happens that changes the timing, and then
mythbackend starts earlier and the tuner is not found. Things that
affect the timing fairly drastically are fscks being run on partitions
at startup, which will happen from time to time if you are using ext
format partitions, or if you have a power failure and the partitions
are still marked as dirty on the next boot. Or some random program
that used to hold things up for a while gets a new version that makes
it work faster. Or a new version of systemd gets installed that runs
something in parallel that used to run in sequence. Or you upgrade to
Ubuntu 22.04 LTS and the timings have changed and you always get
mythbackend starting too early. That is the nature of race conditions
- some systems will see the problem on almost every boot, and others
will not see it except maybe once in the lifetime of the system.

So, have you ever had a problem where mythbackend did not seem to be
working and you restarted it and then it was working? That is the
characteristic pattern that you see with this race condition - it only
happens at boot, so a restart of mythbackend even a few seconds after
boot will never have it happen.

It really is always better to actually fix race conditions by making
things happen in the required order, rather than just rely on "its
working, so why bother?". Unfixed race conditions will usually bite
you at some time and it often happens when it will cause real problems
for you, like when you are trying to work out some hardware problem
and the race condition also pop up and fools you into thinking that a
bit of hardware is faulty so you buy a new one that you really did not
need to.
_______________________________________________
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

On 4/27/2022 8:40 PM, Stephen Worthington wrote:
> On Wed, 27 Apr 2022 18:31:04 -0500, you wrote:
>
>> I have and existing Ubuntu 18.04/Mythtv V30 box, that works fine.  I
>> just moved, so needed to change my listing setup; figured I would
>> upgrade at the same time, so built a new box with Ubuntu 20.04 (Mate),
>> Mythtv v32, and configured with one tuner of an HDHR Connect Quatro.
>> Installation went fine but thing were very unstable, downright flaky.
>>
>> Found two issues; there were two master backends on the same network,
>> and there were two systemd scripts enabled on the new box. I unchecked
>> the master backend selection in setup of the existing 18.04 backend, but
>> the new box was still unstable.   The scripts were mythbackend.service
>> and mythtv-backend.service.  I disabled mythbackend.service and now it
>> works fine.
>>
>> I came across a recommendation to use mythtv-backend on Ubuntu, but the
>> Systemd mythbackend Configuration wiki seems to favor
>> mythbackend.service.  Which is  the preferred script?
> If you have installed the Ubuntu 20.04 MythTV packages from the main
> Ubuntu repositories or the fixes packages from the Mythbuntu
> repository, both sets of packages use mythtv-backend.service. It is
> possible that Mate has different packages, but I do not know where
> mythbackend.service will have come from. If you want to find out,
> here are instructions for finding which package a file comes from:
>
> https://linuxhint.com/find_which_package_contains_specific_file_ubuntu/
>
> However, if you are using networked tuners, the standard
> mythtv-backend.service file does not account for this as it starts
> mythtbackend when networking is first available (when the localhost
> interface is up), not when networking is fully up and network tuners
> are actually available. Mythbackend tests tuners immediately after it
> starts up and will not use any that do not work when tested, so it
> will normally mark all network tuners as bad in that situation. So
> you need to add an override file that makes the startup of mythbackend
> wait until the network tuners are actually accessible. The usual way
> to do that is to make the override file ping one of your network
> tuners and get a response before it will allow mythbackend to start.
> Instructions on how to do that are available on this list here:
>
> https://lists.archive.carbon60.com/mythtv/users/625992
> _______________________________________________
> 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
For the installation, I used:
don@scotty:~$ sudo apt-get install mythtv

, which I assume is the Ubuntu main repositories.

apt-file didn't find "mythbackend.service" anywhere.  I may be the
culprit here, earlier in the week I was trying tons of things to
stabilize it, and manually installed mythbackend.service (from the wiki
instructions).  My last effort was to wipe the box and start over from
scratch, but I didn't think I had included that script....maybe I did.

Hmm, you pointed me to my own thread from 3 years ago to fix the network
ready issue :).  I wasn't having that problem (that I knew of), but used
anyway, just in case; worked great, thanks again.

Don


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

_______________________________________________
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

On Fri, 29 Apr 2022 08:59:33 -0500, you wrote:


>For the installation, I used:
>don@scotty:~$ sudo apt-get install mythtv
>
>, which I assume is the Ubuntu main repositories.

Which repository depends on what you have set up in
/etc/apt/sources.list.d. You really should be using the Mythbuntu
repository, so you get the latest v32-fixes versions as they are
released. The main Ubuntu repositories have v32 (without fixes),
except that they may get a later version occasionally (maybe when a
point release comes out). To see if you have the Mythbuntu repository
installed:

cd /etc/apt/sources.list.d
grep mythbuntu *.list

root@mypvr:/etc/apt/sources.list.d# grep mythbuntu *.list
mythbuntu-ubuntu-32-focal.list:deb
http://ppa.launchpad.net/mythbuntu/32/ubuntu focal main
mythbuntu-ubuntu-32-focal.list:# deb-src
http://ppa.launchpad.net/mythbuntu/32/ubuntu focal main

If the grep does not show any results, you do not have the Mythbuntu
repository installed. If you manually install repositories, you might
have put it in /etc/apt/sources.list, so you should also check that:

cd /etc/apt
grep mythbuntu *.list
_______________________________________________
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

On 4/29/2022 10:51 AM, Stephen Worthington wrote:
> On Fri, 29 Apr 2022 08:59:33 -0500, you wrote:
>
>
>> For the installation, I used:
>> don@scotty:~$ sudo apt-get install mythtv
>>
>> , which I assume is the Ubuntu main repositories.
> Which repository depends on what you have set up in
> /etc/apt/sources.list.d. You really should be using the Mythbuntu
> repository, so you get the latest v32-fixes versions as they are
> released. The main Ubuntu repositories have v32 (without fixes),
> except that they may get a later version occasionally (maybe when a
> point release comes out). To see if you have the Mythbuntu repository
> installed:
>
> cd /etc/apt/sources.list.d
> grep mythbuntu *.list
>
> root@mypvr:/etc/apt/sources.list.d# grep mythbuntu *.list
> mythbuntu-ubuntu-32-focal.list:deb
> http://ppa.launchpad.net/mythbuntu/32/ubuntu focal main
> mythbuntu-ubuntu-32-focal.list:# deb-src
> http://ppa.launchpad.net/mythbuntu/32/ubuntu focal main
>
> If the grep does not show any results, you do not have the Mythbuntu
> repository installed. If you manually install repositories, you might
> have put it in /etc/apt/sources.list, so you should also check that:
>
> cd /etc/apt
> grep mythbuntu *.list
> _______________________________________________
> 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 used the instructions at this wiki, which looks like mythbuntu:
https://www.mythtv.org/wiki/Installing_MythTV_on_Ubuntu

Again, it looks like mythbuntu:
don@scotty:/etc/apt/sources.list.d$ grep mythbuntu *.list
deb http://ppa.launchpad.net/mythbuntu/32/ubuntu focal main
# deb-src http://ppa.launchpad.net/mythbuntu/32/ubuntu focal main

And this looks correct:
don@scotty:/etc/apt/sources.list.d$ apt-cache policy mythtv
mythtv:
  Installed: 2:32.0+fixes.202204210037.bfae001d5c~ubuntu20.04.1
  Candidate: 2:32.0+fixes.202204250633.daa4e7e447~ubuntu20.04.1
  Version table:
     2:32.0+fixes.202204250633.daa4e7e447~ubuntu20.04.1 500
        500 http://ppa.launchpad.net/mythbuntu/32/ubuntu focal/main
amd64 Packages
        500 http://ppa.launchpad.net/mythbuntu/32/ubuntu focal/main
i386 Packages
     2:32.0+fixes.202204231836.daa4e7e447~ubuntu20.04.1 500
        500 http://ppa.launchpad.net/mythbuntu/32/ubuntu focal/main
amd64 Packages
        500 http://ppa.launchpad.net/mythbuntu/32/ubuntu focal/main
i386 Packages
 *** 2:32.0+fixes.202204210037.bfae001d5c~ubuntu20.04.1 100
        100 /var/lib/dpkg/status
     2:31.0+fixes.20200323.9579662cdc-0ubuntu1 500
        500 http://us.archive.ubuntu.com/ubuntu focal/multiverse amd64
Packages
        500 http://us.archive.ubuntu.com/ubuntu focal/multiverse i386
Packages

See anything wrong?  Looks like it's setup is correctly; I must have
done the script manually when I rebuilt the box.

Don


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

_______________________________________________
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

On Fri, 29 Apr 2022 21:14:55 -0500, you wrote:

>deb http://ppa.launchpad.net/mythbuntu/32/ubuntu focal main

That is what you want, and you are getting v32-fixes packages, so it
is all good.
_______________________________________________
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

On Fri, Apr 29 2022, Stephen Worthington <stephen_agent@jsw.gen.nz> wrote:

> On Thu, 28 Apr 2022 06:13:42 -0500, you wrote:
>
>>That's a good tip, but it may not be needed. I have the same
>>mythtv-backend.service file as the OP in that thread and I have never
>>had an issue with my hdhr tuner being marked as unavailable.
>
> Until it happens. It is a race condition - it is likely that there is
> something in your system that makes mythbackend start late enough that
> networking is up. Most of the time. But with race conditions,
> eventually something happens that changes the timing, and then
> mythbackend starts earlier and the tuner is not found. Things that
> affect the timing fairly drastically are fscks being run on partitions
> at startup, which will happen from time to time if you are using ext
> format partitions, or if you have a power failure and the partitions
> are still marked as dirty on the next boot. Or some random program
> that used to hold things up for a while gets a new version that makes
> it work faster. Or a new version of systemd gets installed that runs
> something in parallel that used to run in sequence. Or you upgrade to
> Ubuntu 22.04 LTS and the timings have changed and you always get
> mythbackend starting too early. That is the nature of race conditions
> - some systems will see the problem on almost every boot, and others
> will not see it except maybe once in the lifetime of the system.
>
> So, have you ever had a problem where mythbackend did not seem to be
> working and you restarted it and then it was working? That is the
> characteristic pattern that you see with this race condition - it only
> happens at boot, so a restart of mythbackend even a few seconds after
> boot will never have it happen.

As I wrote, I have never had such problems.

>
> It really is always better to actually fix race conditions by making
> things happen in the required order, rather than just rely on "its
> working, so why bother?". Unfixed race conditions will usually bite
> you at some time and it often happens when it will cause real problems
> for you, like when you are trying to work out some hardware problem
> and the race condition also pop up and fools you into thinking that a
> bit of hardware is faulty so you buy a new one that you really did not
> need to.

Yes, the good is the enemy of the best.

TBH, what you are describing sounds like a bug in the systemd service
file that ships with mythbackend. Have you filed a bug report with a
suggested patch (I checked on launchpad, and I don't see anything
there)?

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