[mythtv-users] scheduler confusion

[blind Pete]

On Fri, 05 Sep 2014 11:59:39 -0400
"Michael T. Dean" <mtdean at thirdcontact.com> wrote:

> On 09/05/2014 11:15 AM, Mark Perkins wrote:
> > From: Michael T. Dean
> >> On 09/05/2014 08:25 AM, Michael T. Dean wrote:
> >>> On 09/05/2014 07:52 AM, Mark Perkins wrote:
> >>>> To be honest I don't think the ordering is causing your problem,
> >>>> but the recommendation is that if all the tuners are equally
> >>>> functional then that should be reflected in the order priority.
> >>> Though not all having the same value.  If you have 4 physical
> >>> capture devices, all equally functional and equivalent to one
> >>> another, you should set them up as having schedule orders of 1,
> >>> 2, 3, and 4.  Then, you would likely choose Live TV order of 4,
> >>> 3, 2, 1 to ensure you take the
> >>> least-likely-to-be-chosen-for-recordings device first when you
> >>> enter Live TV (so it's also the least likely to be already locked
> >>> to a mux).
> >> Oh, and BTW, this is exactly how MythTV will configure your system
> >> by default.  If it's not already this way, I highly recommend you
> >> "Delete all capture cards" (not "Delete all capture cards
> >> on<hostname>") and re-create them to ensure they're fixed properly
> >> so you don't:
> >>> Choosing exactly the same schedule order value for the different
> >>> physical devices may break multirec placement efficiency.
> >> break multirec.
> > Mike, this appears to be the opposite answer to what you gave me
> > when I went through this exact issue earlier this year. In
> > particular you said:
> >
> > MythTV, in absence of instruction to do otherwise, will always
> > schedule recordings on the first-available input that can be used
> > for that recording. So, if it's doing otherwise, you've told it to
> > do otherwise.
> 
> Yes, so when it puts a recording from mux 1 on physical device
> 1/virtual tuner 1 and a recording from mux 2 on physical device
> 2/virtual tuner 4 and it tries to place another recording from mux 1,
> it will do so on physical device 1/virtual tuner 2, which means it
> shares the same physical tuner and maximized multirec efficiency.
> 
> The only time this is "broken" is when you have a so many concurrent
> recordings on a given mux that at least one of them spills over to
> another physical device (say you now have devices 1 and 3 recording
> from mux 1) and the recording on the "later" (= higher scheduling
> order, in this example device 3) device has a longer run time than
> all of the recordings on the earlier device (device 1).  At the point
> the final recording on device 1 finishes, device 3 is being used for
> mux 1, but if a new recording from mux 1 starts when device 1 (and 2)
> is not being used for recording from other mux'es, it will start the
> new recording on device 1, so you'll still have devices 1 and 3 used
> for the same mux until the recording on device 3 finishes.  In other
> words, you'll need both a spill over (more concurrent recordings on a
> given mux than virtual tuners on the physical device) /and/ the
> latest-ending recording must be placed on the higher-schedule-order
> device /and/ a new recording from the same mux must start before that
> (latest-ending) recording on the higher-schedule-order device
> ends /and/ at least one lower-schedule-order devices must be
> unoccupied/not-in-use-for-a-recording-on-a-different-mux at the time.
> 
> This is enough of a corner case that it's really not worth trying to
> "fix"--especially as there are nearly as many ways that assigning the
> new recording to the later-schedule-order device will break other
> future recordings as there are ways that the above issue will
> actually break recordings (where "break," here, tends to mean "cause
> conflicts").

At this stage all sorts of interesting algorithms come to mind, 
but I must admit some of them would be a right royal pain to 
implement. 

> > There was another thread where you detailed that unless tuners
> > otherwise had shortcomings or limitations they should have the same
> > priority, but too tired to try and find it at the moment.
> 
> Input (tuner/card) Priority is /very/ different from Schedule Order
> and Live TV Order.  Order should increment for each physical device,
> in the order in which you want devices to be used (lowest used first)
> and applies to both recordings (Schedule Order) and Live TV (Live TV
> Order).  Priority affects whether a recording (and only a
> recording--it has no effect on Live TV) from that input is better or
> worse than a recording from another input--and with priority, higher
> is "more preferred" (meaning higher is generally used first).  So,
> they have completely different purposes, and their values have
> opposite effects.  And, input priority will actually break multirec
> placement efficiency--therefore, all inputs should have the same
> priority unless they have shortcomings or other limitations compared
> to other inputs.
> 
> Unfortunately, confusing Priority and Order is actually a /very/
> common mistake among users.  We (I?) just haven't been emphasizing
> the difference enough since Order was introduced.  People are still
> thinking as they did in the days of Anarchy--when there was only
> Priority (the time before David Engel introduced Order to MythTV :).

Touche.  

> Please help spread the word since I've been shirking my duties on
> list.
> 
> Mike

This might be a user interface problem.  There are technical well 
defined terms that coders must get right that look sufficiently 
similar that ordinary users will misuse them.  

Might I suggest that the word "priority" should be hidden from 
the ordinary user.  The GUI could ask, "which tuner works best?".  
Then offer a choice of; "they all work for all channels" <default>, 
"the best tuner is <name or number one>" <the HD tuner>
"the worst tuner is <>" <the pay per view card?>
"it is complicated"

If best or worst is selected, repeat the question with 
a truncated list.  

If "it is complicated" is selected, offer a link to the wiki.  

-- 
testing
bP