On Wed, Feb 24, 2010 at 5:45 PM, Michael T. Dean <span dir="ltr"><<a href="mailto:mtdean@thirdcontact.com">mtdean@thirdcontact.com</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;">
On 02/24/2010 04:46 AM, Tortise wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: "Ian Oliver"<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
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.<br>
</blockquote></div></blockquote>
<br>
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."<div class="im"><br></div>
</blockquote><div><br></div><div>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. </div>
<div> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Failing that, tell me I can't watch that channel. All PVRs I've met do pretty much exactly this<br>
</blockquote></blockquote>
<br></div>
/me wonders just how many PVR's you've seen that support recording from X virtual tuners on each of Y physical capture cards<br>
<br>
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. :)</blockquote><div><br></div><div>I think the point being made above is that he wants MythTV to 'manage' this situation for him and currently it doesn't.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
<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>
<br></div>
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.</blockquote>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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).<br>
</blockquote>
<br></div>
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.<br>
</blockquote><div><br></div><div>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.</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>