bjm at lvcm
Feb 12, 2005, 10:22 PM
Post #19 of 21
(1528 views)
Permalink
|
Anduin Withers wrote:
>>I think I need to reiterate some of the goals from when the scheduler
>>was written. I thought these were made pretty clear then and are
>>captured in the documentation Bruce has written.
>
>
> I try to read most of -dev, still it takes a bit of digging and derivation
> to arrive at how the scheduler works even with the documentation. Especially
> regarding behavior that some of us may have foolishly become accustomed to.
Anduin, please sit back, take a deep breath and chill out.
Nothing here is quite so terrible as you seem to want to
make it sound.
You asked the question "why". David asked if you used the option
that is there for these situations and I tried to explain what
was happening in response to your asking why. I'm in favor
of postponing things so that something else can get recorded.
You may have confused my explianing what had happened and why
with something you need to argue against.
>>First, above all else, the behavior must be deterministic. The
>>scheduler is run many times and the results can't change just because
>>something comes out of the database in a different order.
>
>
> How many times do I have to hear deterministic before someone realizes that
> what I want (and what was there, at least in this aspect) isn't
> non-deterministic?
I believe three times but this response suggest that you still
may not have gotten the drift of why it is being said. Everyone
understands what you are saying and no one has said that it
would be non-deterministic.
Everything has to be placed in the schedule serially. They can't
be dropped in at the same time in parallel even if they have
the same proirity value. One show has to be placed first, the
second one next and so on. They could be sorted by time or
preference or something else but one grabs a spot then the next
then the next. Even though you gave Monk and BSG and NUMB3RS the
same value, they can't all get card number 2. Even though they
are all zero, one of them gets the next spot in line after the
things that were priority 1 or higher.
Monk won. And, every time the scheduler ran since you last touched
any of these rules and since the listings last changed. Monk has
won every time and has always been assigned to card 2. Every time.
That's the deterministic part.
When Monk is placed, both card 2 and 3 are available. There is no
reason to anticipate that there will be two or more shows coming
along later for that same time. Therefore there is no reason for
it to choose midnight instead. Who knows, midnight just might
turn out to be a bigger problem. 10 o'clock, card 2 is the best
choice so far.
Now what's unusual in your example is that NUMB3RS came up last
in the sorted list but NUMB3RS doesn't have another showing. If
things had been different so that Monk came up last, it would
have immediately chosen the midnight showing, but it wasn't and
NUMB3RS lost instead.
Now, you know this isn't the best result and I know it and David
knows it and Isaac knows it but you're so caught up in trying to
say that you're right that you didn't notice that no one is saying
that you're wrong.
I think what you've overlooked in the explainations is that
the scheduler can't know that there is a conflict until it
places things and sees that there are too many for a given time.
After it finds that NUMB3RS can't fit then it needs to go back
and check if it could move BSG or Monk. It can't 'know' that Monk
has to move until after there are four things found for the three
cards.
In my schedule, I've never had a problem with this kind of situation
because I've never run a day without SMH turned on. To me, the
less than 1% chance that I might miss a higher ranked show is
outweighed by the 100% chance that it won't record a lower, oh,
'sorted preference list' show that doesn't have another showing.
To me, it's a no brainer. Turn on SMH and leave it on. If a
situation comes up where you really want the first showing
more than a lower ranked show, it will be clearly marked "L"ater
Showing and you can easily override.
> In this case some of the rules are simply applied too soon. My issue was
> with the order of operation not with your design goals.
No matter how you decide which item is placed first, you won't know
which ones will result in a conflict until after they have all been
compared. And only then can you figure out if one or more could move
to allow room to record something that can't move.
>>Now, that all being said, I think the SchedMoveHigher behavior can be
>>extended to automatically apply to programs of equal priority without
>>violating the above goals. The attached patch attempts to do this for
>>anyone who wants to test it.
>
>
> I think you've done a good job with the scheduler, this is the only case
> I've encountered where I disliked what it did by default.
I'll agree that I don't like what it does by default and therefore
have never used the default other than testing.
>>To anyone unsatisfied with this, they're
>>welcome to submit patches or write their own scheduler.
>
>
> If the expected result of raising an issue is a thread like this one, I
> imagine something like that will be the only satisfactory path remaining. I
> don't want to write a scheduler (mostly I don't want to maintain one, and
> put up with people like me poking at it), I don't want to break your
> scheduler, I also don't want you and Mr. Markey to act like I insulted your
I think you may have misread the responses. You asked 'why does
this happen' and the response was 'here is why this happened' and
'here is the option that exists specifically for solving this exact
problem'.
-- bjm
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
|
schedequal.patch
