[mythtv-users] scheduling a regular recording in a timeslot

[Bruce Markey]

Michael T. Dean wrote:
> On 07/06/2006 06:29 PM, Eyal Lebedinsky wrote:
...
>> Thanks everyone. One thing not clear in the doco is: when is the search
>> (what a rule is) done? With every housekeeping?
>>   
> 
> With every run of the scheduler against that rule (including when the 
> scheduler is run against all rules).  This can be triggered by 
> "mythbackend --resched", or by creating a rule using the 
> frontend/MythWeb, or ...
> 
> In short, it's done when it needs to be done.

Good question and good answer.

The scheduler can be thought of as having two phases; "match" to
find all the showings in the 'program' table that match the criteria
of the rules, then "place" where the showings that need to be recorded
are placed in the schedule while the status is determined for all the
showings that are not going to be recorded. One of the optimizations
that David Engel added later after the new scheduler went in is the
ability to keep the "match" results for the future scheduler runs so
that these queries don't have to be run every time. If a rule hasn't
changed and the listing haven't changed, the same showings will match
that rule the next time the scheduler is run.

So, when the master backend starts, it finds all the matches for all
the rules and stores them in the 'recordmatch' table then does the
placement phase. If you add a new rule or change an existing rule, it
only updates the matches for that one rule in the 'recordmatch' table
then goes on the placement. It only need to do all matching from scratch
when the MBE starts, when mythfilldatabase runs and updates the listings
or when a --resched is sent (this should be done when the listings are
manually updated).

grep match mb.log | grep -v sch

2006-07-06 01:27:44.193 Scheduled 307 items in 2.1 = 0.03 match + 2.07 place
2006-07-06 02:10:12.221 Scheduled 307 items in 1.9 = 0.05 match + 1.88 place
2006-07-06 04:00:27.465 Scheduled 304 items in 2.7 = 0.01 match + 2.73 place
2006-07-06 06:17:42.839 Scheduled 334 items in 6.4 = 5.39 match + 1.05 place
2006-07-06 07:08:08.721 Scheduled 334 items in 3.1 = 0.00 match + 3.13 place
2006-07-06 07:15:25.610 Scheduled 332 items in 1.0 = 0.01 match + 0.94 place
2006-07-06 08:59:25.228 Scheduled 331 items in 0.9 = 0.00 match + 0.92 place

Mfdb finished at 06:17AM when the number of matches jumped from 304 to
334. The scheduler had to query 49 kPowerSearch rules of 95 total which
took 5.39 (not bad considering how abusive some of these are =). Once it
found all the matches, the match phase only takes a couple hundredths of
a second for the rest of the day.

--  bjm