[mythtv] Ongoing struggle of bug 4989

[Michael T. Dean]

On 02/03/2009 01:20 PM, Jelle De Loecker wrote:
> Good evening everyone,
>
> Some of us are still struggling with bug 4989:
> http://svn.mythtv.org/trac/ticket/4989
>
> I'm not sure what to do now, the bug has been closed because apparently
> "it's a feature request".
>
> I understand this is low priority, as it only affects a few people, but
> to call it a feature request is nearly making fun of our situation
>   

No, it's simply acknowledging that there's a perfectly usable approach
for doing what you want that requires no new code.

> To recap the problem:
>
> When multiple frontends are watching 2 channels on the same multiplex,
> and one of the frontends wants to switch to another channel on another
> multiplex, it won't be able to do so because the other frontend is
> hogging the tuner. 
>
> It never checks "Could this tuner be part of a multirec card?", it
> totally does not exist in the code.

Best approach:
http://www.gossamer-threads.com/lists/mythtv/users/342420#342420

No new code required.

There's another approach that you can use to make LiveTV work exactly as
you desire, but doing so /will/ affect your recordings (basically tells
Myth LiveTV is more important to you than recordings).

1) Disable "Avoid conflicts between LiveTV and recordings"
2) Delete all capture cards (
http://www.gossamer-threads.com/lists/mythtv/users/264034#264034 --no
need to delete video sources, but you /must/ use the approach described
in that post)
3) In mythtv-setup under "Capture cards," create new capture cards. 
While creating the new capture cards, do /not/ enable multiple
recordings from any of the cards--make sure you set "Max Recordings"
under "Recording Options" to 1 (the default is 2, IIRC).  Do this for
each capture card.
4) Connect Inputs.  Under "Input connections," add inputs in the order
of preference (with the most-preferred input (on the most-preferred
card) being added first, and the least-preferred input being added
last).  Do /not/ set an input priority on any of the cards (leave it set
to 0).  Make sure you've connected an input on each capture card.
5) Go back to "Capture cards" and, under "Recording Options", increase
the "Max Recordings" to create additional virtual tuners.  Again, go
through in the order of most-preferred to least-preferred input (the
same order you used when connecting inputs).  Note that in doing this,
you are adding new inputs whose ID's are higher than the ID of the
least-preferred tuner.  (So, if you have 3 capture cards, each one of
them has an input ID in the range 1-3.  Then, say you change "Max
Recordings" to 2 on each, now you also have an input on each in the
range of 4-6.  If you then go back through and change "Max Recordings"
to 3, you'll have inputs in the range 7-9.  Note that if you jump from 1
to 3 immediately in this step, you'll have inputs 1, 4, 5 sharing the
most-preferred (physical) input/card, 2, 6, 7 sharing the
second-most-preferred, etc., rather than 1, 4, 7 on the most-preferred,
etc.  Either approach is likely fine, but it will have an impact on
which input is used for LiveTV.)
6) Make sure there are no recordings in progress (at least we're going
to assume that for our example/description) and watch LiveTV on one
frontend.  It will grab input ID 1.
7) Watch LiveTV on another frontend.  It will grab input ID 2 (which is
on a separate physical card).  Users on either frontend can now change
to any channel while watching LiveTV.
8) Watch LiveTV on another frontend.  It will grab input ID 3.
9) Watch LiveTV on a fourth frontend.  Since in our example, there are
only 3 physical capture cards, the fourth frontend is sharing a physical
input/capture card with the LiveTV user on the first frontend. 
Therefore, the user watching LiveTV on the fourth frontend can /not/
change to a channel on a different mux unless he/she uses the NEXTCARD
binding as described above (again, we're back to the top, easy solution
of mapping a key to NEXTCARD being the preferred ;).

Note that you should ensure that you do /not/ set an input priority on
any of the inputs.  Doing so will make it do things you don't want.  If
you want to enable "Avoid conflicts between LiveTV and recordings", you
/must/ increase the number of virtual tuners by 1 on each card when
doing step 5 (but you may repeat it as often as you like to get as many
virtual tuners as desired)--i.e. no jumping from 1 to 3 immediately, and
due to some other complexities, it may or may not work as desired,
depending on your (physical) system configuration.  Note, also, that
this approach pretty much assumes that you do not have any combined
frontend/backend systems.

So, above I said that this will affect your recordings.  How so?

When MythTV goes to record a show--let's say that there are no LiveTV
sessions in progress to make the example easier to follow--it will start
to record the highest-priority show using the most-preferred
input--input ID 1.  Then, let's say that another show happens to run at
the exact same time on a different channel but that's on the same
multiplex (let's call it multiplex "A").  Myth will start to record it
on the second-most-preferred input--input ID 2.  Since you've configured
your system to make LiveTV more important than recordings (and to make
it so that no user has to push the NEXTCARD button--assuming you have as
many physical capture cards as frontends), input ID 2 is on the 2nd
physical capture card.  That means that /both/ capture card 1 and
capture card 2 are locked to a multiplex--and it's the exact same
multiplex, multiplex "A".  So, when a third show starts on some
multiplex (we'll say a different multiplex, "B") input ID 3 is used. 
Then, a fourth show starts while the first 3 shows are still in
progress, and it's on multiplex "C"--a third multiplex.  Myth can /not/
record the 4th show because all the available inputs are locked to their
mux's (i.e. inputs 1 and 2 are /both/ locked to mux "A" and input 3 is
locked to mux "B".  So, although you have 3 capture cards and could,
therefore, tune 3 multiplexes, due to a combination of recording rule
priorities and your "I love LiveTV"/"I don't want to press NEXTCARD"
configuration, you've already exhausted the 3 capture cards and are
wasting one by tuning the same mux that another was using.

It's possible you could get around this issue by configuring all your
capture cards with "Max Recordings" of say, 3, in step 3, above.  Then,
when connecting inputs in step 4, card 1 will have inputs 1, 2, 3 and
card 2 will have inputs 4, 5, 6, etc.  Then, in step 5, increase "Max
Recordings" to 4.  Then, card 1 will have inputs 1, 2, 3, and 10, card 2
will have 4, 5, 6, and 11, and card 3 will have 7, 8, 9, and 12.  Then,
check "Avoid conflicts between LiveTV and recordings," and the first
LiveTV session will use input 12, then the second LiveTV session will
use input 11, then the third input 10.  However, for recordings,
recording 1 on mux A uses input 1 (on card 1).  Recording 2 on mux A
uses input 2 (on card 1--thus, not wasting a card).  Recording 3 on mux
B uses input 4 (on card 2), recording 4 on mux C uses input 7 (on card
3), thus, you're recording from 3 different muxes with your 3
cards--none are wasted.

I haven't tested any of the above (though I helped someone on IRC
configure it using the approach described in detail without "Avoid
conflicts between LiveTV and recordings," so I know it works).  I don't
have any channels where multirec is actually useful, so I won't be
testing this.  I've already spent a /lot/ more time writing this up than
I feel LiveTV is even worth, so test things out--there should be plenty
of information here for you to figure out how things work so you can
configure it the way you want (but feel free to ask questions--ideally
on the -users list).  Likely the last approach (in the paragraph
immediately above) is the most robust for /both/ recordings and LiveTV
(and should work even if some backends are combined frontend/backend
machines).  If you try this approach, I recommend trying the last
approach.  If it works for you, please write up a page on the wiki and
direct users on the -users list (since I'm answering this on the wrong
list) to that wiki page.

I'm pretty sure the best way to get what you want is for you to
configure your system to tell Myth what you want.  I don't see any
reason why card 1 with inputs 1,2,3,10 and card 2 with inputs 4,5,6,11
and card 3 with inputs 7,8,9,12 wouldn't do everything you want it to do
with no downsides (assuming you choose the appropriate number of virtual
inputs), so please try it out and write it up for the users.

Thanks,
Mike