[mythtv-users] Live TV channel restrictions

[Andrew Herron]

On Tue, Feb 23, 2010 at 11:42 PM, Michael T. Dean
<mtdean at thirdcontact.com>wrote:

> On 02/23/2010 05:47 PM, Andrew Herron wrote:
>
>> I totally agree with your perspective on this issue. Below i describe a
>> fix for this that we have in development;
>>
>> We are working on a patch to MythTV 0.21 that does exactly what you are
>> describing for LiveTV & 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.
>>
>
> MythTV already does this.  That's the crux of the problem that Ian is
> describing.
>
>
>  This means that there is never a situation where you can have two physical
>> tuners tuned to the same MUX.
>>
>
> That would be new--i.e. causing MythTV to "jump tuners" from whatever
> ("later") tuner it's using to (an "earlier") one that's already tuned to a
> mux when the LiveTV user requests a channel change.
>

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.


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


Which is why we are implementing the same Tuner management for the Scheduler
currently.


>
>
>  All of this is automatically handled for the user and no manual tuner
>> selection is required.
>>
>
> Which is "Browse all channels" (which was added to MythTV for version 0.22
> and is disabled by default).


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.


>
>
>  Alongside the above we have removed the limitation of only 5 multirec
>> tuners per physical tuner.
>>
>
> 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.


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.


>
>
>  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.
>>
>
> So, other than the one new feature I mentioned, it sounds like you guys
> have just implemented, "Browse all channels," in MythTV 0.21.
>

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.


>
> 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's different from what we
> currently have (other than 0.21-fixes support :).
>

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.

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20100224/b4af88be/attachment.htm>