[mythtv] Two scheduler queries when "Expiring Program", and two "Finished recording" messages

[Bruce Markey]

Chris Pinkham wrote:
> * On Tue Feb 27, 2007 at 08:55:49AM -0800, Robert Tsai wrote:
>> 	- Each "Expiring Program" message causes the scheduler to run
>> 	  twice, instead of once.
> 
> Haven't seen this, but then I can't recall the last time I've
> had something actually Auto-Expire.  I don't see in the code

I haven't seen it but I have an idea why this may appear to
happen.

> how this would be happening though.  The expirer just sends a
> message to the master backend which handles deleting the file
> like any normal delete.
> 
>> 	- After a recording finishes, the scheduler query is issued
>> 	  ("Scheduled Items" in DB backend log). This is not
>> 	  surprising. What is surprising is that each "Finished
>> 	  recording" message appears twice. Usually this is "Last
> 
> I've looked into this before and think I tracked it down once
> but can't recall exactly why it does it.

The finished recording message appear twice but I think that
is just the result of two verbose messages being hit along
the way. I don't think it duplicates post recording tasks.

One thing that used to happen is that there is the syslog look
alike written into the database and the '[Ss]cheduled items'
was written by VB_VERBOSE then another verbose message was
written by the logger to log that it was being written to the
log (huh?). There would be two variations of the message for
any one run.

>> Are these expected behaviors?
> 
> I don't think so.

I'll just float this but haven't verified it. Say the allow
re-record when auto-expired flag was set. When the file was
deleted from recorded a resched would need to be requested.
The oldrecorded.duplicate flag for that episode would need to
be cleared and needs a resched. Each of thees are in different
places in the code and can be (and usually are) called separately
by different operations. It's not that auto-expire is calling
resched twice consecutively per se but the course of events
require it to be properly called in two separate tasks.


I'd seen this message and didn't want to pick it apart but
here goes =). Starting from the end:

- The problem sounds like it happens on a set of events during
a single scheduler run. Trimming some runs wouldn't 'fix' the
problem.

- I find it hard to believe that an average of as many as 10
things could auto-expire per day for almost anyone. Even this
high estimate is a mean avg of once every 2 1/2 hours. Not
high impact. For me, my auto-expire average is zero per year. 

- The scheduler doesn't run twice at once. New requests during
a run are queued. This queue is optimized to throw out duplicate
work. If if the scheduler is running and there are new request
to re-match 1234 then 1234. it will only rerun once. If the
next request is for 0 (no rematching), that's thrown out as
it's covered. Next, -1 and that trumps everything and this
is the only pending request that would need to run.

- This also implies that if there are multiple runs in a short
period of time, the later run may be a request that wasn't
generated until after the earlier run was finished.

- Duplicate verbose messages may be misleading as above.

- There may be two perfectly legitimate requests from different
tasks in different parts of the code as above.

--  bjm