[mythtv] V2Capture::AddCardInput

Tue Jul 5 23:05:04 UTC 2022

On Tue, Jul 5, 2022 at 1:53 PM John P Poet <jppoet at gmail.com> wrote:

> On Tue, Jul 5, 2022 at 1:38 PM David Engel <david at istwok.net> wrote:
>
>> On Tue, Jul 05, 2022 at 02:17:08PM -0500, David Engel wrote:
>> > 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. :)
>>
>> FYI, I'm also fine with defining an optionally, more complex format
>> that splits the long and short/must-be-unique names.  For example,
>> with a / (or other agreed upon delimier) the user could enter
>>
>>     HDHR-Prime/A1
>>     HDHR-Prime/B3
>>     Ceton/C5
>>
>> If the delimiter is not present, the last n characters are checked for
>> uniqueness, otherwise, the part after the delimiter is used.  I know
>> some might argue that that's more complex than just having separate
>> fields.  I can understand that argument but don't necessarily agree
>> with it.  Most users will be content with the default Input nn names.
>>
>> David
>>
>
> That works for me and gives the flexibility I was after.
>
> John
>

David,

I am attaching a patch for you to look at. One thing I was unable to find
is where the "short" displayname is created for actual display purposes. I
downloaded several themes and did not find a single example of the short
displayname being used anywhere. Believe it or not, most themes are still
showing the input number!

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20220705/578cc0c6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dispayname.patch
Type: text/x-patch
Size: 4066 bytes
Desc: not available
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20220705/578cc0c6/attachment.bin>