[mythtv-users] MBE loses tuners in SBE until I enter & exit from Mythtv-Setup
Michael T. Dean
mtdean at thirdcontact.com
Sun Feb 8 02:35:25 UTC 2009
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>
More information about the mythtv-users
mailing list