[mythtv-users] How do I disable a tuner
Michael T. Dean
mtdean at thirdcontact.com
Sat Apr 30 05:22:33 UTC 2011
On 04/29/2011 05:49 PM, f-myth-users at media.mit.edu wrote:
> > Date: Fri, 29 Apr 2011 16:07:10 -0500
> > From: David Engel
> > On Fri, Apr 29, 2011 at 04:04:48PM -0400, f-myth-users at media.mit.edu wrote:
> > > [I still think it's a little weird that Myth uses the creation order,
> > > as opposed to something easier for a user to define and/or change, but
> > > that's a different topic.]
> > What would that something be? If you've got a better idea, let's hear
> > it. The obvious one is to add another column to cardinput to reflect
> > the concept of input ordering.
> That's sort of what I was thinking. In fact, I think I said as much a
> couple of years ago, and I imagine others have probably said so as well.
> > The hard part is then presenting it to
> > the user in such a way that doesn't confuse it with input priority.
> I agree. But we keep hearing that input priority almost never does
> what you want anyway, and yet we keep presenting -that-, too...
> So instead of making an important priority a total accident of the
> order in which the cards were created, find some name for the concept
> we're talking about (do we have one already?), name the column that,
> and present it to the user using that name.
Again, as mentioned in my other post, we don't need a way to represent
the information--we already have that. We only need a UI for changing
(and showing) it. Think select a card or input, hit up arrow or down
arrow, and the setup program fixes the DB to reflect the changes... It
should also present the information in such a way that the user knows
that he is changing the recording input selection order or the Live TV
card selection order (and shouldn't allow the separate Live TV card
selection order unless the user enabled "Avoid conflicts...").
> No matter what name I
> come up with, someone will point out that it's not technically
> correct, or that I need to read and understand every word of an
> enormously long description of what's going on (since that's what Mike
> says every time someone tries to use input priorities), so I'll leave
> it to Mike or some other expert on that chunk 'o text to come up with
> a good name for the underlying concept.
> But yes, I think it should be decoupled from the total artifact of the
> autoincrement field in the table. Asking the user to start over if
> they get the ordering wrong---or just change their minds---has always
> seemed completely crazy to me. And the whole "it takes me---an expert
> who's done this dozens of times---only 30 seconds to do this" attitude
> it entirely dismissive of users who -aren't- experts and do it rarely.
> That's no way to judge whether the task is easy or hard. It's a silly
> task in the first place if only Myth had a way to do this that wasn't
> dependent on the order in which the cards were initially defined.
In other words, the internal data model is none of your business (where
"your" means anyone who isn't actually using the data internally in
MythTV code). A good application will, however, present a useful UI
that makes a user-important concept clear--regardless of how the
information is stored internally.
> (For that matter---uh oh, feature creep---we could then define a
> priority called NEVER USE and the OP's original question would have
> been solved without the whole disconnect-from-sources-no-wait-delete-
> it-instead business---just set the don't-use priority and reset it
> later. Users have occasionally asked for this functionality for a
> long time to deal with short-term changes to Myth's environment;
> this might be a good excuse to make it easier.)
Wow, those lazy devs. They really should do that.
(Here I'm just saying that if I had anywhere near the kind of time
available that some of these, "Someone ought to," messages seem to imply
we devs have, MythTV would be a very much more mature program from the
one it is. ;)
Just my $0.02.
More information about the mythtv-users