[mythtv] [mythtv-commits] Ticket #1319: scheduler is sometimes recording wrong program

[Michael T. Dean]

On 03/07/06 20:43, henri wrote:

>i'm assuming that doing a grep for:
>
>grep "DELETE FROM recordmatch WHERE recordid = -1" /var/log/mythbackend.log
>
>should correctly show when that is being called with recordid = -1
>
>should Scheduler::UpdateMatches(-1) be called after each
>mythfilldatabase run? 
>

mfdb calls ScheduledRecording::signalChange(-1);

>my logs only show it being called when i run 
>
>mythbackend --resched 
>
>or do something else manually
>

or restart the backend

>, and not on a daily basis after
>mythfilldatabase is run (from a cron job, not via mythfrontend)
>  
>

That's basically where I had gotten when I was trying to track it down 
and that's why in the post I linked to above (which I had re-titled to 
match your ticket's title) I said it's a temporary condition that can be 
corrected by forcing the scheduler to run.  I've seen it happen when a 
matching program was replaced by mfdb with a non-matching program 
(which, unfortunately/fortunately doesn't happen that often for 
me--twice so far, and once I caught it and re-ran the scheduler to fix it).

Since mfdb doesn't seem to re-run the scheduler properly, if nothing 
else causes the scheduler to run before the program starttime, Myth 
records the show that's there now.  Unfortunately, I can't figure out 
why the reschedule is not happening because the code in filldata.cpp 
looks good.  I will say, though, that the last change to the code 
section that requests the reschedule was [8025] ( 
http://svn.mythtv.org/trac/changeset/8025 --from Nov 23), which reverted 
the change to that section in  [7973] ( 
http://svn.mythtv.org/trac/changeset/7973 --from Nov 21).

It's possible the issue may have been corrected by David Engel's 
scheduler connection changes ( http://svn.mythtv.org/trac/changeset/9233 
and http://svn.mythtv.org/trac/changeset/9243 ), but if so, I'm 
surprised I was ever affected since I'm running MySQL 4.0.18.  Are you 
by any chance running MySQL 5.x and SVN > 9243 or -fixes SVN > 9266?  If 
so, have you seen the problem since updating your Myth?

Mike