[mythtv] Scheduler needs table keys?

[Chris Pinkham]

* On Sun Jan 28, 2007 at 07:21:23PM -0800, Bruce Markey wrote:
> 2007-01-28 17:39:20.600 Scheduled 249 items in 1.2 = 0.01 match + 1.19 place
> 2007-01-28 17:40:54.279 Scheduled 249 items in 1.2 = 0.01 match + 1.19 place
> 
> The match times are negligible unless there is a full resched.
> 
> : bjm at nordtv ; mythbackend --resched
> ...
> 2007-01-28 18:28:08.892 Scheduled 249 items in 9.6 = 8.18 match + 1.40 place

I don't see anything like this on my production or dev systems.

My production system (for some reason) normally takes only 13-14
seconds to run the scheduler.  Most of the time the match time is 0,
but occasionally it goes up to between 1 and 2 seconds, and once in
the past week it went up to almost 3 seconds.  This is a sample of 147
reschedules over the 1 week period since I restarted my production
backend.  I've never seen it reverse like you're showing.  I just
ran the backend on my dev box and then ran a --resched from the command
line and the match and place values stayed almost exactly the same as
they were in the original scheduler run when I started the backend.
I deleted a recording to trigger a resched and the numbers were again
almost identical.

> But again, this only matter during at the end of mfdb while you
> are asleep. I think what makes more difference during the day
> is "place" while the schedule is being filled in from the pre-
> identified matching showings. Here I like to keep my reclist
> short so there are fewer items to weed through to when placing.

I ran "egrep -i 'mythfill|match'" on my production backend log file
and there is only one time when my match column is non-zero other
than the initial startup scheduler run and the mythfilldatabase
triggered runs.  All other times, my match time is 0.

So, even with my production 'record' table with mostly kAllRecord
entries, I spend most of my time in place not in match.

Here's the "grep match" results from my slave as I just reproduced
the "all -> channel" and "channel -> timeslot" changes that I tested
previously.

2007-01-28 23:22:54.744 Scheduled 754 items in 16.6 = 0.76 match + 15.81 place
2007-01-28 23:23:15.709 Scheduled 569 items in 12.8 = 0.23 match + 12.55 place
2007-01-28 23:23:35.700 Scheduled 213 items in 5.7 = 0.20 match + 5.55 place

Between each I ran a "mythbackend --resched" so these were full reschedules.
Your match time must be related to the power rules you have.  I only have
a few.

> You also mentioned the size of your oldrecorded table. It is

> I record SportsCenter anywhere from 365 to 366 times per year
> but no matter how slow of a sports day it is, they never show
> old reruns. I can "Remove all episodes for this title" for
> SportsCenter and anything like it and do so frequently. Same

I see, something I had never considered.  I guess I do have a whole
bunch of old kruft in there that I'll never need again.  Makes me
wonder if there should be a new menu item on the popup when you delete
a scheduled recording that would allow you to delete the schedule and
the history together.

For reference, I just started with a new copy of my production record
table and the only thing I did was truncate the oldrecorded table.
The scheduler run time was cut in half:

2007-01-28 23:34:45.908 Scheduled 754 items in 16.4 = 0.74 match + 15.66 place
2007-01-28 23:35:07.078 Scheduled 754 items in 8.2 = 0.78 match + 7.41 place

So for people with large histories, that data alone can cause as much
scheduler run time as using kAllRecord vs kChannelRecord does.

> be repeated and you still record, plus movies or specials that
> might match search rules. I usually have my table trimmed down
> to a few hundred lines.

Another item to put on my production TODO list. :)

--
Chris