[mythtv-users] scheduler confusion

[Stephen Worthington]

On Fri, 05 Sep 2014 11:59:39 -0400, you 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").

This explanation is how I thought it was supposed to work.  But for
me, it demonstrably did not always work like this.  I have three DVB-T
tuners with five multirec tuners each.  When I was having problems,
here in New Zealand we had only three muxes being transmitted.  So if
it actually worked as described, each mux should get one physical
tuner only (as long as there were enough multirec tuners, which was
always the case).  But until I added the suggested powerpriority rules
to fix it, in complex situations the scheduler would assign two
physical tuners to one mux, and would run out of tuners.  I was
getting situations like this at least once or twice a week.

It is possible that there was a bug that has now been fixed, as I
think this was with the initial versions of 0.27, and I have not tried
removing my powerpriority rules with the latest 0.27/fixes to see if
it still happens.  The scheduler dumps I did at the time are still on
my web site:

  http://www.jsw.gen.nz/mythtv/scheduling_problem_2013-12-5.zip

These dumps clearly show the use of two physical tuners for the same
mux when there were still available multirec tuners on the physical
tuner first assigned to the mux.

The fix was to use powerpriority rules that guide the scheduler to
assign a specific physical tuner for each mux:

mysql> select * from powerpriority;
+----------------------+-------------+-------------------------------------------------------+
| priorityname         | recpriority | selectclause                                          |
+----------------------+-------------+-------------------------------------------------------+
| TVNZ multiplex       |          20 | channel.mplexid=2 and cardinputid in (1,2,3,4,5)      |
| Mediaworks multiplex |          20 | channel.mplexid=3 and cardinputid in (11,12,13,14,15) |
| Kordia multiplex     |          20 | channel.mplexid=4 and cardinputid in (6,7,8,9,10)     |
+----------------------+-------------+-------------------------------------------------------+
3 rows in set (0.00 sec)

Note that the mplexid values above have changed due to retuning and
the adding of a fourth mux in NZ since I created those dumps.  The
mplexid values at the time of the dumps will have been 1, 2 and 3, I
believe.

See
http://www.mythtv.org/pipermail/mythtv-users/2013-December/357428.html
for the original discussion of this.  On reading it again now, it
looks like there was some further discussion after I stopped looking
at the thread when David Engel's suggested fix worked for me.