<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 02/05/2016 17:21, Hika van den Hoven wrote:<br>
    <blockquote cite="mid:17110599682.20160502182140@gmail.com"
      type="cite">
      <pre wrap="">Hoi Hika,

Monday, May 2, 2016, 6:10:45 PM, you wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="">Hoi Damian,
</pre>
      </blockquote>
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">Monday, May 2, 2016, 6:02:40 PM, you wrote:
</pre>
      </blockquote>
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">On 02/05/2016 15:42, Hika van den Hoven wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">Hoi Vincent,

Monday, May 2, 2016, 3:52:16 PM, you wrote:

</pre>
            <blockquote type="cite">
              <pre wrap="">On Mon, May 02, 2016 at 12:18:02AM +0100, Damian wrote:
</pre>
              <blockquote type="cite">
                <pre wrap="">I have tried manually stopping and restarting the backend, and that didn't
fix things.

</pre>
                <blockquote type="cite">
                  <pre wrap="">Posting the output of
   initctl list
should help clarify the situation
</pre>
                </blockquote>
                <pre wrap="">Here you go ...

$ initctl list
indicator-application stop/waiting
unicast-local-avahi stop/waiting
update-notifier-crash stop/waiting
upstart-udev-bridge start/running, process 1438
update-notifier-hp-firmware stop/waiting
xsession-init stop/waiting
dbus start/running, process 1444
no-pinentry-gnome3 stop/waiting
update-notifier-cds stop/waiting
gnome-keyring-ssh stop/waiting
ssh-agent stop/waiting
upstart-dbus-session-bridge start/running, process 1493
gpg-agent start/running
indicator-messages stop/waiting
logrotate stop/waiting
im-config start/running
session-migration stop/waiting
upstart-dbus-system-bridge start/running, process 1491
at-spi2-registryd stop/waiting
startxfce4 start/running, process 1532
update-notifier-release stop/waiting
indicator-sound stop/waiting
upstart-file-bridge start/running, process 1501
gnome-keyring stop/waiting
re-exec stop/waiting
upstart-event-bridge stop/waiting

Any problems/clues there?
</pre>
              </blockquote>
              <pre wrap="">  
I was flummoxed by this - no mention of myth or mysql in the output.
But clearly they are starting up.
Then I remembered you are on 16.04 - is it using systemd as the
init system? You can tell if 'sudo which systemctl'
returns e.g. /usr/sbin/systemctl or /sbin/systemctl.
What I was trying to do here was get an idea of the relative order
in which things are being started up. That's turning out to be tricky
so we probably should not get distracted by the issue, but we may have
to come back to it.
Cheers
Vince
PS
If you do have systemd installed you might be able to use it to
get some information about the startup ordering, with
   $ sudo systemd-analyze critical-chain mythbackend.service
   $ sudo systemd-analyze critical-chain mysql.service
see also [1] and [2]. I am not sure these commands will work,
maybe others can supply the correct incantations.
</pre>
            </blockquote>
            <pre wrap="">I keep have the feeling that still backends are running on your
frontends a slave backend running without any tuner could give these
weird results.
What does:

pgrep -l myth

report? Or if you do not have pgrep:

ps -A | grep myth


results
</pre>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">Hi Hika,
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">On the frontend machines, those commands return no results. Just goes to
a new line in the terminal as though I had just pressed enter with no 
command at all.
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">On the backend, I get ...
$ pgrep -l myth
2145 mythbackend
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">$ ps -A | grep myth
  2145 ?        00:40:32 mythbackend
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">Is that useful?
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">Thanks,
Damian
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">YES, there is a (slave)mythbackend running on that machine! So if
there is no tuner configured for that backend, it will keep
complaining and the master too, slowing everything down.
So you have to stop it and make sure it won't start again.
Unfortunatly I do not know the systemd syntax for that, but it will be
similar as you used to stop the frontend.
</pre>
      </blockquote>
      <pre wrap="">
Except of cause when you ran it on your backend machine. The it is OK
;-)

That command shows all running services containing myth in their name.

</pre>
      <blockquote type="cite">
        <pre wrap="">Tot mails,
  Hika                            <a class="moz-txt-link-freetext" href="mailto:hikavdh@gmail.com">mailto:hikavdh@gmail.com</a></pre>
      </blockquote>
    </blockquote>
    <br>
    It's fixed! (hopefully)
    <br>
    <br>
    I went back into the backend setup as I remembered that changing the
    entry in that IPv6 box changed things last time.
    <br>
    <br>
    A few things have changed since then, so I wanted to go back in and
    see if changing the IPv6 setting would change things again. I
    assumed that it would make things worse, but knew that I cut put
    things back if needed.
    <br>
    <br>
    I was surprised to find that there were 3 options for the IPv6
    setting (see <a class="moz-txt-link-freetext"
href="https://www.dropbox.com/s/twcih9pkd2sp4to/2016-05-02%2017_11_44-gingerserver_0%20-%20TigerVNC.png?dl=0">https://www.dropbox.com/s/twcih9pkd2sp4to/2016-05-02%2017_11_44-gingerserver_0%20-%20TigerVNC.png?dl=0</a>).
    <br>
    <br>
    The one that worked was the default, "::1".
    <br>
    <br>
    That wasn't working before, but obviously the changes we have made
    have altered things so that it can work!
    <br>
    <br>
    I've now had the 2 remote frontends playing different media and
    grabbing meta-data for the last 15 minutes or so. All seems to be
    fine!!
    <br>
    <br>
    Thanks for the help everyone. I'd be lots without you lot!! <span
      class="moz-smiley-s1" title=":-)"></span>
    <br>
    <br>
    Thanks again,
    <br>
    Damian
    <br>
  </body>
</html>