[mythtv-users] Enabling multirec borks usability a bit.

mugginz feed.mugginz at internode.on.net
Wed Apr 21 03:41:59 UTC 2010


On Wed, 21 Apr 2010 07:48:54 am Michael T. Dean wrote:
> On 04/20/2010 04:22 PM, Tortise wrote:
> > From: "Michael T. Dean"
> > 
> > One thing to keep in mind is the overall goal of mythtv - wasn't it to
> > be the mythical convergence of all technologies into one system?
> > Correct me if I am worng, I don't think exclusion of livetv fits with
> > the original definition of mythtv?
> 
> Live TV isn't excluded.  It's just that it will only be improved by
> people who care to donate their time/effort to improving Live TV (and
> you can't count me among those people--I have plenty of other stuff on
> my TODO list for MythTV).
> 
> >> Small, but achievable goals, and all...  Make a bunch of little
> >> changes to get a huge improvement.
> > 
> > Well I am certainly sympathetic to that notion, IMO and experience it
> > is vastly eassier to make small incremental changes than do a dump of
> > a radical change and then the pain of debugging the hell out of it....
> > 
> >> Then, eventually, maybe some of the bigger changes will be
> >> easier/more acceptable.
> > 
> > The holy grail seems to be having the same number of tuners as the
> > users have number of mux, so for me that's 3, given code that
> > efficiently utilises the tuners for recording and livetv.
> > (Realistically that means 2 x 500T's here = 4 tuners!)
> > 
> > 
> > I did not realise that turning off multirec would also fix the issue.
> > So if I had 3 x 500T = 6 physical tuners that hardware requirement is
> > very likely to cover 99.x% of our user requirements, whether it be
> > through either of the above options.  My servers got 3 PCI slots....
> > To make 6 I'm going to buy another dual tuner!
> > 
> > One thing I'd appreciate a response on is the question of dedicating
> > tuners.  How hard would it be to say have 3 tuners dedicated for
> > multi-recording mux and say 3 dedicated for (uni-rec) live TV use?  As
> > we only have 3 mux, this could also work well and keep 3 live
> > frontends live.  (Not sure what one would do when 4 tried...I suppose
> > as is now....)
> > 
> > Maybe making the first 3 tuners multi-rec and leaving the rest uni
> > might be a pragmatic solution that uses the existing code base? I
> > think it would cover it all for 1 live user.  The issue would be which
> > tuner a second live user got, I believe they'd currently get the same
> > tuner the first live tv user is using....?  Could that be a small
> > fix....(Mike can you comment please?)
> 
> Just configure your first 3 cards with, say, 3 virtual tuners each, then
> add the next 3 cards with 1 virtual tuner each (and you /must/ connect
> inputs and set virtual tuners as you're configuring your cards properly
> so you have card 1 with inputs 1,2,3; card 2 with inputs 4,5,6; card 3
> with inputs 7,8,9, card 4 with input 10, card 5 with input 11, card 6
> with input 12).  Then enable Avoid conflicts...  (See
> http://www.gossamer-threads.com/lists/mythtv/dev/369358#369358 for more
> details, but you won't need the +1 for Live TV is you have 6 physical
> tuners and 3 muxes.)


The above configuration requirement seems to be an unfortunate side effect of 
the current tuner selection code.  Expecting an experienced MythTV implementer 
to configure in this way is reasonable.  Expecting someone new to MythTV to 
both find information on how to perform this peculiar configuration ritual, and 
then be comfortable performing it is another thing.


> > Either way I'd still have an inefficient tuner use outside the "holy
> > grail" scenario.
> 
> If you only have 3 muxes, you only need 3 physical tuners with X >
> max_concurrent_recordings_and_livetv_per_mux virtual tuners defined.
> Then change channel with the EPG or using Browse all channels.  And,
> using the configuration I described at the post above, you'd likely use
> Y+1 virtual tuners where Y >= max_concurrent_recordings and the +1 gives
> you 1 extra virtual tuner for Live TV.


This allows you to browse the channels, but when selecting one of them Myth 
wont actually change to the one you necessarily want.


> > The cost of tuners is relatively small compared to the surrounding kit
> > they integrate in with.
> > 
> > The coding "cost", ie limited coding dev resource is limited.
> 
> Yep.  And that's just it.  It's cheaper for me to buy as many tuners as
> I need than it is to write (and have to maintain) code to try to do what
> you all would like to see.  (Granted, I don't/won't ever use Live TV, so
> it's easier for me to get a configuration that's perfect than it is for
> someone who wants recordings and Live TV.)


Indeed it's unfair to demand some random dev to implement functionality that 
dev has no need for.  I do hope that the project leads are open to 
modifications of the nature required though.


> > I for one respect the dev's setting development priorities because
> > they understand the decision criteria and consequences better than I do.
> > 
> > I am also prepared to buy another dual tuner!
> 
> Right, so everyone else has the same option as me--write code, configure
> their system within current possibilities, use EPG or Browse all
> channels, or buy hardware.  :)
> 
> Mike


Browse all channels isn't working they way you think it is unless it's a bug 
introduced into 0.23, either via browsing with up/down arrow or EPG.

With regards to hardware utilitsation, it's already been identified that even 
when you have enough tuners to cover all of the available muxes there are 
still scenarios were Myth doesn't make best use of hardware and locks out 
possible channels.


More information about the mythtv-users mailing list