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

[David Engel]

On Wed, Dec 30, 2009 at 06:29:52AM +1100, Mark Spieth wrote:
> >My gut reaction is to reject this new patch for the same reasons we didn't
> >do more in the first place -- it isn't flexible enough to justify the
> >extra complexity.  I'd much rather see effort put into making the existing
> >power priority support be made more accessible.
> 
> fair enough.
> what kind of flexibility?

At that time, I had 3 tuners/inputs, two analog and one digital.
Depending on the content, sometimes I preferred the one digital input,
but other times I preferred either analog input.  bjm's use cases were
even more complicated where he would want to prefer any input attached
to one or more backends.

> >2. The join condition on the inputgroup table in the scheduler BUQ (big
> >ugly query) is bogus.
> this info is only available AFAICT in the inputgroup table.
> how else could this be done? cache this info for all schedules and
> fuse, but this increases the complexity quite a bit.
> add inputgroup column to cardinput table? dont like this either. the
> info would then be duplicated.

Your patch adds the following line.

" INNER JOIN inputgroup ON (channel.sourceid = cardinput.sourceid) "

I can't see how that does anything useful since it doesn't match on
anything in the inputgroup table.  Are you sure didn't meand someting
like the following?

" INNER JOIN inputgroup ON (cardinput.cardinputid = inputgroup.cardinputid) "

>  >3. This is the biggie.  Inputs can belong to multiple inputgroups.  Even
> >if the join condition mentioned above is fixed, this wouldn't be handled
> >correctly.
> how is this possible? the only info for inputgroups is in the 1
> table, setup by the channel scanner.
> this functionality this purely there to associate dvb multiplex
> inputs for multirecord. thats the whole point of this functionality
> from the recorder side.
> prefer a physical device for a certain recording, say due to better
> FE performance for say UHF band. but dont care which particular
> virtual input is actually chosen. otherwise you have to make manual
> scheduling choices for this purpose.
> This functionality doesnt exist currently and would be better if it
> did (obviously).

I suppose it's possible I'm missing some magic Daniel added behind the
scenes for multirec and we're talking about completely different
"inputgroups".  I think it's more likely, however, that you don't
realize that inputgroups can be manually configured for other uses
besides multirec.  Fox example, inputgroups are used to avoid
conflicts between digital and analog inputs on the same card and to
avoid conflicts over a single STB used by both firewire and HD-PVR
inputs.

David
-- 
David Engel
david at istwok.net