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

Mark Spieth mark at digivation.com.au
Tue Dec 29 23:09:01 UTC 2009


On 30/12/2009 8:52 AM, David Engel wrote:
> 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.
>    
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.
> 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.
>    
problem is that cardid is unique as generated and is different for each 
cardinputid.
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.

mark

-- 
Mark Spieth, PhD
Digivation Pty Ltd
9 Catalina Ave
ASHBURTON VIC 3147
Australia
Phone: +61 4 11 515 717 (0411515717)
Fax: +61 3 9885 5774



More information about the mythtv-dev mailing list