[mythtv-users] MBE loses tuners in SBE until I enter & exit from Mythtv-Setup

[Michael T. Dean]

On 02/07/2009 06:38 PM, Glen Hawksworth wrote:
> I need to ensure that my slave backend connects to the master when it 
> is switched on.
...
> My best guess is that mythtv-backend is starting before the network is 
> connected because if I open and close the backend settings or run 
> "/etc/init.t/mythtv-backend restart" it successfully connects allowing 
> the MBE to see all tuner cards.
> I can propose two solutions but they both amount to the same thing:
>
>     * Somehow get the network to lock in before mythtv-backend starts
>       (preferred)
>     * have something run that restarts the backend after the network
>       is connected (probably easier)
>
> The problem with restarting the backend after the network is connected 
> is that I would be guessing and just allowing a minute or so after 
> bootup to run the script so it would be a one shot deal, hit or miss.
> The problem with getting the network to lock in before starting the 
> backend is that I have no idea how to achieve this.

For a backend, it's critical that the database be active/accessible 
before starting the backend--otherwise, the backend will attempt to 
connect to the database and will fail, so it shuts down.  If you have 
WOL configured in Myth for the DB host, it will try to wake the DB host 
WOLsqlConnectRetry times--waiting WOLsqlReconnectWaitTime after each 
attempt--before failing (those settings are specified in mysql.txt).

For a remote backend, if the DB and/or mythbackend and/or the network 
are not ready when the app is started, it may or may not quit due to the 
failure (there are too many different cases to describe, so, IMHO, it's 
best to make sure it's all ready before starting the remote mythbackend 
instance).  There are settings allowing you to configure WOL for the 
master backend in mythtv-setup.  If configured, the remote backend will 
try "Wake Attempts" times--waiting "Delay between wake attempts (secs)" 
after each attempt--before failing (assuming it didn't fail already to 
to some other part's not being ready).

A frontend attempts to connect to the master backend.  If it's not 
there, it may attempt to do UPnP autoconfiguration and/or prompt the 
user for information about the backend.  (I.e. you may get the 
Language/DB Settings prompt that you get the first time you configure 
the host.)

Therefore, for all except the master backend (remote backends and 
frontends), it makes sense to verify that the master backend is running 
before starting the app.  I use the attached script, myth_ping.pl, to 
"ping" the master backend and see if it's alive.  If so, I then start 
the app.  If not, I do a "rolling sleep" before trying to ping again.

The relevant code from my start script is:

  # See if the master backend is available
  ready=0
  count=1
  max_increment=60
  while [ $ready = 0 ]; do
    echo "Pinging MythTV master backend (try $count)..."
    myth_ping.pl > /dev/null 2>&1
    if [ $? = 0 ]; then
      ready=1
    else
      count=`expr "$count" + 1`
      if [ "${?}" != 0 ]; then
        count=$max_increment
      fi
      if [ "$count" -lt 60 ]; then
        sleep "$count"
      else
        sleep "$max_increment"
      fi
    fi
  done
  # The master backend is running/accessible, start app

Note that the above code is bash-compatible, but may not be 100% 
sh-compatible (though I've tried to make it as portable as possible, I 
may have missed some things).

The myth_ping.pl script requires the Perl bindings be installed and 
properly configured (i.e. the user running myth_ping.pl /must/ have a 
valid HOME environment variable and a valid ${HOME}/.mythtv/config.xml 
).  The script is also assumed to be in the path--if not, include full 
path information in the call in the snippet above.

The "rolling sleep" starts out sleeping 2 seconds between tries, then 3 
seconds, then 4, ... until it sleeps for 60 ($max_increment) seconds, at 
which point it continues to try again once every minute.  Note that by 
the time it gets to the once/minute tries it's already been > 30 minutes 
of trying (1829 seconds of sleep, actually).

If you'd prefer a more active solution (i.e. using WOL or whatever), 
feel free to modify as desired (or just let Myth do the WOL for you as 
described above).

I use the above in my mythfrontend start script.  In my master backend 
start script (technically, in my mythbackend start script, if it 
determines it's being executed on the master backend), I have a similar 
stanza that, instead of using myth_ping.pl, uses "mysqladmin ping" (see 
the man page for details) to verify that the DB is available.

In your remote backend start script you can either check for the master 
backend or for the database...  The master backend cannot be available 
unless the database is available, so checking for the master backend 
implicitly guarantees that the database is running (though, not 
necessarily that /this/ host/user has permissions to the DB).  Checking 
for the database means that the remote backend may start before the 
master backend--which may or may not be a problem depending on your 
configuration.  So, I'll leave it to you to decide which test to do on 
your remote backends.  :)

Mike
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: myth_ping.pl
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20090207/823845a1/attachment.txt>