[mythtv-users] Recording starts soon, AUTO-Startup assumed (no it doesn't!)

Graeme Wilford gwilford at gmail.com
Sat Nov 11 19:47:14 UTC 2006


On 11/11/06, David Watkins <watkinshome at gmail.com> wrote:
> On 09/11/06, Graeme Wilford <gwilford at gmail.com> wrote:
> > On 09/11/06, Graeme Wilford <gwilford at gmail.com> wrote:
> > > On 09/11/06, Thorsten Sandfuchs <fux at users.berlios.de> wrote:
> > > > On Thu, Nov 09, 2006 at 04:34:09PM +0000, Graeme Wilford wrote:
> > > > > Can someone explain the schedulers idle logic to me? I've read the
> > > > > HOWTO and looked through scheduler.cpp but I'm a bit lost.
> > > > > However, since then I restarted mythbackend several times and every
> > > > > time I do, it logs
> > > > >    Recording starts soon, AUTO-Startup assumed
> > > > > despite the next recording being hours away (much longer than
> > > >
> > > > In my case the "AUTO-Startup" seems to be assumed on _every_ show mythtv
> > > > considers in my "Upcoming Recordings" even in the duplicates and the reruns
> > > > and not, as I'd expect it only in the "scheduled recordings".  I think this is
> > > > a bug. Although mythtv shuts down the system, if the corresponding time of
> > > > such a rerun did occure and the recording actually doesn't start.
> > >
> > > I think you might be right. Although the scheduled recording was hours
> > > away, there were non-recording duplicates and 'T' disabled recordings
> > > within idleWaitForRecordingTime.
> > >
> > > > > Does a minimum amount of time have to pass before mythbackend even
> > > > > begins to consider itself idle? Also, why does it think that a
> > > > > recording starts soon when in fact it's many hours away and
> > > > > idleWaitForRecordingTime is set to 60 mins?
> > > >
> > > > perhaps you have a upcomming recording in every hour?
> >
> > I just re-read your definition of upcoming recording and now I
> > understand. So Myth factors in any possible recording while it's up
> > and doesn't become 'idle' until there are no possible recordings
> > withint idleWaitForRecordingTime?
> >
> > That sounds broken and inconsistent, especially as once it finally
> > decides it's idle, it will shutdown until the next 'actual' recording
> > rather than the next 'possible' recording.
> >
> > The shutdown time is configured for actual recordings and so should
> > system idleness.
> >
> > Anyone disagree?
>
> I'm also still running 0.19 and my experience of the problem is
> slightly different.
>
> I have no problem with the system detecting that it's idle -  that
> always works.  My problem is that if I start the system with an
> upcoming recording due then the system assumes an Auto start, even if
> that recording is not scheduled to be recorded.  Then, with no front
> end connected and no recording actually about to happen, it detects
> idle and shuts down straight away.  To avoid this I need to be quick
> and manually start a front end (because I don't automatically start
> front ends for an auto start).

My patch will fix that.

There is a logical error in the idle algorithm - it factors in
'possible' recordings rather than 'actual' recordings. With my patch,
your system will startup in 'user' mode rather than 'auto' unless
there really is an actual recording scheduled in less than
idleWaitForRecordingTime mins. If you have
block-until-frontend-connects set, it will then stay up until your
frontend connects.

The reason you might not notice shutdown issues is that the bug only
really manifests if you have a high idleWaitForRecordingTime. If you
leave it at the 15min default and you don't have back-to-back
'possible' recordings, the BE will shutdown just fine. However, if
you set it to say, 1hr and you have 'possible' recordings every hour
or so, the BE will never shutdown...

My BE has been going up and down as expected and recording fine with
this patch for nearly 48hrs now. If all is well after a couple more
days, I'll put this fix in trac.

Cheers,
Wilf.
-- 
Me at google | MythTV blog: http://mezzanines.blogspot.com/


More information about the mythtv-users mailing list