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 [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
