[mythtv-users] scheduler confusion

[Stephen Worthington]

On Thu, 7 Aug 2014 09:58:07 +0100, you wrote:

>blind Pete <0123peter at gmail.com> wrote:
>
>> There are three physical dvb-t tuners on two cards, each is configured 
>> for five virtual tuners.  15 total.
>
>First question: Do these all get the same multiplexes, or do different cards get different muxes ? It is VERY important as it has a major effect on how things need to be set up.
>
>> selectclause: (channel.callsign LIKE 'SBS%' OR channel.callsign = 'NITV') AND cardinput.cardid = 'sbs'
>...
>> selectclause: (channel.callsign NOT LIKE ('SBS%') AND channel.callsign <>  'NITV' ) AND  cardinput.cardinputid <> 'sbs'
>
>AFAIK you should rarely, if ever, have to specify cards/inputs in your recording rules. Normally you simply tell the system *WHAT* you want recording and it works out *WHERE* it can be recorded. If you have multiple tuners that get the same set of channels/muxes then you define these as one source with one set of channels and let the system decide which tuner to use. If the physical tuners get different muxes/channels (eg using different antennae pointing at different transmitters) then you need to define them as separate inputs with different channel lineups - but the system still decides for itself which tuner to use.

But, as the devs have told us, the scheduler is not perfect.  It can
and does make mistakes in certain situations.  Here in New Zealand up
until a few months ago, we had only three multiplexes transmitting.  I
have three DVB-T tuners in my box, so there should not have been any
way for any programs to not be recorded.  But the scheduler did
sometimes manage to assign two different physical tuners to the same
multiplex at the same time, despite there being enough multirec tuners
that it could have used the same physical tuner.  And then it ran out
of physical tuners when I needed to record from all three multiplexes
simultaneously.

The solution suggested by one of the devs was to use the powerpriority
table as the OP is doing.  Here is what I am using:

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)     |
+----------------------+-------------+-------------------------------------------------------+

What that does is to give programs from each of the three main
multiplexes a priority boost when they are assigned to a specific
physical tuner.  That overcomes the scheduler's problem and makes it
use the same tuner for the same multiplex.  Now that we have a fourth
multiplex, it would use any tuner not already in use, but as I never
record from any of its channels yet I have not seen how well that
would work in combination with the above settings.  The basic idea
with the above settings is that all channels on the same multiplex (ie
with the same channel.mplexid value) should be assigned to the same
physical tuner.  The "cardinputid in {<set of numbers>)" specifies all
the multirec tuners for one physical tuner.

Where there are more multiplexes than physical tuners, a more complex
set of rules could be used to give say recpriority 60 for a multiplex
on one specific tuner, and another rule that only gave a recpriority
of 40 for the same multiplex when on another specific tuner.  The
difference between the recpriority values should be large enough so
that any other priority boosts a program got for any reason would not
add up to more than the difference in the powerpriority rules, so that
all programs for that multiplex would go to the tuner with the
greatest recpriority value that was not already assigned to another
multiplex by a higher recpriority rule.  You would have to decide on
an order of priorities for the use of physical tuners versus
multiplexes, but as long as there are not too many more multiplexes
than tuners it should be possible to make a set of rules that will
overcome the scheduler's problem.

However, I would not be surprised to find that adding more
powerpriority rules caused the scheduler to run significantly slower.