On Wed, Feb 24, 2010 at 9:46 AM, Tortise <span dir="ltr"><<a href="mailto:tortise@paradise.net.nz">tortise@paradise.net.nz</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
----- Original Message ----- From: "Ian Oliver" <<a href="mailto:lists@foxhill.co.uk" target="_blank">lists@foxhill.co.uk</a>><br>
To: <<a href="mailto:mythtv-users@mythtv.org" target="_blank">mythtv-users@mythtv.org</a>><br>
Sent: Wednesday, February 24, 2010 11:09 AM<br>
Subject: Re: [mythtv-users] Live TV channel restrictions<br>
<br>
Interesting thread that I've just come across that also interests me and my familial "clients".<div class="im"><br>
<br>
In article <<a href="mailto:4B840B51.4000309@thirdcontact.com" target="_blank">4B840B51.4000309@thirdcontact.com</a>>, Michael T. Dean wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you always want LiveTV to get a separate physical<br>
tuner<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That isn't what I want. If there is a tuner on the right mux and with a free<br>
</blockquote>
virtual tuner, then use it. Failing that, find a free tuner and tune it to the<br>
right mux. Failing that, tell me I can't watch that channel. All PVRs I've met do<br>
pretty much exactly this.<br>
<br></div>
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.)<br>
<br>
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.<br>
<br>
A LiveTV Tuner is ideally locked to one tuner - why - because a Live user may want to choose any channel from any mux anytime.<br>
<br>
A Rec Tuner is distinguished by not having an enduser who is going to demand the tuner change any time to any mux.<br>
<br>
These distinctions seem fundamental to me.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
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]}<br>
<br>
[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].<br>
<br>
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.<br>
<br>
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)<br>
</blockquote><div><br></div><div>The patch we have posted essentially fixes the above problem pretty effectively - and requires no manual tuner management from the user.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
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.<br>
</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
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!<br>
<br>
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. </blockquote><div><br></div><div>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.</div>
<div><br></div><div>All the best</div><div><br></div><div><br></div><div>Andrew</div></div><br><br clear="all"><br>-- <br>Head of Software & Technology<br>Convergent Home Technologies Ltd<br><a href="http://www.dianemo.co.uk">www.dianemo.co.uk</a><br>
<a href="http://www.cascade-media.co.uk">www.cascade-media.co.uk</a><br>Tel: +44 (0)1245 330101<br>Fax: +44 (0)1245 263916<br><br>Unit 205 Waterhouse Business Centre<br>Cromar Way<br>Chelmsford<br>Essex CM1 2QE<br>UK<br>
<br>
Registered in England: 0513055 Registered Office: Alecandra Accountancy Services. 47 Church Street Gt. Baddow Essex CM2 7YA <br>CHT asks that you please consider the Environment before printing this or any other correspondence<br>