<div class="gmail_quote">On Sun, Jun 3, 2012 at 6:32 AM, Michael T. Dean <span dir="ltr">&lt;<a href="mailto:mtdean@thirdcontact.com" target="_blank">mtdean@thirdcontact.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="HOEnZb"><div class="h5">On 06/03/2012 01:14 AM, Michael Wareman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Maybe I&#39;m missing something or have been doing something wrong - but<br>
updated to the latest -fixes (0.25.0+fixes.20120601.<u></u>77394f0)<br>
from 0.25.0+fixes.20120528.d3a5b0a and have noticed that many-many more<br>
programs are scheduled to record - all really old. Things like years old<br>
MythBusters episodes - despite the Custom Record rule having &#39;New Episode&#39;<br>
set on the schedule filter.<br>
<br>
My understanding of this filter (with reference to<br>
<a href="http://www.mythtv.org/docs/mythtv-HOWTO-12.html" target="_blank">http://www.mythtv.org/docs/<u></u>mythtv-HOWTO-12.html</a>) is &#39;One of the duplicate<br>
matching options is &quot;Record new episodes only&quot;. If this is selected,<br>
listing that have an original air date of more than 14 days earlier are<br>
considered repeats and are not eligible to record.&#39;<br>
<br>
My &#39;Search Phrase&#39; is:<br>
program.title = &#39;MythBusters&#39; AND program.hdtv&gt;  0 AND<br>
program.previouslyshown = 0<br>
<br>
I have the schedule filter &#39;New Episode&#39; set - so only episodes with an<br>
&#39;Original Airdate&#39; within the last two weeks should be scheduled. Certainly<br>
- until the recent -fixes update that seemed to be the case. Yet much older<br>
episodes are now showing up to be recorded. Not just for this one rule<br>
either - but all my rules. My backend has suddenly become really busy<br>
recording old episodes I don&#39;t want to be recorded.<br>
<br>
Adding &#39; and datediff(curdate(),program.<u></u>originalairdate)&lt;  14&#39; to the<br>
search phrase seems to solve this for the time being - but I&#39;m trying to<br>
figure out what changed and if it was intentional (ie: am I going to have<br>
to add this phrase to all my recording rules?).<br>
<br>
Has anyone else noticed unexpected recordings being scheduled recently?<br>
</blockquote>
<br></div></div>
Almost definitely mythfilldatabase breakage.  Please provide a mythfilldatabase log.  (I&#39;m guessing your mythfilldatabase is taking ludicrously long time to run--due to having barriers enabled on your file system with MySQL data files--and is getting killed before it finishes.)<br>


<br>
Mike<br>
______________________________<u></u>_________________<br></blockquote><div><br></div><div>Well, my Kernel is 3.2.0-24-generic-pae and filesystem EXT4 - and the specs say that &#39;Barriers&#39; are enabled by default. However - mythfilldatabase is completing normally. It&#39;s taking no longer than usual to complete (1-2 mins per run). My understanding of barriers (although limited) is that it&#39;s a performance bottleneck only. Is there any reason other than file system performance to turn it off?</div>

<div><br></div><div>The last background run of mythfilldatabase (from /var/log/mythtv/mythfilldatabase.log) is at <a href="http://pastebin.com/Ys5URNv2">http://pastebin.com/Ys5URNv2</a>. I don&#39;t see anything odd or unusual about the run.</div>

<div><br></div><div>A fresh interactive run of mythfilldatabase is available at <a href="http://pastebin.com/ewJU7TUE">http://pastebin.com/ewJU7TUE</a>. Again - nothing odd or unusual here.</div><div><br></div><div>However - you are probably onto something. The Jun 2nd run did have SQL errors in it - and a significant delayduring the run of the grabber. mythfilldatabase still appeared to complete (ie: wasn&#39;t killed) - but I can see how there may have been issues after this run. <a href="http://pastebin.com/1MHU5LX1">http://pastebin.com/1MHU5LX1</a></div>

<div><br></div><div>It seems a mythfilldatabase -dd-refresh-all cleared the issue up for me.</div><div><br></div><div>Mike - thanks for the pointer - helped tremendously pining it down.</div><div><br></div><div>Michael.</div>

<div><br></div><div><br></div></div>