On Wed, Feb 24, 2010 at 12:35 AM, 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/23/2010 07:23 PM, Andrew Herron wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Feb 23, 2010 at 11:42 PM, Michael T. Dean wrote<div class="im"><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<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
tuners per physical tuner.<br>
<br>
</blockquote>
You do realize that limitation was put there because there are significant<br>
scalability problems with multirec that become progressively worse as the<br>
number of virtual tuners increases past 5.<br>
<br>
</blockquote>
We currently are successfully testing with 10 multirec tuners per physical<br>
tuner and we see no such performance issues to date. As I write this one of<br>
the test backends is utilising 7 multirec tuners on one physical tuner and<br>
4 each on the other two tuners. We are regularly testing with 20+ multirec<br>
tuners in use concurrently across 3 physical tuners.<br>
<br>
</div></blockquote>
<br>
It's the scheduler itself that slows with more virtual recorders. Try running complete reschedules with varying numbers of virtual tuners. Also, if your patch doesn't obsolete and remove the "Browse all channels" setting, try with and without that setting using varying numbers of virtual tuners.<div class="im">
<br>
<br>
<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">
If, in fact, your implementation is better than the one we have now, the<br>
patch is appreciated, but please ensure you do proper research before<br>
submitting the patch and describe exactly what's different from what we<br>
currently have (other than 0.21-fixes support :).<br>
<br>
</blockquote>
We will do the above and i hope that what we have done will prove to be a<br>
valuable enhancement to MythTV that anyone who uses multirec like we all do<br>
will find useful.<br>
<br>
</blockquote>
<br></div>
Great. With a good description of what you've done and how it differs from/improves upon all of the many pieces we have involved with multirec, it will make it a lot easier for someone to review the patch. I'm looking forward to seeing the patch.<br>
<br>
Oh, and if it decreases the number of settings we have (as it sounds like it may), I'll definitely love that part of it. :)<br>
<br>
Thanks,<div><div></div><div class="h5"><br>
Mike<br></div></div></blockquote><div><br></div><div>Hi Mike, </div><div><br></div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Just to give you a taster...This is the current patch. It's a bit ugly in my opinion, but OK for work in progress (things will move some more).<br>
<br>This patch requires unique channel numbers. Identical channel numbers on two or more sources doesn't work, and any collisions must be fixed, or the other channels will be rendered inaccessible - first result returned by SQL is always used. So far, the work centered around DVB-T and DVB-S cards. Capture card channels (with channel changer script) fail to switch from one channel to another because right now the ShouldSwitchToAnotherCard function is short-circuited to always return true and Myth excludes the current tuner when "it should switch", which results in a popup box saying all tuners are busy. This will be addressed in the very near future.<br>
<br>This patch only addresses live tv. It doesn't fix browse mode, and collisions between scheduled recordings and Live TV can result in anything from an inconvenience - you have to restart Live TV - to a missed recording.<br>
<br>Target is to change the way recorders work: have "infinite" multirec support built into the TVRec class, and also have the recordings scheduler pick a tuner on the fly, just in time to record the program, rather than pre-schedule it, in order to have optimum tuner usage across the board.<br>
<br>What would happen if all the tuners are in use and a recording is about to start and there's no tuner for it - especially if the tuners are busy due to different people watching different things on Live TV throughout the house, is still up to debate, and there may not be a "one size fits all" solution to it.<br>
<br>The patch is for Myth 0.21+fixes20787 from Avenard's VDPAU-patched sources, but it should give you a clear insight of what we're doing though, even if it's not ready for prime time. One more thing this patch does not include the change to allow for more multirec tuners - that is a separate and simple patch though and I will post it if it would be useful to anyone on the list.<br>
<br></span><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Any insight would be appreciated Mike, cheers.</span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br>
</span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br></span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Andrew</span></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>
<br>