[mythtv] Input switching question

Jerry Rubinow jerrymr at gmail.com
Thu Feb 16 03:37:58 UTC 2006

On 2/15/06, Bruce Markey <bjm at lvcm.com> wrote:
> 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

Thanks Bruce, that all makes sense.  Yes, I see how those are
important considerations.  So is this a good summary of the
requirements for implementing IGs:

1.  Scheduler has to consider all inputs in an IG as a unit when
determining conflicts/placing items in the schedule.
2.  Channel changing in live tv has to know that it can't use any
input from an in-use IG.
3.  When notifying an input in an IG to stop what it's doing, the
notifier has to notify all inputs in the IG.

Anything else?  I'm not thinking about implementation until I know
what's involved (and I've had more of a chance to study the classes


More information about the mythtv-dev mailing list