<!DOCTYPE html><html><head><style type="text/css">body { font-family:'DejaVu Sans'; font-size:13px}</style></head><body><div>On Sat, 02 Feb 2013 13:32:07 +0000, Roger James wrote:<br> <br>&gt; 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>&gt;  <br>&gt; 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 &gt; | sequence of events is as follows.<br>&gt; <br>&gt; 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>&gt; 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>&gt; seconds queue a scheduler MATCH 0 0 0 request.<br>&gt;  <br>&gt; 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>&gt; statuschanged to true.<br> &gt;&nbsp;<br>&gt; 3. When the scheduler calls HandleIdleShutdown the fact that statuschanged is true will cause the shutdown timer to be reset!<br> &gt;&nbsp;<br>&gt; 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>&gt; irrelevant to any recording schedules.<br> &gt;<br>&gt; Please can anyone confirm this!<br> &gt;<br>&gt; I can see two possible ways to fix this.<br> &gt;<br>&gt; 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>&gt; best way to go about it as mixes a lot of scheduling functionality into the scanner.<br> &gt;<br>&gt; 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 &amp; 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&nbsp;<a 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></body></html>