[mythtv-users] Live TV channel restrictions

[Andrew Herron]

On Wed, Feb 24, 2010 at 5:45 PM, Michael T. Dean <mtdean at thirdcontact.com>wrote:

> On 02/24/2010 04:46 AM, Tortise wrote:
>
>> From: "Ian Oliver"
>>
>>  Michael T. Dean wrote:
>>>
>>>> If you always want LiveTV to get a separate physical
>>>> tuner
>>>>
>>> That isn't what I want. If there is a tuner on the right mux and with a
>>> free virtual tuner, then use it. Failing that, find a free tuner and tune it
>>> to the right mux.
>>>
>>
> That's the default configuration of MythTV.  The part you're complaining
> about is that you're then "stuck" on the mux.  To fix that, enable "Browse
> all channels."
>
>
Well our experience is that to achieve what your describing above you need a
very specific tuner setup otherwise MythTV's 'standard' behaviour is exactly
as Ian and his family experience... even if you enable "Browse all
channels". Yes "Browse all channels" allows you to browse but it will not
allow you to select and tune to any channels that are not on your currently
tuned MUX.



>  Failing that, tell me I can't watch that channel. All PVRs I've met do
>>> pretty much exactly this
>>>
>>
> /me wonders just how many PVR's you've seen that support recording from X
> virtual tuners on each of Y physical capture cards
>
> I can turn your MythTV system into something just as "simple to use and
> always works like I expect" as a dual-tuner TiVo.  That's an easy problem.
>  :)


I think the point being made above is that he wants MythTV to 'manage' this
situation for him and currently it doesn't.


>
>
>  I think this "if" logic is flawed.  (I assume LiveTV needs a free
>> dedicated tuner, not a shared Tuner, it should first hunt for a free tuner.
>>  An assumption here is that the code is not setup to directly jump tuners to
>> use a tuner which is already pulling a mux, when there remain free virtual
>> tuners on the tuner.)
>>
>> I suggest a useful perspective is that LiveTV is a different beast to a
>> recording mux and they merit recognition of their differences in their
>> treatment.
>>
>> A LiveTV Tuner is ideally locked to one tuner - why - because a Live user
>> may want to choose any channel from any mux anytime.
>>
>> A Rec Tuner is distinguished by not having an enduser who is going to
>> demand the tuner change any time to any mux.
>>
>> These distinctions seem fundamental to me.
>>
>> So, from a different perspective, what is an ideal number of tuners?  That
>> depends.  The most efficient number of tuners one should ever want should be
>> {[number of mux] + [number of LiveTV viewers]}
>>
>> [number of LiveTV viewers] deserves further clarification, that is not the
>> number of frontends, rather it is the maximum number simultaneous Frontend
>> viewers likely or perhaps possible.  So in a house with 6 frontends but only
>> 3 people present 3 is likely to be enough for [number of LiveTV viewers].
>>
>> To highlight that the current mythtv setup is a problem, consider we have
>> 3 muxs here, I have 4 (multirec) tuners (T0, T1, T2 and T3) and I have
>> enabled LiveTV selecting a free Tuner.  (I forget the exact phrase)
>> Multirec recordings start at T0 and work their way up, T0, T1, T2 - and that
>> is all that's needed for all combination of recordings, so long as there is
>> no demand for channels > 5 on any mux.   A LiveTV session ("LiveTV1") is
>> opened on a frontend and mythtv selects T3.  All good.
>>
>> Now a second frontend LiveTV session ("LiveTV2") is started on a second
>> frontend - and that is when it falls apart because LiveTV2 also gets T3 -
>> and suddenly the problem is back again as one tuner dominates controlling
>> the mux and effectively limiting the channel options available to those on
>> that mux (therefore for LiveTV1 and LiveTV2).  Manually swapping Tuners
>> works for the technically savvy - mostly I find T2 is free, however mythtv
>> should really have put LiveTV2 user onto T2, assuming it to be free, which
>> mostly it will be.  I've not tested a 5th tuner however I expect the
>> situation would be the same, LiveTV1 gets T4 as would LiveTV2 also get T4.
>> T3 would remain lonely, would it not?   (reservation: I've not managed to
>> get my head around how this might work if Mike Dean's "Revolving" next
>> Virtual Tuner assignment method might impact on this and experience suggests
>> I'd be best to configure it and test to comment on it however Mike might be
>> able to comment on its impact in the scenario I portrait)
>>
>
> This is exactly what the post I linked allows the user to configure.  You
> can configure MythTV so that it either always re-uses a physical card
> (meaning you're stuck on the mux unless you a) hit NEXTCARD, b) use the EPG,
> or c) enable "Browse all channels")--this being the default
> configuration--or can configure it so that MythTV always grabs a different
> physical tuner for each Live TV session (assuming one is available, or if
> not, grabs a virtual tuner already "stuck" on a mux due to some other
> recording or Live TV session)--this being the configuration where you tell
> MythTV that Live TV is important to you.  Note that in the second case, you
> get exactly what you seem to want--a separate physical capture card for each
> LiveTV session.


However in the 2nd case mentioned above...where a separate physical tuner is
allocated to each LiveTV session...you will currently get sub-optimal use of
tuners with multiple tuners tuner to the same MUX. This limits the choice of
TV channels that can be viewed concurrently to the ones that are available
on the MUX's already being tuned.


>
>
>  Regarding the more than 5 virtual tuner limit, the useful limits here seem
>> to be hardware based and therefore quite variable, depending on the
>> individual servers capabilities, mainly its effective pipe size to the
>> HDD(s).
>>
>
> Really, it's a scalability issue.  On any given hardware, scheduling
> becomes a much harder (and, therefore, much slower) process as the number of
> virtual tuners grows.  It's not the absolute time required for scheduling
> that caused the devs who implemented multirec to choose a limit of 5 virtual
> tuners (as the absolute time /would/ be hardware specific), it's the
> difference in scheduling time required between 5 and 6 (and 7 and 8 and ...)
> virtual tuners.  Graph it and you'll see a non-linear growth.
>

Well I have to say that we dont see this performance issue in our testing
using the current scheduler but with the upper limit on multirec tuners
lifted to say 10. What your describing is not apparent to us. However what
is apparent is that the way multirec tuners are implemented currently seems
less efficient than it might be. This is an area we're looking at
currently...but performance is not driving this so much as reducing code
complexity. We'll post some patches in this area as soon as we have a
reasonably clean implementation.

Andrew



-- 
Head of Software & Technology
Convergent Home Technologies Ltd
www.dianemo.co.uk
www.cascade-media.co.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20100225/4fa4781e/attachment.htm>