[mythtv-users] BE3 - Issues with installation and database
Barry Martin
barry3martin at gmail.com
Mon May 27 17:59:06 UTC 2019
Hi Stephen!
OK, there are three problems I can see in the pastebin log. Two are
minor and one is fatal.
The two minor ones are:
1) If you are wanting to use a remote with the frontend on this PC,
you do not have LIRC working yet, so the remote will not work.
Yes: will have several remote Frontends
2) Mythfrontend is unable to find the exact font it wants (Droid Sans)
and is making do by loading an alternative font (DejaVu Sans). This
means that some of the screen text may not look as good as it should.
It is a very minor problem.
At this point more important to get Backend-3 working, communicating
with the Frontends. Nice font is later.
3) Mythfrontend is unable to connect to mythbackend. That is fatal,
but I suspect it is an easy fix - did you start mythbackend after you
ran mythtv-setup? It was failing before due to the timezones problem
with the database, so it will have retried a number of times and then
stopped for good. If you did not restart it manually after applying
the timezone fix, then it will not be running. So either rebooting,
or manually restarting mythbackend:
sudo systemctl restart mythtv-backend
should fix that.
System was off overnight, sopowered onthis morning.
BE2 (old) Ethernet unplugged (for ‘safety’)
BE3 (one we’re working on) plugged into the network.
Did Bill’s link correction; at this point Host is configured for
localhost (from yesterday’s messages).
*sudo systemctl status mythtv-backend* indicates the backend service
is running so skipping the restart step.
However, it is now time to do the fix to only start mythbackend after
the network connection is up. I have now tested this on my system and
the following procedure should work. There are two files on my web
server to download:
sudo su
cd /usr/local/bin
wget -chttp://www.jsw.gen.nz/mythtv/wait-until-pingable.py
chown root:root wait-until-pingable.py
chmod u=rwx,g=r,o=r wait-until-pingable.py
cd /etc/systemd/system
wget -chttp://www.jsw.gen.nz/mythtv/local-network-pingable.service
chown root:root local-network-pingable.service
chmod u=rwx,g=r,o=r local-network-pingable.service
So far so good – copy to a thumbdrive, sneakernet, and then copying
from that makes things a heck of a lot easier (and accurate!)
Now test wait-until-pingable.py - find the IP address or DNS name of
something on your network that is pingable and will always be
available. If your Ethernet switch is pingable, that is the best
option, otherwise your router is usually pingable. Do this command
from the root prompt you were using above, as wait-until-pingable.py
only works from root:
wait-until-pingable.py <IP address> 5; echo $?
Using the gatemway…. returned a 0 :)
That will return immediately and display a 0 result if the ping
succeeds. If the ping fails, it will timeout after 5 seconds and
display a non-zero result.
If your switch and router do not respond to pings, and you do not have
anything else on your network that does, you may need to use an
external address (such as google.com) as the ping address. That is
not as good as a local address because it will not work when your
Internet connection is down, so booting BE3 at such a time will cause
mythbackend's startup to be delayed by a long timeout. Here is the
contents of the local-network-pingable.service file that you now need
to edit. This is where the long timeout is:
[Unit]
Description=Wait for the local network to be pingable
After=network.target
[Service]
Type=simple
ExecStartPre=/bin/bash -c "/usr/local/bin/wait-until-pingable.py
switch.jsw.gen.nz 30"
ExecStart=/bin/true
[Install]
WantedBy=multi-user.target
Note that the ExecStartPre line is all one line up to the second "
character. My email system displays it wrapped, and yours may or may
not also do that. You need to edit that file (using nano or your
favourite editor). This needs to be done from the root prompt:
nano local-network-pingable.service
In the ExecStartPre line, replace "switch.jsw.gen.nz" with the IP
address or DNS name that you have tested above. You can also change
the 30 in that line to whatever timeout (in seconds) you want to wait
for that address to be pingable. A value of 30 seconds should work
for most systems, but you may be able to use a smaller value. I would
not set it to less than 10 seconds.
It did come though wrapped here – text/message; the file itself
didn’t wrap, of course. Changed to my gateway’s IP of 192.168.0.1
(like people couldn’t figure that one out from BE3’s static address!)
Leaving at 30 seconds; only problem I can foresee is if everything
is powered up from a power failure the gateway takes closer to a
minute before reconnects to DSL. I’m thinking different from the
gateway being up.
Exit from nano (Ctrl-X) and save the changes. Then run this:
systemctl enable local-network-pingable.service
systemctl start local-network-pingable.service
1. (enable) “created symlink:, etc.
2. (start) immediate to prompt.
So now systemd has a unit that tells it when the local network is
available and pingable. You can check to see if it is working using:
systemctl status local-network-pingable.service
This is what I get:
? local-network-pingable.service - Wait for the local network to be
pingable
Loaded: loaded (/etc/systemd/system/local-network-pingable.service;
enabled; vendor preset: enabled)
Active: inactive (dead) since Sun 2019-05-26 01:02:00 NZST; 1 day
21h ago
Main PID: 2197 (code=exited, status=0/SUCCESS)
May 26 01:01:59 mypvr systemd[1]: Starting Wait for the local network
to be pingable...
May 26 01:02:00 mypvr /wait-until-pingable.py[1861]: Starting
May 26 01:02:00 mypvr /wait-until-pingable.py[1861]: ping of
switch.jsw.gen.nz succeeded
May 26 01:02:00 mypvr /wait-until-pingable.py[1861]: Exiting
May 26 01:02:00 mypvr systemd[1]: Started Wait for the local network
to be pingable.
If it worked, it should say:
code=exited, status=0/SUCCESS
If the "status=" value is non-zero, the ping failed.
Slightly different but I think is OK:
root at Backend-3:/etc/systemd/system# systemctl status
local-network-pingable.service
● local-network-pingable.service - Wait for the local network to be
pingable
Loaded: loaded (/etc/systemd/system/local-network-pingable.service;
enabled; vendor preset: enabled)
Active: inactive (dead) since Mon 2019-05-27 11:55:24 CDT; 3min 1s ago
Process: 3111 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Process: 3110 ExecStartPre=/bin/bash -c
/usr/local/bin/wait-until-pingable.py 192.168.0.1 30 (code=exited,
status=0/SUCCESS)
Main PID: 3111 (code=exited, status=0/SUCCESS)
May 27 11:55:24 Backend-3 systemd[1]: Starting Wait for the local
network to be pingable...
May 27 11:55:24 Backend-3 /wait-until-pingable.py[3110]: Starting
May 27 11:55:24 Backend-3 /wait-until-pingable.py[3110]: ping of
192.168.0.1 succeeded
May 27 11:55:24 Backend-3 /wait-until-pingable.py[3110]: Exiting
May 27 11:55:24 Backend-3 systemd[1]: Started Wait for the local
network to be pingable.
root at Backend-3:/etc/systemd/system#
Now you need to create a systemd override file to make systemd only
attempt to start mythbackend once that new unit has started. Do this
command from the root prompt:
systemctl edit mythtv-backend
That should put you in nano (or whatever is the default editor on your
system) editing a temporary file. Copy and paste these three lines
into that file:
[Unit]
Wants=local-network-pingable.service
After=local-network-pingable.service
Save the file and exit from the editor. Systemd will then put the
file in the right location
(//etc/systemd/system/mythtv-backend.service.d//) and set its ownership
and permissions correctly.
What the override file does is to add the above lines to the config
for mythtv-backend.service, which is the systemd unit that controls
the running of mythbackend. The new config is stored in a different
place from the default config, so when a new version of the MythTV
packages gets installed, it will not be lost. A "Wants=" line tells
systemd that the unit with that line wants to use the named service,
so systemd knows to start that service before it tries to start the
service with the "Wants=" line. The "After=" line tells systemd that
the unit with the "After=" line is only to be started after the named
unit has started. Both lines are needed - "After=" does not
automatically imply "Wants=", so if you do a "After=" without a
"Wants=", and no other unit has a "Wants=" for the wanted unit, it
will never be started, and this unit will hang waiting for it to
start.
Then run this command:
systemctl daemon-reload
OK – exits back to the prompt after a split-second pause.
That tells systemd that you have changed one of its config files and
it should re-read them all to find the changes. You can now close the
root prompt:
exit
Now when you reboot, mythbackend will only be started once the
Ethernet interface is up and the address specified has responded to a
ping, or after a long timeout if the ping fails. That ensures that
the 192.168.0.3 address is up and working before mythbackend is
started, so mythbackend can bind it and be available for connections
from frontends on other PCs.
OK: *sudo shutdown -r now*
Ah! *mythfrontend* goes to a usable frontend set of menus! <cartwheels>
Now the thing is do I need to change the 127.0.0.1 on the Backend to
192.168.0.3, or will a Frontend see Backend-3 by directing to
192.168.0.3? (Don’t have an available FE right now.)
Can the media (guess the database, though not sure if that means the
‘record this’ instructions’ or also the actual shows) be copied over
to the new system (BE2 → BE3). The old Backend is 0.28 and the new
is 30. If a hassle isn’t a problem to use two systems like we have
been. I’d rather not tempt fate!
So a HUGE thank you to you and Bill for getting me to this point. No
idea what happened to screw things up so badly but thanks both for
being patient.
Barry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20190527/81cb55ac/attachment.html>
More information about the mythtv-users
mailing list