[mythtv] [mythtv-dev] Active EIT scanner and idle shutdown of backend

[Roger James]

On 03/02/13 20:24, Roger Siddons wrote:
> On Sat, 02 Feb 2013 13:32:07 +0000, Roger James wrote:
>
> > A couple of years I disabled all active EIT scanning as that was the 
> only way I could get my backend to to idle shutdown. This was even 
> after | the fix for ticket #3597 was applied.
> >
> > I recently turned it back on again to see if things had changed in 
> fixes-0.26. They have not. I still cannot get my backend to shut down. 
> The > | sequence of events is as follows.
> >
> > 1. The eit scanner finds some events. These can be for any program 
> new or old whether or not there is a recording schedule for it. This
> > means that here in UK DVB-T land the scanner will pretty much 
> continually find new events. The scanner will then at least every 60
> > seconds queue a scheduler MATCH 0 0 0 request.
> >
> > 2. The scheduler will find a MATCH request in its queue and because 
> HandleRequest will always return true for a match request it will set
> > statuschanged to true.
> >
> > 3. When the scheduler calls HandleIdleShutdown the fact that 
> statuschanged is true will cause the shutdown timer to be reset!
> >
> > I cannot see how the patch in #3297 can ever have worked if the 
> scanner continues to find events even though those events may be
> > irrelevant to any recording schedules.
> >
> > Please can anyone confirm this!
> >
> > I can see two possible ways to fix this.
> >
> > 1. Stop the scanner requesting a reschedule if none of the events in 
> its queue relate to active recordings schedules. I do not think this 
> is the
> > best way to go about it as mixes a lot of scheduling functionality 
> into the scanner.
> >
> > 2. Change the scheduler logic to only return statuschanged if 
> recording schedules have actually been changed.
>
>
> I've never had a problem with EIT & shutdown personally, probably 
> because I use a 30 sec idle shutdown timeout.
>
> However, I know that Lawrence Rust has a patch that addresses this 
> already.
>
> See mythtv-0.26/0055 in 
> http://www.softsystem.co.uk/download/mythtv/mythpatches-0.24.tar.bz2
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-dev
Yes a 30 second timeout would probably fix it!

For information my comment about HandleIdleShutdown reacting to 
statuschanged is incorrect. It is actually checked in Scheduler::Run and 
the idle time reset before HandleIdleShutdown is called.

I have looked at code further and dug out a copy of the DVB spec, As far 
as I can see the handling of EIT table version numbers is very broken in 
eitcache.cpp. This causes a massive number of unnecessary reschedules. I 
have worked out a patch to address this, but at the moment this does not 
do anything special for valid reschedules being caused by version 
changes to the "now next" EIT table which can be quite frequent. For 
"now" changes we can probably check against active recordings to see if 
they can be ignored. "Next" changes are much more problematic.

I will leave this running for a while. Hopefully the reschedules should 
quieten down enough overnight to allow the backend to shutdown.

Roger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-dev/attachments/20130203/ab71548f/attachment.html>