<div dir="ltr"><div dir="ltr">On Tue, Jul 5, 2022 at 1:53 PM John P Poet <<a href="mailto:jppoet@gmail.com">jppoet@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Tue, Jul 5, 2022 at 1:38 PM David Engel <<a href="mailto:david@istwok.net" target="_blank">david@istwok.net</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jul 05, 2022 at 02:17:08PM -0500, David Engel wrote:<br>
> On Tue, Jul 05, 2022 at 11:54:15AM -0600, John P Poet wrote:<br>
> > On Tue, Jul 5, 2022 at 11:02 AM David Engel <<a href="mailto:david@istwok.net" target="_blank">david@istwok.net</a>> wrote:<br>
> > <br>
> > > On Tue, Jul 05, 2022 at 09:57:36AM -0600, John P Poet wrote:<br>
> > > > On Tue, Jul 5, 2022 at 9:46 AM David Engel <<a href="mailto:david@istwok.net" target="_blank">david@istwok.net</a>> wrote:<br>
> > > ><br>
> > > > > On Tue, Jul 05, 2022 at 08:28:43AM -0600, John P Poet wrote:<br>
> > > > > > On Tue, Jul 5, 2022, 12:33 AM Klaas de Waal <<a href="mailto:klaas.de.waal@gmail.com" target="_blank">klaas.de.waal@gmail.com</a><br>
> > > ><br>
> > > > > wrote:<br>
> > > > > > > On Tue, 5 Jul 2022 at 05:13, John P Poet <<a href="mailto:jppoet@gmail.com" target="_blank">jppoet@gmail.com</a>> wrote:<br>
> > > > > > >> On Mon, Jul 4, 2022 at 8:30 PM David Engel <<a href="mailto:david@istwok.net" target="_blank">david@istwok.net</a>><br>
> > > wrote:<br>
> > > > > > >>> On Mon, Jul 04, 2022 at 08:03:45PM -0600, John P Poet wrote:<br>
> > > > > > >>> > Hi all,<br>
> > > > > > >>> ><br>
> > > > > > >>> > I don't think the call to CardUtil::IsUniqueDisplayName()<br>
> > > should be<br>
> > > > > > >>> fatal<br>
> > > > > > >>> > in V2Capture::AddCardInput. *Only the last two characters* of<br>
> > > the<br>
> > > > > > >>> > DisplayName are considered to determine if it is unique. That<br>
> > > > > unfairly<br>
> > > > > > >>> > penalizes users who use a theme which can display more than two<br>
> > > > > > >>> characters.<br>
> > > > > > >>> ><br>
> > > > > > >>> > Thoughts?<br>
> > > > > > >>><br>
> > > > > > >>> The last two characters of the short, display name can be and is<br>
> > > used<br>
> > > > > > >>> in themes.  Without enforcing this uniqueness requirement, themes<br>
> > > > > that<br>
> > > > > > >>> use the short, dispaly name will present ambiguous inputs.<br>
> > > > > > >>><br>
> > > > > > >>> David<br>
> > > > > > >>><br>
> > > > > > >><br>
> > > > > > >> It should be up to the user to choose Display Names which work<br>
> > > with<br>
> > > > > the<br>
> > > > > > >> theme they have chosen. Why penalize some users just to protect<br>
> > > other<br>
> > > > > users<br>
> > > > > > >> from making a poor choice?<br>
> > > > > > >><br>
> > > > > > >> John<br>
> > > > > > >><br>
> > > > > > >> As I understand it, it is only a presentation string so it does<br>
> > > not<br>
> > > > > > > matter for correct operation.<br>
> > > > > > > Consider using a 4-tuner HDHomeRun box. It is not really important<br>
> > > > > which<br>
> > > > > > > of the four tuners are used so a string like "HC" (short for<br>
> > > HDHomerun<br>
> > > > ><br>
> > > > > You are correct that the physical tuner doesn't matter.  However, if<br>
> > > > > you care about scheduling or especially, having to support scheduling<br>
> > > > > issues, the logical tuner very much matters.<br>
> > > > ><br>
> > > > > > > Cable) could then be used for all four input connections.<br>
> > > > > > > So I suggest doing it the same as in mythtv-setup; generate a<br>
> > > default<br>
> > > > > that<br>
> > > > > > > is unique, e.g. "Input 12", but leave the decision to the user.<br>
> > > > ><br>
> > > > > It defaults to "Input XX", or at leat it used to.<br>
> > > > ><br>
> > > > > > Let's move CardUtil::IsUniqueDisplayName() to its own services API<br>
> > > call.<br>
> > > > > > Then the application can use it to warn the user of the consequences<br>
> > > of<br>
> > > > > > their choice.<br>
> > > > ><br>
> > > > > I strongly disagree.  Perhaps you never noticed, but the short,<br>
> > > > > display name is used in multiple places like the System Status screen<br>
> > > > > and the Change Input menu in live TV.  The intent was to replace input<br>
> > > > > number with the [unique] short, display name in every user-facing<br>
> > > > > location.  The reason for that was to more gracefully handle the<br>
> > > > > proliferation of inpuss and increasingly, meaningless numbers.  In my<br>
> > > > > case, I don't even know nor care what my input numbers are anymore.<br>
> > > > ><br>
> > > > > As for the length of the unique part, I think 2 characters is enough.<br>
> > > > > However, as I stated in my private email, 3 could probably work if<br>
> > > > > theme designers agree.<br>
> > > > ><br>
> > > > > David<br>
> > > > ><br>
> > > ><br>
> > > > David, I generally agree with you on most things, but not this. At least<br>
> > > > not completely. I agree about the part of input numbers being<br>
> > > meaningless.<br>
> > > > I disagree that we should punish users of *some* themes just because<br>
> > > *other*<br>
> > > > themes went with the "short" name instead of the long one.<br>
> > > ><br>
> > > > You are right that I never noticed the short name being used in those<br>
> > > > places -- because with the Steppes theme, the short name is *not used<br>
> > > > anywhere*.<br>
> > ><br>
> > > I wouldn't call requiring 2 or 3 characters to be unique "punishing".<br>
> > > Is it really that hard?  I also think that's much better than risking<br>
> > > the intentional confussion of users just because they happen to change<br>
> > > themes.<br>
> > ><br>
> > > Look, display name must be unique in some way.  I see that as a given.<br>
> > > The question then becomes how to also make it unique when it's used in<br>
> > > a condensed format.  When I added the feature, I chose to use the last<br>
> > > two characters.  It was much simpler than adding yet another name and<br>
> > > it was easy code-wise, wasn't onerous for the user and was also the<br>
> > > most likely place a user would distinguish between two or more of the<br>
> > > same type of input -- Red 1/Red 2, Black 5/Black 6, etc.<br>
> > ><br>
> > > If you've got a another suggestion of how to take a unique, display<br>
> > > name and condense it down to 2/3 characters that are also unique, then<br>
> > > let's hear it.  I'm not wedded to the idea of using the last 2<br>
> > > characters.  I'll happily change my input names if you have another<br>
> > > way of maitaining uniqueness of both long and short names.<br>
> > ><br>
> > > David<br>
> > <br>
> > <br>
> > I can see an advantage to requiring that DisplayName be unique. However, we<br>
> > have never enforced that before. It is not enforced in mythtv-setup, and I<br>
> > am talking about the full DisplayName, not even the shortened version.<br>
> <br>
> I thought I'd put enforcement in there.  I know I updated the help<br>
> text and enforced it in the serviced API as you found out.  Thinking<br>
> back on it now, I'm not even sure mythtv-setup can be made to enforce<br>
> constraints at entry time.  It might have strongly suggested at exit<br>
> time like some other mis-configurations are handled.<br>
> <br>
> > I just recently tried to use the V2Capture::AddCardInput for the first time<br>
> > yesterday and used the same DisplayNames I always use, resulting in<br>
> > confusion when they were rejected. I had to track down the code to discover<br>
> > that it was only looking at the last two characters. If it had looked at<br>
> > the last three then I would not have been bit by that test. So, obviously *for<br>
> > me*, requiring the last three to be unique would have been fine.<br>
> > <br>
> > So, as a compromise I would like to change CardUtil::IsUniqueDisplayName to<br>
> > look at the last three characters. *Just* doing that would not change the<br>
> > "value" of the "short" version of the DisplayName, which means themes would<br>
> > continue to display the short version as they do now.<br>
> > <br>
> > Alternatively, we could change the *definition* of the short DisplayName to<br>
> > be three characters.  If a theme does not have enough room for three<br>
> > characters, the result will be the last character overlapping the next<br>
> > field by some amount. The information would be displayed, it just might not<br>
> > look good in some themes.<br>
> <br>
> As already noted, I'm fine with 3 being the number of characters<br>
> counted.  In addition, 4 characters shalt not be counted and 5 is<br>
> right out. :)<br>
<br>
FYI, I'm also fine with defining an optionally, more complex format<br>
that splits the long and short/must-be-unique names.  For example,<br>
with a / (or other agreed upon delimier) the user could enter<br>
<br>
    HDHR-Prime/A1<br>
    HDHR-Prime/B3<br>
    Ceton/C5<br>
<br>
If the delimiter is not present, the last n characters are checked for<br>
uniqueness, otherwise, the part after the delimiter is used.  I know<br>
some might argue that that's more complex than just having separate<br>
fields.  I can understand that argument but don't necessarily agree<br>
with it.  Most users will be content with the default Input nn names.<br>
<br>
David<br></blockquote><div><br></div><div>That works for me and gives the flexibility I was after.</div><div><br></div><div>John<br></div></div></div></blockquote><div><br></div><div>David,</div><div><br></div><div>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!<br></div><div><br> </div><div>John<br></div></div></div>