On Tue, Feb 23, 2010 at 11:42 PM, Michael T. Dean <span dir="ltr">&lt;<a href="mailto:mtdean@thirdcontact.com">mtdean@thirdcontact.com</a>&gt;</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;">

<div class="im">On 02/23/2010 05:47 PM, Andrew Herron wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I totally agree with your perspective on this issue. Below i describe a fix for this that we have in development;<br>
<br>
We are working on a patch to MythTV 0.21 that does exactly what you are describing for LiveTV &amp; for scheduler recordings too - ie MythTV automagically manages multirec tuners so that it always makes sure that if a multirec tuner is already tuned to a channel from a given MUX that subsequent requests from either LiveTV viewing or the scheduler for other channels on that MUX are allocated to a Multirec tuner derived from that same physical tuner...if no physical tuner is delivering channels from the MUX required then a new Multirec tuner will be allocated on an unused physical tuner.<br>


</blockquote>
<br></div>
MythTV already does this.  That&#39;s the crux of the problem that Ian is describing.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This means that there is never a situation where you can have two physical tuners tuned to the same MUX.<br>
</blockquote>
<br></div>
That would be new--i.e. causing MythTV to &quot;jump tuners&quot; from whatever (&quot;later&quot;) tuner it&#39;s using to (an &quot;earlier&quot;) one that&#39;s already tuned to a mux when the LiveTV user requests a channel change.<br>

</blockquote><div><br></div><div>Mike - as I said in my original post we have this working now...and it works well and it avoids the situation that Ian describes whereby currently MythTV may double up Tuners and have them delivering channels from the same MUX.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
It would also have effects on future recordings and the schedule (as if LiveTV locks that tuner to the mux that /was/ in use and the scheduler had planned to change to a different mux for the next recording...).</blockquote>

<div> </div><div>Which is why we are implementing the same Tuner management for the Scheduler currently.</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">
All of this is automatically handled for the user and no manual tuner selection is required.<br>
</blockquote>
<br></div>
Which is &quot;Browse all channels&quot; (which was added to MythTV for version 0.22 and is disabled by default).</blockquote><div><br></div><div>But the standard Myth implementation still double allocates tuners and wastes resources as Ian describes. Our code optimises physical tuner usage and does that automatically for the user.</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">
Alongside the above we have removed the limitation of only 5 multirec tuners per physical tuner.<br>
</blockquote>
<br></div>
You do realize that limitation was put there because there are significant scalability problems with multirec that become progressively worse as the number of virtual tuners increases past 5.</blockquote><div><br></div><div>

We currently are successfully testing with 10 multirec tuners per physical tuner and we see no such performance issues to date. As I write this one of the test backends is utilising  7 multirec tuners on one physical tuner and 4 each on the other two tuners. We are regularly testing with 20+ multirec tuners in use concurrently across 3 physical tuners.</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">
We have the LiveTV part of the above working well now and are just starting working on integrating and testing the recordings scheduler so that it uses the same logic now. As soon as we have the scheduler working we will release a patch for MythTV 0.21 and then we hope to test and then commit a 0.22 version subsequently.<br>


</blockquote>
<br></div>
So, other than the one new feature I mentioned, it sounds like you guys have just implemented, &quot;Browse all channels,&quot; in MythTV 0.21.<br></blockquote><div><br></div><div>Well the efficient use of multirec tuners is really at the core of what we are doing. The current way MythTV handles multirec tuners in this respect is not optimal and it is this change that really addresses the issues that Ian raises in his original post. Optimising the allocation of multirec tuners both when the user is consuming LiveTV and when the Scheduler is managing recordings is what this is about - and to achieve that we have to have MythTV do the management automatically for us.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
If, in fact, your implementation is better than the one we have now, the patch is appreciated, but please ensure you do proper research before submitting the patch and describe exactly what&#39;s different from what we currently have (other than 0.21-fixes support :).<br>

</blockquote><div><br></div><div>We will do the above and i hope that what we have done will prove to be a valuable enhancement to MythTV that anyone who uses multirec like we all do will find useful.</div><div> </div><div>

Andrew</div></div>