On Sun, 2 Aug 2020 00:10:28 +0000 (UTC), you wrote: >With a little extra time at home due to COVID-19, I decided to modify the abandoned Mythbuntu Control Centre application and create Mythbuntu Control Panel. For users who are new to MythTV/Ubuntu and those who prefer to not use the command line, MCP can be used to install MythTV and configure the system. I have tested it with Ubuntu and Xubuntu 18.04 and 20.04.??
>YouTube video without advertising:
>Would some of the gurus on the mailing list want to help improve MCP? I set up a Mythbuntu Control Panel team on Launchpad, and it would be great if there could be more people on the team. Please let me know or use the "Join the team" link at https://launchpad.net/~mythcp. Would some folks familiar with Python want to be a collaborator with write access to the GitHub repository? If so, please email your GitHub username to me, and I will verify your status and send you an invite.??
It is great to see MCP resurrecting all the useful things MCC used to
do for us. >One of the items that could possibly be improved is having the backend wait for the network to be up before starting when the user has other frontends on the network.? The current MCP version currently adds the systemd override.conf file shown below. There is currently a sleep delay in addition to waiting for network-online.target, but it is only five seconds.? Could this programmatically be improved?
Race conditions like this are a well known problem. Equally well
known by those people who get to fix them is that any attempted fix
using a delay is going to fail at some point when something happens to
change the timing. The proper fix for a race condition is to actually
wait for the correct status that is required, not to just delay and
hope. And the proper fix will normally start things up faster than a
So the proper fix for mythbackend is to wait until the network is
actually up. The way I do that is to ping something on my local
network. Getting a ping reply guarantees the network connection is
working. The downside of this fix is that you have to have the user
specify the IP address or DNS name of something on their local network
that is pingable at boot time. If they are using HDHR tuners, they
are pingable and using one of them is a good idea. Other network
tuners may or may not be pingable. In the absence of HDHRs, the
Internet router is often pingable, as are higher specification
Ethernet switches (ones with management interfaces, so the switch
itself has an IP address). I am set up to ping my switch. Here are
the instructions I post for how to do my fix: ====================================================================
The fix is a bit complicated - you have to make a systemd unit that
tests for the Ethernet interface actually being up and able to pass
traffic, and then have mythbackend wait on that unit before it is
started. The tools to do this are on my web server. If you are not
running a server version of Ubuntu and have not disabled
NetworkManager, run the following commands to set it all up. Watch
out for line wrapping - my email client does that with longer lines
such as the wget commands, so the wget and the URL after it should be
on one line.
chmod u=rwx,g=r,o=r wait-until-pingable.py
systemctl enable NetworkManager-wait-online.service
systemctl start NetworkManager-wait-online.service
chmod u=rwx,g=rx,o=rx mythtv-backend.service.d
chmod u=rw,g=r,o=r mythtv-backend-wait-until-pingable.conf
chmod u=rw,g=r,o=r local-network-pingable.service
Here you will need to change the text in
local-network-pingable.service where it says "switch.jsw.gen.nz" and
replace that with the IP address or DNS name of your first network
tuner (if the tuner is pingable), or otherwise something on your
network such as your switch or router that is normally pingable when
your MythTV box is booting.
Use nano or your favourite editor:
Then save the change and exit from nano or your editor and do these
systemctl enable local-network-pingable.service
systemctl start local-network-pingable.service
systemctl status local-network-pingable.service
The systemctl status command should show that the
local-network-pingable.service has started and the ping worked. If
not, fix that before proceeding. Then do these commands:
After that, on boot mythbackend will wait for either the ping to work,
or the 30 second timeout specified in the
local-network-pingable.service file. If you want to change that
timeout, it is the "30" after the ping address. ====================================================================
You might also like to consider doing the mythbackend stopping fix.
All MythTV programs use the same codebase and all have the same bug -
when they are stopped from the outside (usually by a "kill -15"
command, or just "kill"), they shut down except for one thread which
remains running waiting for something. A second "kill -15" stops this
remaining thread and the shutdown will complete normally. Mythbackend
has this bug, so when systemd requests it to stop by doing a "kill
-15", the remaining thread remains running until a systemd timer
expires (90 seconds by default), after which systemd does a "kill -9"
and that finally gets rid of the remnant of mythbackend. Since
everything was actually tidily shut down by then, there are no adverse
consequences from the "kill -9", except for the very long delay before
it happens. The delay adds 90 seconds to the shutdown or reboot time
for the system, which feels like an eternity when you are waiting for
it to happen, and there is no need for it. My fix is to tell systemd
to use a small script to shut down mythbackend. It sends two kill -15
signals one second apart. You can install it from my web server:
chown root:root mythbackendstop.sh
chmod u=rwx,g=rx,o=rx mythbackendstop.sh
Then in a systemd override file you add this line in the [service]
It is also a good idea to put these two lines in the [service] section
as well, as a backup in case mythbackend is locked up and really needs
a kill -9:
That will cause systemd to do a kill -9 after 10 seconds if
mythbackend still does not shut down.
From the point of view of MCP, I would suggest that either MCP create
two separate, appropriately named, systemd override files for these
fixes, or maybe just one with a name telling us that MCP created it.
Having comments in those override files describing what they are for
would be a good idea.
mythtv-users mailing list
email@example.com http://lists.mythtv.org/mailman/listinfo/mythtv-users http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org