[mythtv] Input switching question

[Bruce Markey]

Jerry Rubinow wrote:
> On 2/15/06, David Engel <gigem at comcast.net> wrote:
>> On Wed, Feb 15, 2006 at 12:37:56PM -0800, Bruce Markey wrote:

>>> Card Type input inputid source  InputGroup
>>>
>>> 1    bttv coax      1   cable        A
>>> 2    ivtv coax      2   cable        B
>>> 2    ivtv s-video   3   STB-cable    B
>>> 3    DVB  DVB       4   DVB          C
>>> 3    DVB  DVB       5   DVB          D
>>> 4    HD   HD        6   STB-firewire B
>>   5    DVB  coax      7   cable QAM    E
>>   6    v4l  coax      8   cable        E
>>   6    v4l  s-video   9   STB-cable    E
>>
>> Cards 5 and 6 are physically the same card.  It is split into two
>> virtual cards because Myth doesn't support multiple types for the same
>> card.  IG E is used to make sure that only 1 of inputs 7, 8 or 9 can
>> be used at a time.
>>
>> IMHO, the hardest part of all of this is the local/remote encoder link
>> changes that would be needed.  Currently, when a recording is started,
>> the scheduler fires off a command to that card to stop whatever you
>> are doing and start recording this.  With IG changes, the "stop
>> whatever you are doing" would no longer only cross inputs on the same
>> card, it could inputs on different cards and even cards in different
>> backends.

> Why is that?  If the scheduler wants to start recording on (in the
> above example) card 2 ivtv s-video, in IG B, it can only do so if the
> other inputs in IG B (ivtv coax and HD) are already not busy, right? 

You've skipped over the step of how they came to be not busy. If there
is a recording scheduled for card 2/input 3/STB-cable for 7:00 and at
6:58 you are watching live on card 4/input 6/STB-firewire it has to
tell you in the next minute that you can watch with it records, go to
the menu, or cancel the recording because at 7:00, the channel is going
to change for the device that lead to you creating a group B.

> If they're not busy, the scheduler only needs to send the "stop
> whatever you're doing" to the particular input it wants to use.  If
> the other inputs in the IG are busy, it wouldn't be sending the signal
> in the first place.

The show at 7:00 was scheduled days or weeks ago. You started channel
surfing a few minutes ago. The station broadcasting the video going
through card 4 is about to change without card 4's consent.

> What am I missing (I'm assuming there's something)?

Possibly many things ;-) but for starters, signaling that live will
need to stop for a recording and a current recording on any IG B that
ends at 7 (i.e. 6:30-7:00 on card 4) can't use overrecordseconds because
the "card" (or now InputGroup) needs to fire off another recording at 7.

The question also misses the bigger picture. We already can deal with
mutually exclusive inputs on the same card. Nothing new here. I think
David's point is that now we make an encoder link to one card to tell
it that it has to stop the 6:30-7:00 recording on any input because the
card has to start a new recording at 7. Maybe a different input, maybe
the same. What he is pointing out is that now he has to send encoder
link messages to more than one card as in his 5 and 6 or your 2 and 4.
This would be new.

--  bjm