<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 03/02/13 20:24, Roger Siddons wrote:<br>
</div>
<blockquote cite="mid:op.wrx5mziyb49nse@archie" type="cite">
<style type="text/css">body { font-family:'DejaVu Sans'; font-size:13px}</style>
<div>On Sat, 02 Feb 2013 13:32:07 +0000, Roger James wrote:<br>
<br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> 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<br>
> 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 <br>
> seconds queue a scheduler MATCH 0 0 0 request.<br>
> <br>
> 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 <br>
> statuschanged to true.<br>
> <br>
> 3. When the scheduler calls HandleIdleShutdown the fact
that statuschanged is true will cause the shutdown timer to be
reset!<br>
> <br>
> 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 <br>
> irrelevant to any recording schedules.<br>
><br>
> Please can anyone confirm this!<br>
><br>
> I can see two possible ways to fix this.<br>
><br>
> 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 <br>
> best way to go about it as mixes a lot of scheduling
functionality into the scanner.<br>
><br>
> 2. Change the scheduler logic to only return statuschanged
if recording schedules have actually been changed.<br>
</div>
<div><br>
</div>
<div><br>
I've never had a problem with EIT & shutdown personally,
probably because I use a 30 sec idle shutdown timeout.</div>
<div><br>
However, I know that Lawrence Rust has a patch that addresses
this already.<br>
<br>
See mythtv-0.26/0055 in <a moz-do-not-send="true"
href="http://www.softsystem.co.uk/download/mythtv/mythpatches-0.24.tar.bz2">http://www.softsystem.co.uk/download/mythtv/mythpatches-0.24.tar.bz2</a><br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
mythtv-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mythtv-dev@mythtv.org">mythtv-dev@mythtv.org</a>
<a class="moz-txt-link-freetext" href="http://www.mythtv.org/mailman/listinfo/mythtv-dev">http://www.mythtv.org/mailman/listinfo/mythtv-dev</a>
</pre>
</blockquote>
Yes a 30 second timeout would probably fix it!<br>
<br>
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.<br>
<br>
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.<br>
<br>
I will leave this running for a while. Hopefully the reschedules
should quieten down enough overnight to allow the backend to
shutdown.<br>
<br>
Roger<br>
</body>
</html>