[mythtv] V2Capture::AddCardInput

[David Engel]

On Tue, Jul 05, 2022 at 11:54:15AM -0600, John P Poet wrote:
> On Tue, Jul 5, 2022 at 11:02 AM David Engel <david at istwok.net> wrote:
> 
> > On Tue, Jul 05, 2022 at 09:57:36AM -0600, John P Poet wrote:
> > > On Tue, Jul 5, 2022 at 9:46 AM David Engel <david at istwok.net> wrote:
> > >
> > > > On Tue, Jul 05, 2022 at 08:28:43AM -0600, John P Poet wrote:
> > > > > On Tue, Jul 5, 2022, 12:33 AM Klaas de Waal <klaas.de.waal at gmail.com
> > >
> > > > wrote:
> > > > > > On Tue, 5 Jul 2022 at 05:13, John P Poet <jppoet at gmail.com> wrote:
> > > > > >> On Mon, Jul 4, 2022 at 8:30 PM David Engel <david at istwok.net>
> > wrote:
> > > > > >>> On Mon, Jul 04, 2022 at 08:03:45PM -0600, John P Poet wrote:
> > > > > >>> > Hi all,
> > > > > >>> >
> > > > > >>> > I don't think the call to CardUtil::IsUniqueDisplayName()
> > should be
> > > > > >>> fatal
> > > > > >>> > in V2Capture::AddCardInput. *Only the last two characters* of
> > the
> > > > > >>> > DisplayName are considered to determine if it is unique. That
> > > > unfairly
> > > > > >>> > penalizes users who use a theme which can display more than two
> > > > > >>> characters.
> > > > > >>> >
> > > > > >>> > Thoughts?
> > > > > >>>
> > > > > >>> The last two characters of the short, display name can be and is
> > used
> > > > > >>> in themes.  Without enforcing this uniqueness requirement, themes
> > > > that
> > > > > >>> use the short, dispaly name will present ambiguous inputs.
> > > > > >>>
> > > > > >>> David
> > > > > >>>
> > > > > >>
> > > > > >> It should be up to the user to choose Display Names which work
> > with
> > > > the
> > > > > >> theme they have chosen. Why penalize some users just to protect
> > other
> > > > users
> > > > > >> from making a poor choice?
> > > > > >>
> > > > > >> John
> > > > > >>
> > > > > >> As I understand it, it is only a presentation string so it does
> > not
> > > > > > matter for correct operation.
> > > > > > Consider using a 4-tuner HDHomeRun box. It is not really important
> > > > which
> > > > > > of the four tuners are used so a string like "HC" (short for
> > HDHomerun
> > > >
> > > > You are correct that the physical tuner doesn't matter.  However, if
> > > > you care about scheduling or especially, having to support scheduling
> > > > issues, the logical tuner very much matters.
> > > >
> > > > > > Cable) could then be used for all four input connections.
> > > > > > So I suggest doing it the same as in mythtv-setup; generate a
> > default
> > > > that
> > > > > > is unique, e.g. "Input 12", but leave the decision to the user.
> > > >
> > > > It defaults to "Input XX", or at leat it used to.
> > > >
> > > > > Let's move CardUtil::IsUniqueDisplayName() to its own services API
> > call.
> > > > > Then the application can use it to warn the user of the consequences
> > of
> > > > > their choice.
> > > >
> > > > I strongly disagree.  Perhaps you never noticed, but the short,
> > > > display name is used in multiple places like the System Status screen
> > > > and the Change Input menu in live TV.  The intent was to replace input
> > > > number with the [unique] short, display name in every user-facing
> > > > location.  The reason for that was to more gracefully handle the
> > > > proliferation of inpuss and increasingly, meaningless numbers.  In my
> > > > case, I don't even know nor care what my input numbers are anymore.
> > > >
> > > > As for the length of the unique part, I think 2 characters is enough.
> > > > However, as I stated in my private email, 3 could probably work if
> > > > theme designers agree.
> > > >
> > > > David
> > > >
> > >
> > > David, I generally agree with you on most things, but not this. At least
> > > not completely. I agree about the part of input numbers being
> > meaningless.
> > > I disagree that we should punish users of *some* themes just because
> > *other*
> > > themes went with the "short" name instead of the long one.
> > >
> > > You are right that I never noticed the short name being used in those
> > > places -- because with the Steppes theme, the short name is *not used
> > > anywhere*.
> >
> > I wouldn't call requiring 2 or 3 characters to be unique "punishing".
> > Is it really that hard?  I also think that's much better than risking
> > the intentional confussion of users just because they happen to change
> > themes.
> >
> > Look, display name must be unique in some way.  I see that as a given.
> > The question then becomes how to also make it unique when it's used in
> > a condensed format.  When I added the feature, I chose to use the last
> > two characters.  It was much simpler than adding yet another name and
> > it was easy code-wise, wasn't onerous for the user and was also the
> > most likely place a user would distinguish between two or more of the
> > same type of input -- Red 1/Red 2, Black 5/Black 6, etc.
> >
> > If you've got a another suggestion of how to take a unique, display
> > name and condense it down to 2/3 characters that are also unique, then
> > let's hear it.  I'm not wedded to the idea of using the last 2
> > characters.  I'll happily change my input names if you have another
> > way of maitaining uniqueness of both long and short names.
> >
> > David
> 
> 
> I can see an advantage to requiring that DisplayName be unique. However, we
> have never enforced that before. It is not enforced in mythtv-setup, and I
> am talking about the full DisplayName, not even the shortened version.

I thought I'd put enforcement in there.  I know I updated the help
text and enforced it in the serviced API as you found out.  Thinking
back on it now, I'm not even sure mythtv-setup can be made to enforce
constraints at entry time.  It might have strongly suggested at exit
time like some other mis-configurations are handled.

> I just recently tried to use the V2Capture::AddCardInput for the first time
> yesterday and used the same DisplayNames I always use, resulting in
> confusion when they were rejected. I had to track down the code to discover
> that it was only looking at the last two characters. If it had looked at
> the last three then I would not have been bit by that test. So, obviously *for
> me*, requiring the last three to be unique would have been fine.
> 
> So, as a compromise I would like to change CardUtil::IsUniqueDisplayName to
> look at the last three characters. *Just* doing that would not change the
> "value" of the "short" version of the DisplayName, which means themes would
> continue to display the short version as they do now.
> 
> Alternatively, we could change the *definition* of the short DisplayName to
> be three characters.  If a theme does not have enough room for three
> characters, the result will be the last character overlapping the next
> field by some amount. The information would be displayed, it just might not
> look good in some themes.

As already noted, I'm fine with 3 being the number of characters
counted.  In addition, 4 characters shalt not be counted and 5 is
right out. :)

David
-- 
David Engel
david at istwok.net