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

[David Engel]

On Wed, Dec 30, 2009 at 07:51:54AM +1100, Mark Spieth wrote:
> however, it should still be ok for these cases where inputs belong
> to multiple groups as the sched will/(should) find a matching input
> group and boost priority, but without extensive knowledge on all
> these, I cant be sure.

The problem is this will cause the scheduler to have to consider
multiple instances of a program on the same input at the same time.
Fox example, say program P in on at 20:00 on input 3 and input 3
belongs to inputgroups 5 and 6.  This will cause the BUQ to generate
the following candidate showings after the join on inputgroup is
added.

title     starttime     cardinputid    inputgroupid
  P         20:00            3              5
  P         20:00            3              6

Before, there would have only been one candidate generated for input
3.  IOW, an extra candidate will be generated for every extra
inputgroup an input belongs to.

Now, the scheduler *probably* will do the right thing if given data
like this.  We actually did this on purpose a long time ago when we
tried one approach for (dare I say it) soft padding.  As I recall,
there were some corner cases (among other things) that didn't work so
well and caused us to abandon the whole approach.  I would not be
surprised if some of the same problems crept up again.  Either way,
I'd rather keep the current scheduler assumption that there is only
one candidate per title-chanid-starttime-input tuple.

Something just occurred to me.  You're mainly interested in the
inputgroup use case tied to multirec, right?  Why don't you just use a
negative preferred inputid to prefer the cardid with that absolute
value?  The way we do things now, there will never be any ambiguity
with the other use cases for inputgroups and the cardid is already
available so there won't need to be any new joins to create additional
candidates.

David
-- 
David Engel
david at istwok.net