[mythtv] Re: Scheduler behavior, why?

[Anduin Withers]

> 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