[mythtv-users] Scheduling issue?

[Michael Wareman]

On Sun, Jun 3, 2012 at 6:32 AM, Michael T. Dean <mtdean at thirdcontact.com>wrote:

> On 06/03/2012 01:14 AM, Michael Wareman wrote:
>
>> Maybe I'm missing something or have been doing something wrong - but
>> updated to the latest -fixes (0.25.0+fixes.20120601.**77394f0)
>> from 0.25.0+fixes.20120528.d3a5b0a and have noticed that many-many more
>> programs are scheduled to record - all really old. Things like years old
>> MythBusters episodes - despite the Custom Record rule having 'New Episode'
>> set on the schedule filter.
>>
>> My understanding of this filter (with reference to
>> http://www.mythtv.org/docs/**mythtv-HOWTO-12.html<http://www.mythtv.org/docs/mythtv-HOWTO-12.html>)
>> is 'One of the duplicate
>> matching options is "Record new episodes only". If this is selected,
>> listing that have an original air date of more than 14 days earlier are
>> considered repeats and are not eligible to record.'
>>
>> My 'Search Phrase' is:
>> program.title = 'MythBusters' AND program.hdtv>  0 AND
>> program.previouslyshown = 0
>>
>> I have the schedule filter 'New Episode' set - so only episodes with an
>> 'Original Airdate' within the last two weeks should be scheduled.
>> Certainly
>> - until the recent -fixes update that seemed to be the case. Yet much
>> older
>> episodes are now showing up to be recorded. Not just for this one rule
>> either - but all my rules. My backend has suddenly become really busy
>> recording old episodes I don't want to be recorded.
>>
>> Adding ' and datediff(curdate(),program.**originalairdate)<  14' to the
>> search phrase seems to solve this for the time being - but I'm trying to
>> figure out what changed and if it was intentional (ie: am I going to have
>> to add this phrase to all my recording rules?).
>>
>> Has anyone else noticed unexpected recordings being scheduled recently?
>>
>
> Almost definitely mythfilldatabase breakage.  Please provide a
> mythfilldatabase log.  (I'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.)
>
> Mike
> ______________________________**_________________
>

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

The last background run of mythfilldatabase (from
/var/log/mythtv/mythfilldatabase.log) is at http://pastebin.com/Ys5URNv2. I
don't see anything odd or unusual about the run.

A fresh interactive run of mythfilldatabase is available at
http://pastebin.com/ewJU7TUE. Again - nothing odd or unusual here.

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't killed) - but I can
see how there may have been issues after this run.
http://pastebin.com/1MHU5LX1

It seems a mythfilldatabase -dd-refresh-all cleared the issue up for me.

Mike - thanks for the pointer - helped tremendously pining it down.

Michael.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20120603/aeaa6f1d/attachment.html>