> Most likely because you misinterpreted what "Higher Priorities" > means.
Sure, possible. Though in this case all priorities are the same (though as you point out one is more specific). > This is the (understandable) point of confusion. You presume that > because you didn't specify, there is no issue of what should get > first dibs. On the contrary I fully expect there to be an issue, what I don't expect is creating artificial losers. > [stuff I understand and am fine with] > You can see that Monk could record at midnight which is why you want > to allow it to move items that may had been placed first due to the > fact that they were higher in the sorted list. SHM (schedMoveHigher) > is precisely there to allow this but the default is that it is turned > off. Yes, but my case shouldn't involve such a drastic solution. Instead of earlier start time = higher priority, the earliest time which doesn't cause a conflict should be higher (similar to how the scheduler records full versions of the program if the scheduler starts after the start time and sees a future showing). I'm prepared for losers, but I don't want to make the leap to letting the scheduler decide to record higher priority shows later to solve what I believe is broken behavior. In my case it has the opportunity to record everything but the order the record rules was added is blinding it to that fact (the order being the only thing I'm seeing that makes the less specific ones not equal). I find it hard to believe that the current behavior is being defended. I think in terms of making things deterministic for people you have to consider repeat shows in an attempt to resolve trivial conflicts. I think the order should only count if there is an insoluble conflict. After all the order record items are added isn't reasonably controllable (though I admit is should be a factor). -- Anduin Withers
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
