[mythtv-users] Overactive scheduler?

[Marco Quezada]

On Sat, Feb 11, 2012 at 3:49 PM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> On 02/11/2012 02:56 PM, Marco Quezada wrote:
>> On Feb 11, 2012 12:07 PM, "Michael T. Dean" wrote:
>>> Anyway, reschedules should occur:
>>>
>>> a) any time someone runs mythfilldatabase
>>> b) any time someone changes a recording rule
>>> c) any time a recording starts or finishes
>>> d) any time a recording is deleted
>>> e) every 5 minutes for EIT users
>> Well, is there a way to tell which of these events might be the one queuing
>> the scheduler? Is there a way to increase the verbosity of the log messages
>> and would that be helpful? I have tried to relate the messages with the
>> event but I don't know enough about the meaning of the messages to make
>> sense of them. I just noticed that my eit crawler timeout is set to 3600.
>> It is a big value but not sure if there is a number that marks it as
>> disabled at all.
>>> You could see if EIT is involved by checking when these "overactive
>>> scheduler" runs occur.
>> Right, well the thing is that I can't find a steady pattern. And which of
>> all the messages would be related to the eit? Is it the ANN monitor, the
>> housekeeping.... The messages don't seem to happen on a regular schedule.
>
> Well, if you don't see a "Reschedule requested..." (at least) every 5
> minutes, then EIT isn't the problem.
>
>>>> I did find this snippet in my backend log from earlier in the month
>>>> when it was still set to look for an idle time of 840 seconds. It
>>>> seems it really thought it would shut down but got interrupted:
>>>>
>>>> 2012-02-04 17:36:39.516 Seem to be woken up by USER
>>>> 2012-02-04 17:36:44.610 mythbackend: Running housekeeping thread
>>>> 2012-02-04 17:36:51.324 MainServer::ANN Playback
>>>> 2012-02-04 17:36:51.333 adding: QMHTPC-1 as a client (events: 0)
>>>> 2012-02-04 17:36:51.336 MainServer::ANN Monitor
>>>> 2012-02-04 17:36:51.353 adding: QMHTPC-1 as a client (events: 1)
>>>> 2012-02-04 17:36:59.528 I'm idle now... shutdown will occur in 840 seconds.
>>>> 2012-02-04 17:37:54.610 AutoExpire: CalcParams(): Max required Free
>>>> Space: 1.0 GB w/freq: 15 min
>>>> 2012-02-04 17:38:50.360 MainServer::ANN Playback
>>>> 2012-02-04 17:38:50.361 adding: QMHTPC-1 as a client (events: 0)
>>>> 2012-02-04 17:38:50.364 MainServer::ANN Monitor
>>>> 2012-02-04 17:38:50.365 adding: QMHTPC-1 as a client (events: 1)
>>>> 2012-02-04 17:40:37.968 MainServer::ANN Playback
>>>> 2012-02-04 17:40:37.970 adding: QMHTPC-1 as a client (events: 0)
>>>> 2012-02-04 17:40:37.972 MainServer::ANN Playback
>>>> 2012-02-04 17:40:37.973 adding: QMHTPC-1 as a client (events: 0)
>>>> 2012-02-04 17:40:37.974 MainServer::ANN Monitor
>>>> 2012-02-04 17:40:37.976 MainServer::ANN Monitor
>>> FWIW, reports suggest that MythWelcome fails to allow shutdown.
>>>
>>> http://code.mythtv.org/trac/ticket/10114
>>> http://www.gossamer-threads.com/lists/mythtv/users/496118#496118
>> I will take a look at this.  I don't remember enabling mythwelcome but
>> certainly something I can check.
>
> So this is a dedicated backend-only machine that's not running
> mythfrontend?  You've shut down mythfrontend on all other hosts, too?
> (When mythfrontend is running mythbackend will not shut down since it
> assumes that whoever is running mythfrontend is using it to play
> recordings, etc.).  That's the purpose of MythWelcome--it allows you to
> exit mythfrontend on a host when you're done using mythfrontend (but
> don't want to shut off/suspend that host) and want to allow the backend
> to shut down, while still having a nice, easy, remote-friendly way to
> restart mythfrontend with a nice GUI and one-button restart.
>
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users

Well, I guess this shows how much of a newbie I am at this... :) I've
only been using mythTv since version .23.

The good news is that the system now seems to work as expected, shuts
down when idle, wakes up to record and the scheduler does not seem to
have been the culprit although still seems overactive in my opinion.

The bad news is that I don't think I will find out what the messages
meant on my backend logs :).

The machine is a combined BE/FE. When I initially set it up I read the
ACPI Wakeup article in the wiki to get the auto shutdown to work. At a
point in the wiki there is a section that talks about "if you are
using this machine as a BE/FE and a desktop..." which explains how to
set up the backend to shutdown and has the checklogin.sh script to
keep it from closing if there is someone logged onto the machine. That
is what I had up until yesterday and it was throwing me off because
every once in a while it would indeed shut down. After this point the
wiki talks about MythWelcome but that seemed like more work to achieve
the same result so I did not use that setup.

So I checked the MythWelcome setup and implemented it yesterday and it
turns out it works very well in my case.

Now, I do in occasion use this machine to do some work and maintenance
so I don't want it to shut down on me without being warned. When I
access the machine it is usually not from the console but from a
remote ssh session. I was thinking of placing a call to mythshutdown
--lock in one of my login scripts (.bash_profile or so) in order to
keep mythwelcome from commanding the shutdown while I am on the
machine doing work. Is this appropriate and the way the lock command
is/can be used? If so, is there a way to automatically call
mythshutdown --unlock when I log out so mythwelcome can regain control
of the power-off sequence?

-Marco