[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