[mythtv-users] scheduler confusion

[blind Pete]

On Wed, 3 Sep 2014 14:33:15 +1000
Mark Perkins <perkins1724 at hotmail.com> wrote:

> Here is what my cardinput table looks like (I essentially have an
> extra tuner that is pseudo 'reserved' (or more accurately
> prioritised) for livetv): 
> mysql> select cardinputid, cardid, schedorder, livetvorder from
> mysql> cardinput;
> +-------------+--------+------------+-------------+
> | cardinputid | cardid | schedorder | livetvorder |
> +-------------+--------+------------+-------------+
> |           1 |      1 |          1 |           5 |
> |           2 |      2 |          1 |           5 |
> |           3 |      3 |          1 |           5 |
> |           4 |      4 |          1 |           5 |
> |           5 |      5 |          1 |           5 |
> |           6 |      6 |          1 |           5 |
> |           7 |      7 |          1 |           5 |
> |           8 |      8 |          1 |           5 |
> |           9 |      9 |          1 |           5 |
> |          10 |     10 |          1 |           5 |
> |          11 |     11 |          1 |           5 |
> |          12 |     12 |          1 |           5 |
> |          13 |     13 |          1 |           5 |
> |          14 |     14 |          1 |           5 |
> |          15 |     15 |          1 |           5 |
> |          16 |     16 |          1 |           5 |
> |          17 |     17 |          1 |           5 |
> |          18 |     18 |          1 |           5 |
> |          19 |     19 |          1 |           5 |
> |          20 |     20 |          1 |           5 |
> |          21 |     21 |          1 |           5 |
> |          22 |     22 |          1 |           5 |
> |          23 |     23 |          1 |           5 |
> |          24 |     24 |          1 |           5 |
> |          25 |     25 |          1 |           5 |
> |          26 |     26 |          5 |           1 |
> |          27 |     27 |          5 |           1 |
> |          28 |     28 |          5 |           1 |
> |          29 |     29 |          5 |           1 |
> |          30 |     30 |          5 |           1 |
> +-------------+--------+------------+-------------+
> 30 rows in set (0.00 sec)

I am not sure that that is default, approved, or necessary; 
but if it works use it.  

> I have 6 physical tuners each with 5 virtual tuners.

One physical tuner for each multiplex?  If that can not be made 
to work then something is seriously wrong.  

> The order of the tuners is of relevance to how you can end up with
> two recordings from the same multiplex being on different tuners at
> the same time. Schedule a recording (R1) from 9-10am on multiplex A
> (MA). It gets tuner 1 because it is the first available tuner of the
> highest available priority. Then schedule a second recording (R2)
> from 9:30-10:30am on multiplex B (MB). It gets tuner 6 because tuners
> 1-5 are occupied with R1 (tuner 1 is recording it, 2-5 are locked out
> to channels on multiplex A (MA) only). Now schedule a third recording
> (R3) on multiplex B (MB) for 10:15-11:15am. Ideally it should go on
> tuner 7 because tuners 6-10 are already occupied with MB and R1 from
> MA has finished. However the first available tuner is actually tuner
> 1. So from 10:15am onward two physical tuners are occupied with
> recordings from a single multiplex even though a single physical
> tuner could handle both recordings. 

This is the heart of the problem.  

I was assuming that the scheduler should be smarter than I am.  
Finding an example where I can easily do better was a surprise, 
finding that there was no obvious way to tell it to do things 
my was a disappointment.  In the scheduler's defence, many 
systems do not seem to have multirec capabilities, so this is a 
complete non-problem to them, and we are only looking at one aspect 
of the problem.  Things can get insanely complex when there are 
different types of tuners, fixed antennas pointing in different 
directions, bandwidth limitations, and costs. 

Restricting ourselves to identical multirec tuners there are 
many possibilities, some a bit kludgy, some will be impractical 
for reasons that I don't understand.  For those cases, sorry 
about wasting the bandwidth, but I enjoy turning over algorithms. 

*)  Run a two pass scheduler, on the second pass note that 
    R1 and R3 are on the same multiplex but different tuners 
    *with the same recpriority* then call for a shuffle; 
    either move R1 or R2 and R3.  Coder's get to choose.  

*)  Alternate the direction of the scheduler processing.  
    In the above example pass two would allocate R3 
    first, then R2, then R1.  The example above would 
    be solved by this.  

*)  When a conflict is found (or the user is just being a 
    busybody) allow user intervention to move a recording 
    to tuner <n>, or a button labeled, "try the other
    algorithm".  The other algorithm might be as simple 
    as a random shuffle for the current block of time between 
    instants when all tuners are idle, or even "doing it 
    backwards".  

*)  Add a user definable name to the dtv_multiplex table 
    so that simple Custom Priority Rules like, 
    "cardinput.displayname = 'abc' AND 
     dtv_multiplex.displayname = 'abc'"
    become sensible.  

    Less obvious variations of this are already possible.  

*)  Explicitly allow each multiplex to have its own 
    non-system wide rec-order.  
   
*)  Lock a tuner to a multiplex.  Good for rich people 
    who can afford one tuner per multiplex.  

*)  Lock a sub-channel to a tuner.  Good for very rich 
    people who don't like thinking.  

-- 
testing
bP