[mythtv-users] scheduler confusion

[blind Pete]

On Fri, 08 Aug 2014 06:21:38 +1200
Stephen Worthington <stephen_agent at jsw.gen.nz> wrote:

> 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.

Looks like we have the same problem.  

What is you output from (MySQL):

select cardinputid, cardid, schedorder, livetvorder from cardinput;

> 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:

It might have been you that I was more or less copying, but we are
treating symptoms rather than causes.  

> 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.

I need a stronger placebo.  

My priority boosts were much too small.  

-- 
testing
bP