[mythtv] Re:Next Scheduler Patch

Bruce Markey bjm at lvcm.com
Tue Mar 2 22:58:01 EST 2004


Mark Chou wrote:
> Bruce,
> 
> I've read your test cases quite carefully prior to any of my emails on 
> this thread, quite carefully, I might add.  I suggest you re-read what

No, you haven't. That's apparent again in a couple places
in this message.

> you wrote, preferably with no pre-conceived notions.  There are a number 
> of implicit factors, not explicitly stated, and certainly not in one 
> document.

Obviously and I agree. This is not the final user documentation.
This is just notes on how it should behave and verification that
the new scheduler handles these cases correctly.

Now, you, or anyone else, can point out how this is not a
complete document. But at what point are you going to acknowledge
that the specific gripe you are clinging to has been addressed?
A great deal of time and effort went into fixing it so it would
work exactly as you want. But have you tried it? Have you grasped
the examples to the point where you can see that the effort was
made for YOUR sake?

 Just to show how it could be interpreted differently, I'll add 
> my own comments:
> 
> =======================================================================
> Bruce Markey wrote:
> 
> Earliest showing - if a show has multiple showings, the first showing 
> should always be recorded unless (1)it loses in conflict resolution(1).
> 
> Earliest showing
> 
> Verified.
> 
> With "Reschedule Higher Priorities" turned off, a (2)higher priority(2) 
> show
> that could be postponed to a later showing will record even if a lower
> priority title will not be recorded as a result. In this example,
> Nova at 8pm is marked to record and SportsCenter marked as a conflict:
> 
> Title - Subtitle Chan ChID Day Start End S C I O N Pri
> American Idol 5 1005 24 20:00-21:00 1 2 2 0 2 1
> Nova - "Spies That Fly" 10 1010 24 20:00-21:00 1 1 1 0 1 2
> SportsCenter 30 1030 24 20:00-21:00 1 0 0 0 C 0
> Nova - "Spies That Fly" 10 1010 25 01:00-02:00 1 0 0 0 E 2
> =======================================================================
> 
> (1) Conflict resolution in the "aggregate" tuner case (taking into 
> account all available tuners), or on a specific tuner?

"loses" meaning there are no more cards available and the
result is that the state is marked "C" (rsConflict). But I
do see the ambiguity between conflict in that they are at
the same time verses conflict in that something will have to
be left unrecorded.

> (2) Higher priority?  Where does this "higher" priority come from, 
> especially when a mythtv user did not "explicitly" designate a priority?

Playing dumb is not productive. You know damn well there is
a priority field on the advanced options page with a default
of "0" and you know damn well these are my test notes and not
newbie hand holding instructions. Also, the last case shows the
basic tie breaking for things at the same priority such as
leaving things at zero.

 
>  (A "casual" reader would not know that there is an "implicit" priority

This was not written for a "casual" reader but for people
like yourself who had an ax to grind to show you that things
had been done as you had insisted.
 
> ranking based on the kind of recording, say "one-time" vs. week slot vs. 
> "any channel/any time."  A fact which David Engle made clear only a few 
> posts prior, way after you published your "test cases" a few posts after 
> this thread first started.)

You say you read it, but I guess I have to include an excerpt
again:

------8<---------8<-------


    Tie breaking

Verified.

If two shows have the same priority, the show with the more specific
record rule type is preferred. A Channel record or All record may
have other showings of the same episode where a Single record or
Weekslot may not.

Here "Nova" is Weekslot and "Idol" is Channel so "Idol" is not recorded:

Title - Subtitle                Chan ChID Day Start  End   S C I  O N Pri
Curb Your Enthusiasm - "The Sur  210 2210  24 20:00-20:30  2 1 3  0 1   1
American Idol                      5 1005  24 20:00-21:00  1 0 0  0 C   0
Nova - "Spies That Fly"           10 1010  24 20:00-21:00  1 2 2  0 2   0

With "Nova" as Weekslot and "Idol" as Single, "Idol" wins card 2:

Curb Your Enthusiasm - "The Sur  210 2210  24 20:00-20:30  2 1 3  0 1   1
American Idol                      5 1005  24 20:00-21:00  1 2 2  0 2   0
Nova - "Spies That Fly"           10 1010  24 20:00-21:00  1 0 0  0 C   0

If the priority and type match, there are further rules to assure
that the results will be deterministic.

------8<---------8<-------

David did list the entire order of decision making. Neither of
us spelled out the complete order of RecTypePriority which is
used in a few places in the code. So the order of the six record
types from most specific to least specific is:

Single
Find one
Week slot (weekly)
Time slot (daily)
Channel
All

One of the problems up through .14 is that kWeekslotRecord was
added later and was last in the list and therefore lower than
All. This has now been fixed. Weekslot now beats Timeslot, Channel
and All.


> =======================================================================
> Bruce Markey wrote:
> 
> In testing, the conditions that would result in a later showing
> occur for less than 2% of the items in even a very heavy schedule. 
> =======================================================================
> 
> Umm, perhaps in *your* testing, but certainly not in mine.  I schedule 
> quite a number of programs on PBS, and there are at least 4 distinct PBS 
> stations in my area.  Repeats for these programs are a common 
> occurrence.  This has (almost) nothing to do with with how heavily you 
> schedule recordings on myth, but rather has to do with viewing habits, 
> and prevalence of stations that happen to show repeats in your 
> geographic area.  I can tell you w/o exaggeration I need to to manually 
> override at least 70% of all my recordings, if I use the myth .14 
> scheduler logic.

That was fun to say. Now run "mythbackend --printsched" and
attach the output.

> And when the time comes when ATSC/HDTV becomes "fully supported" within 
> myth, this problem will only exacerbate.

Again, you've completely ignored all of the relevant information.

First. unlike the scheduler, from last week or earlier, the new
scheduler does, in fact, always schedule any episode for the
first showing if there is a card available. Further, you have an
option choice as to whether you want to allow a first showing to
be postponed in a case where it might allow a lower priority
show to be recorded that you might otherwise miss. Still further,
for anyone other than Mark Chou (with your Alice and Betty being
the only known identical twin myth boxes ;-) you can designate
an input preference to say that you would rather have favorite 
shows record on the higher quality card at a later time rather
a lower quality card for the first showing.

Second, the Channel Matching feature (do I need to quote that in
line too or do you think you can find it on your own ;-)
anticipates having the same station from different sources. The
example shows that if your PBS station was on HDTV and cable,
you could set it up so that the HDTV input was preferred. However,
if the HDTV input was busy with a higher priority show, it can now
fail-over to the same broadcast on an analog cable input. The old
scheduler could not do this. Therefore, this problem is not
exasperated but is greatly simplified in the new scheduler.
 
> The intent here is not to brass you off, but to reiterate the need for a 
> document that spells all this out, for everyone in mythtvland to have a 
> proper grasp of multiple tuner scheduling logic. All the usage 
> cases/scenarios documented/explored in one comprehensive document, not a 
> scatter-gun approach like we've been dong on this thread, and a prior 
> thread.

That conveniently ignores the fact that this work is in
progress and I've said so and I've said repeatedly what my
test notes are and are not.

My intent is not to brass off at you either but I am very
disappointed because a great deal of effort went into resolving
your gripes. Now that the solutions are available to you, your
tact has been to not test for yourself to see that it works as
you've demanded, play word games to cover up the fact that you
didn't pay attention the explanations written to help you understand
that your concerns were addressed, complain that you have to
continue to the old code that you know doesn't work right because
you can't risk running the pre-tested code that fixes your problems,
and continue your griping about the old behaviors which have already
been fixed and the code has been checked in. Can you see why I
might be a little testy?

--  bjm



More information about the mythtv-dev mailing list