[mythtv-users] Live TV channel restrictions

[Tortise]

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

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)

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.

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.