[mythtv] Ticket #7818: allow preffered input group forscheduling

[David Engel]

On Wed, Dec 30, 2009 at 10:09:01AM +1100, Mark Spieth wrote:
> On 30/12/2009 8:52 AM, David Engel wrote:
> >3.  IOW, an extra candidate will be generated for every extra
> >inputgroup an input belongs to.
> so what is needed is a limit = 1 on the join perhaps.
> or a distinct on title, starttime, cardinputid.
> but that may exclude the priority gained if the wrong one is selected.
> perhaps a join condition on the inputpref test too. unless that
> would break everything if it doesnt match.
> my sql is a bit poor on complex queries. and this is way more
> complex than I expected.

Please see the message I just sent before checking for new replies
from you.  My SQL is nothing to write home about either, but I *think*
the key is to use a LEFT JOIN and a very restrictive condition.

> problem is that cardid is unique as generated and is different for
> each cardinputid.

Yes, I realized that myself shortly after sending that message.

> In fact it puzzles me why cardid and cardinputid is needed, unless
> its for the analog/digital cases which I haven't seen.
> Thus cardid is not like a inputgroup. each cardinput is effectively
> separate and distinct in the multirec case.

cardid/cardinputid is a hold over from days gone by, but it is still
used for analog cards.  For example, many (most?) analog cards support
tuner, s-video and composite inputs, but only one can be used at a
time.  To handle this, the scheduler considers all inputs with the
same cardid as implicily belonging to the same input group.  That
could probably be done completely with inputgroups now, but the
configuration would be tedious.

David
-- 
David Engel
david at istwok.net