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

[Roger James]

On 03/02/13 21:22, Roger James wrote:
> 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
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-dev
I have opened a ticket for this

<http://code.mythtv.org/trac/ticket/11399>

and attached a patch to it. It seems to be working OK.

Roger

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-dev/attachments/20130205/6e9fa7f7/attachment.html>