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

[Glen Hawksworth]

On Sat, 2009-02-07 at 21:35 -0500, Michael T. Dean wrote:

> 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

Cheers Mike,
Will let you know how I go.
PS: spent the weekend figuring out the IR and LCD on my Antec Fusion
Case (imon 0038 version) instead. IR working beautifully LCD worked once
and now just says "thanks for using LCDproc and Linux!". Once I get it
going I'll do a write up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20090208/f1a82d3a/attachment.htm>