[mythtv-users] Live TV channel restrictions

Andrew Herron totallymaxed at gmail.com
Wed Feb 24 13:50:49 UTC 2010

On Wed, Feb 24, 2010 at 9:46 AM, Tortise <tortise at paradise.net.nz> wrote:

> ----- Original Message ----- From: "Ian Oliver" <lists at foxhill.co.uk>
> To: <mythtv-users at mythtv.org>
> Sent: Wednesday, February 24, 2010 11:09 AM
> Subject: Re: [mythtv-users] Live TV channel restrictions
> Interesting thread that I've just come across that also interests me and my
> familial "clients".
> In article <4B840B51.4000309 at thirdcontact.com>, 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. Failing that, tell me I can't watch that channel. All PVRs I've
> met do
> pretty much exactly this.
> 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.

Well our view is that in the multirec world it makes more sense to only ever
have one physical tuner tuned to a given MUX at any one time. MythTV then
accepts requests from a user who wants to watch LiveTV or from the Scheduler
for tuner resources and manages/arbitrates those requests - automatically.
The user can then decide whether LIveTV usage or scheduler recordings take
preference. This maximises the use of the physical tuner resources by
allowing MythTV automate that tuner allocation/management logic for us...and
at the same time removes the need for the user to make those decisions.

The patch we have posted in this thread is a step along this road...with
some refinement and additional code to extend its reach into the scheduler
we think it offers some real advantages. We have testers already using the
patch and the feedback so far is really very positive from this
predominantly non-technical audience.

> 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)

The patch we have posted essentially fixes the above problem pretty
effectively - and requires no manual tuner management from the user.

> 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).  Where there are more than 5 channels in a mux then it is possible
> to want to record all of them simultaneously, however how many channels are
> people getting in a mux?  We do have arguably 9 useful channels here (3 are
> radio/audio - still valid channels with less hardware requirement each) on
> one mux, so in that respect the limitation shows a flaw in my above
> reckoning of the optimal number of tuners, as it assumes one tuner can
> simultaneously record all channels, which is clearly not the case here.
>  However I understand a mux has a capacity and the nine is pretty much
> approaching the mux's capacity?  One possibility might be to assign a mux to
> a tuner - and therefore specify the number of channels that tuner is to
> handle. - and reduce replication however I do not understand the code here
> and certainly am not saying it should be done that way and that would only
> be helpful when there were enough Tuners for all situations, which will
> often not be the case.

Again our patch essentially does allocate a physical tuner to each requested
MUX. If additional requests come in from other frontends for any channels on
a MUX that is already available from a physical tuner then another multirec
tuner is allocated and the request is satisfied. I agree the only limitation
is the physical hardwares ability to handle the multiple multirec streams
and this will vary from system to system.

> Knowing (and respecting) the majority dev preference of recording all
> material in advance (and still considering the issues here before I form a
> firm view here, I see valid arguments for each view), and having found
> LiveTV in the past to be no where as reliable as the recording performance
> (which I have difficulty recalling crashing ever - no doubt for good reason
> - the dev's interest has been there) I have actually also implemented a
> HDHomerun Dual Tuner on the LAN (in addition to the two 500T cards giving 4
> tuners) and where the Frontend PC has enuff puff I have used VLC for LiveTV,
> as it has been faster and more reliable for me.  (That means I can leave VLC
> running LiveTV and in 48 hours it is still running)  Recently LiveTV with
> limited testing has behaved itself so this old experience may be remedied
> now, I'm not sure yet.  There are pluses and minuses to each approach, vdpau
> is certainly one of the considerations!
> I hope these comments are helpful, in the least for providing some useful
> perspective for the patch coders however you may have covered all this off.

I think all of above is useful perspective. I agree that there are strongly
held views about LiveTV consumption but on the other hand we see actual
users asking for a better experience when consuming LiveTV and I think
therefore both of these needs need to be addressed.

All the best


Head of Software & Technology
Convergent Home Technologies Ltd
Tel: +44 (0)1245 330101
Fax: +44 (0)1245 263916

Unit 205 Waterhouse Business Centre
Cromar Way
Essex CM1 2QE

Registered in England: 0513055 Registered Office: Alecandra Accountancy
Services. 47 Church Street Gt. Baddow Essex CM2 7YA
CHT asks that you please consider the Environment before printing this or
any other correspondence
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20100224/8600e70b/attachment.htm>

More information about the mythtv-users mailing list