[mythtv] V2Capture::AddCardInput

John P Poet jppoet at gmail.com
Tue Jul 5 17:54:15 UTC 2022


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

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20220705/996f0cc9/attachment.htm>


More information about the mythtv-dev mailing list