Mailing List Archive

V2Capture::AddCardInput
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?

John
Re: V2Capture::AddCardInput [ In reply to ]
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
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: V2Capture::AddCardInput [ In reply to ]
On Mon, Jul 4, 2022 at 8:30 PM David Engel <david@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
Re: V2Capture::AddCardInput [ In reply to ]
On Tue, 5 Jul 2022 at 05:13, John P Poet <jppoet@gmail.com> wrote:

> On Mon, Jul 4, 2022 at 8:30 PM David Engel <david@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 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.

Klaas.
Re: V2Capture::AddCardInput [ In reply to ]
On Tue, Jul 5, 2022, 12:33 AM Klaas de Waal <klaas.de.waal@gmail.com> wrote:

>
>
> On Tue, 5 Jul 2022 at 05:13, John P Poet <jppoet@gmail.com> wrote:
>
>> On Mon, Jul 4, 2022 at 8:30 PM David Engel <david@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
> 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.
>
> Klaas.
>

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.

John
Re: V2Capture::AddCardInput [ In reply to ]
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@gmail.com> wrote:
> > On Tue, 5 Jul 2022 at 05:13, John P Poet <jppoet@gmail.com> wrote:
> >> On Mon, Jul 4, 2022 at 8:30 PM David Engel <david@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 Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: V2Capture::AddCardInput [ In reply to ]
On Tue, Jul 5, 2022 at 9:46 AM David Engel <david@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@gmail.com>
> wrote:
> > > On Tue, 5 Jul 2022 at 05:13, John P Poet <jppoet@gmail.com> wrote:
> > >> On Mon, Jul 4, 2022 at 8:30 PM David Engel <david@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*.

John
Re: V2Capture::AddCardInput [ In reply to ]
On Tue, Jul 5, 2022 at 9:57 AM John P Poet <jppoet@gmail.com> wrote:

> On Tue, Jul 5, 2022 at 9:46 AM David Engel <david@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@gmail.com>
>> wrote:
>> > > On Tue, 5 Jul 2022 at 05:13, John P Poet <jppoet@gmail.com> wrote:
>> > >> On Mon, Jul 4, 2022 at 8:30 PM David Engel <david@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*.
>
> John
>

mythtv-setup does not require the (short) DisplayName to be unique, so why
do we need to change that behavior for the ServicesAPI? mythtv-setup does
not even require the full DisplayName to be unique.

John
Re: V2Capture::AddCardInput [ In reply to ]
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@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@gmail.com>
> > wrote:
> > > > On Tue, 5 Jul 2022 at 05:13, John P Poet <jppoet@gmail.com> wrote:
> > > >> On Mon, Jul 4, 2022 at 8:30 PM David Engel <david@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
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: V2Capture::AddCardInput [ In reply to ]
On Tue, Jul 5, 2022 at 11:02 AM David Engel <david@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@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@gmail.com
> >
> > > wrote:
> > > > > On Tue, 5 Jul 2022 at 05:13, John P Poet <jppoet@gmail.com> wrote:
> > > > >> On Mon, Jul 4, 2022 at 8:30 PM David Engel <david@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
Re: V2Capture::AddCardInput [ In reply to ]
On 05/07/2022 18:01, David Engel 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@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@gmail.com>
>>> wrote:
>>>>> On Tue, 5 Jul 2022 at 05:13, John P Poet <jppoet@gmail.com> wrote:
>>>>>> On Mon, Jul 4, 2022 at 8:30 PM David Engel <david@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


To be honest I don't really care but I will say that as one of the dev's
that persuaded Isaac many many years ago that being able to name the
tuners was a good idea for identification purposes at no point did we
ever say they should be 2 characters long!

It sounds to me like at some point someone decided it would be a good
idea to use that name as an identifier in place of some 2 character
number or cardid?  in the UI and didn't take into account the name can
be anything. It was always meant to be a meaningful name not some
cryptic 2 character id. It's just one of those things that always seems
to happen in MythTV were over time things get added or changed but not
necessarily in a sensible way.


Come back Isaac we may not have always agreed with him but at least we
had a direction to follow and in the end progress was always made.  I
miss those exciting times when you could go to bed one day and the next
morning there would be a load of new features added over night and often
a new release to play with :)


Paul H.

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: V2Capture::AddCardInput [ In reply to ]
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@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@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@gmail.com
> > >
> > > > wrote:
> > > > > > On Tue, 5 Jul 2022 at 05:13, John P Poet <jppoet@gmail.com> wrote:
> > > > > >> On Mon, Jul 4, 2022 at 8:30 PM David Engel <david@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@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: V2Capture::AddCardInput [ In reply to ]
On Tue, Jul 5, 2022 at 1:18 PM David Engel <david@istwok.net> 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@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@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@gmail.com
> > > >
> > > > > wrote:
> > > > > > > On Tue, 5 Jul 2022 at 05:13, John P Poet <jppoet@gmail.com>
> wrote:
> > > > > > >> On Mon, Jul 4, 2022 at 8:30 PM David Engel <david@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
>

Okay. How do you feel about *just* changing CardUtil::IsUniqueDisplayName
and leaving the 'display' to still be only two characters? I would be
tempted to also change the display and then let the themers decide if they
need to make room....

John
Re: V2Capture::AddCardInput [ In reply to ]
On Tue, Jul 05, 2022 at 07:00:37PM +0100, Paul Harrison wrote:
> On 05/07/2022 18:01, David Engel 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@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@gmail.com>
> > > > wrote:
> > > > > > On Tue, 5 Jul 2022 at 05:13, John P Poet <jppoet@gmail.com> wrote:
> > > > > > > On Mon, Jul 4, 2022 at 8:30 PM David Engel <david@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
>
>
> To be honest I don't really care but I will say that as one of the dev's
> that persuaded Isaac many many years ago that being able to name the tuners
> was a good idea for identification purposes at no point did we ever say they
> should be 2 characters long!

No one has said the display name must be 2 and only 2 characters long.
All that is currently required is that the last 2 characters be
unique. For example, my input names are HDHR1-An, HDHR-Bn, Ceton-Cn
and MLB.tv-Mn where n is some number.

> It sounds to me like at some point someone decided it would be a good idea
> to use that name as an identifier in place of some 2 character number or
> cardid?? in the UI and didn't take into account the name can be anything. It
> was always meant to be a meaningful name not some cryptic 2 character id.
> It's just one of those things that always seems to happen in MythTV were
> over time things get added or changed but not necessarily in a sensible way.

The feature was added as a replacement for using short names instaed
of increasingly, meaningless input numbers. At one point, many/most
themes could only handle single-digit numbers. When multirec was
added and double-digit, input numbers became more common, all themes
were, or should have been updated, to accomodate that. That's why the
number of 2 unique characters was chosen. It would not require themes
to resize any textareas should they decide to use the short, input
name in place of the input nubmer.

David

> Come back Isaac we may not have always agreed with him but at least we had a
> direction to follow and in the end progress was always made.? I miss those
> exciting times when you could go to bed one day and the next morning there
> would be a load of new features added over night and often a new release to
> play with :)
>
>
> Paul H.
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: V2Capture::AddCardInput [ In reply to ]
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@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@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@gmail.com
> > > >
> > > > > wrote:
> > > > > > > On Tue, 5 Jul 2022 at 05:13, John P Poet <jppoet@gmail.com> wrote:
> > > > > > >> On Mon, Jul 4, 2022 at 8:30 PM David Engel <david@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
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: V2Capture::AddCardInput [ In reply to ]
On Tue, Jul 5, 2022 at 1:38 PM David Engel <david@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@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@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@gmail.com
> > > > >
> > > > > > wrote:
> > > > > > > > On Tue, 5 Jul 2022 at 05:13, John P Poet <jppoet@gmail.com>
> wrote:
> > > > > > > >> On Mon, Jul 4, 2022 at 8:30 PM David Engel <
> david@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
Re: V2Capture::AddCardInput [ In reply to ]
On Tue, Jul 5, 2022 at 1:53 PM John P Poet <jppoet@gmail.com> wrote:

> On Tue, Jul 5, 2022 at 1:38 PM David Engel <david@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@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@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@gmail.com
>> > > > >
>> > > > > > wrote:
>> > > > > > > > On Tue, 5 Jul 2022 at 05:13, John P Poet <jppoet@gmail.com>
>> wrote:
>> > > > > > > >> On Mon, Jul 4, 2022 at 8:30 PM David Engel <
>> david@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
Re: V2Capture::AddCardInput [ In reply to ]
On Tue, Jul 05, 2022 at 05:05:04PM -0600, John P Poet wrote:
> On Tue, Jul 5, 2022 at 1:53 PM John P Poet <jppoet@gmail.com> wrote:
>
> > On Tue, Jul 5, 2022 at 1:38 PM David Engel <david@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@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@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@gmail.com
> >> > > > >
> >> > > > > > wrote:
> >> > > > > > > > On Tue, 5 Jul 2022 at 05:13, John P Poet <jppoet@gmail.com>
> >> wrote:
> >> > > > > > > >> On Mon, Jul 4, 2022 at 8:30 PM David Engel <
> >> david@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!

I think your patch is okay. Although, it looks like it contains some
gratuitous, space changes.

Look for the progMap["input"] = ... line in ProgramInfo::ToMap(). I
wouldn't be surprised if my personal theme is the only one using it.
I didn't promote the change very much to theme developors and inertia
can be a hard thing to change.

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: V2Capture::AddCardInput [ In reply to ]
Hi Paul,

The attach patch makes mythcenter-wide show the input name instead of the
cardid on the upcoming recordings screen. It demonstrates what David and I
have been arguing about (discussing ???? :)

In Steppes there is room to show the full capturecard "displayname" but in
most themes there is not. So David came up with a solution to trim down the
dislayname to the last two characters to they would fit in most themes
where they would normally show the cardid. Since Steppes could show the
full name, I thought limiting it to two characters was too restrictive. Our
compromise was to limit it to two characters unless the user used a slash
('/') as part of the displayname. If a '/' is detected, then anything after
the slash is now used as the *short* displayname. This effectively allows
me to use whatever size *short* displayname I want, while still defaulting
to only the last two characters for most users.

Both David and I agree that using the input name (aka displayname) is more
user friendly than using the cardid, but most themes still use the cardid.
I am happy to commit this mythcenter-wide patch, but wanted to get your
sign-off first.

John
Re: V2Capture::AddCardInput [ In reply to ]
On 07/07/2022 01:09, John P Poet wrote:

> Hi Paul,
>
> The attach patch makes mythcenter-wide show the input name instead of
> the cardid on the upcoming recordings screen. It demonstrates what
> David and I have been arguing about (discussing ???? :)
>
> In Steppes there is room to show the full capturecard "displayname"
> but in most themes there is not. So David came up with a solution to
> trim down the dislayname to the last two characters to they would fit
> in most themes where they would normally show the cardid. Since
> Steppes could show the full name, I thought limiting it to two
> characters was too restrictive. Our compromise was to limit it to two
> characters unless the user used a slash ('/') as part of the
> displayname. If a '/' is detected, then anything after the slash is
> now used as the *short* displayname. This effectively allows me to use
> whatever size *short* displayname I want, while still defaulting to
> only the last two characters for most users.
>
> Both David and I agree that using the input name (aka displayname) is
> more user friendly than using the cardid, but most themes still use
> the cardid. I am happy to commit this mythcenter-wide patch, but
> wanted to get your sign-off first.
>
> John
>

Hi John,


That's fine by me it sound like a reasonable compromise.


It's late and I have not looked at the code but I assume we have a
toMap() function somewhere that maps the theme template strings to there
actual values if so one thought I had was to maybe have two template
strings one for the short 2 character display name and one and one for
the full length display name that way themers can choose which one they
want to use?


Paul H.

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: V2Capture::AddCardInput [ In reply to ]
On Thu, Jul 07, 2022 at 01:51:48AM +0100, Paul Harrison wrote:
> On 07/07/2022 01:09, John P Poet wrote:
>
> > Hi Paul,
> >
> > The attach patch makes mythcenter-wide show the input name instead of
> > the cardid on the upcoming recordings screen. It demonstrates what David
> > and I have been arguing about (discussing ???? :)
> >
> > In Steppes there is room to show the full capturecard "displayname" but
> > in most themes there is not. So David came up with a solution to trim
> > down the dislayname to the last two characters to they would fit in most
> > themes where they would normally show the cardid. Since Steppes could
> > show the full name, I thought limiting it to two characters was too
> > restrictive. Our compromise was to limit it to two characters unless the
> > user used a slash ('/') as part of the displayname. If a '/' is
> > detected, then anything after the slash is now used as the *short*
> > displayname. This effectively allows me to use whatever size *short*
> > displayname I want, while still defaulting to only the last two
> > characters for most users.
> >
> > Both David and I agree that using the input name (aka displayname) is
> > more user friendly than using the cardid, but most themes still use the
> > cardid. I am happy to commit this mythcenter-wide patch, but wanted to
> > get your sign-off first.
> >
> > John
> >
>
> Hi John,
>
>
> That's fine by me it sound like a reasonable compromise.
>
>
> It's late and I have not looked at the code but I assume we have a toMap()
> function somewhere that maps the theme template strings to there actual
> values if so one thought I had was to maybe have two template strings one
> for the short 2 character display name and one and one for the full length
> display name that way themers can choose which one they want to use?

That is already the case. ProgramInfo::ToMap() supports the following
tags, among many others.

Tag Mapped Item
----------------------------
card Numeric card ID
input Short input name
inputname Full input name

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org