Side effects of custom sort tag with alphabetical grouping

[eseb63]

Hello,
I've noticed strange behavior when using alphabetical grouping for an indexTag with a custom sort associated with it.

• indexTags: Work_Rating, Work_Rated:Work (Work_Rated = concatenation of Work and Work_Rating)
• itemTags: Work, Work_Sort
• TagValue: Work_Listing.value.sort={Work_Sort}
• alphaGroup: all=50
  

I made test for Schumann works:
example:

• Work_Rated: "Variations pour Piano Op. 1 "sur le nom de Abegg" (1829-30)     ♪♪♪♪♪"
• Work_Sort: 08Romantique§Schumann, Robert§Instrumental§Op. 1§Variations pour Piano Op. 1 "sur le nom de Abegg" (1829-30)"
  

Instead of finding this work in group "V", I find it in group "#" with all the other Schumann works having the label Work_sort (therefore starting with the same prefix): what does this group correspond to? Does the symbol # represent a number?

I have two albums containing this work; on one, it appears on a single track; on the other, it is spread across six tracks. By adding the letter "Z" to the first position of the Work_Sort label on the first album (single track), I find the work in its correct group "V" and no longer in the group "#", even though the tracks on the second album have a Work_Sort label starting with "08".

I've noticed another problem: if I specify alphagroup="all", the indextags are correctly grouped alphabetically, except for Work_Rated:Work; omitting the alias doesn't change anything; I think this is another side effect of the Work_Sort tag.

thanks in advance for advice

[simoncn]

The symbol # represents an alphbetical group containing items with names starting with a number or symbol. It appears first in the list before the group for A.

I will set up a test along the lines of your description and post back here when I have observed and investigated the results. This is likely to take a few days.

[simoncn]

The sort value is used to control the order in whch names appear in an index. For example, with these tags:

Artist: The Beatles
ArtistSort: Beatles, The

the artist The Beatles will appear among artists whose names start with B, not among artists whose names start with T. Alphabetical grouping doesn't change this sort order, so you will see The Beatles listed in the B section.

Each tag index value can only have one sort value. By adding a Z to the Work_Sort value of the single track, you are creating a conflict between two different sort values for the same index value. In this case, MinimServer ignores both conflicting sort values (it has no way to know which is "correct") and writes a message to the MinimServer log saying that it has done this. Because the sort values for this work have been ignored, you are seeing the work sorted under V.

Quote:I've noticed another problem: if I specify alphagroup="all", the indextags are correctly grouped alphabetically, except for Work_Rated:Work; omitting the alias doesn't change anything; I think this is another side effect of the Work_Sort tag.

I am not sure I have understood what you are saying here. There is no difference in sorting or grouping between specifying alphaGroup: all and alphaGroup: all=50.

[eseb63]

I didn't see you had replied several days ago...

So if i understand correctly, when a sort tag is associated to the index tag, the alphabetical group is based on the first letter of the sort tag's value and not of the index tag's value ; this explains why the works are grouped in the # group.

It makes sense for tags like artist, composer etc ... whose sort tag's value is a reverseName value, but less for tags like work whose sort tag may be defined another way (like mine).

Would it be possible to manage these two different needs ?
for example by analyzing the sort tag's value :

• if it's the reverse form of the index value, the present behavior remains (the alphabetical group is based on the first letter of the sort tag's value)
• if not, the alphabetical group is based on the first letter of the index value
  

[simoncn]

I don't like the idea of MinimServer changing its sort behaviour based on the format of the sort tag value.

I think a better solution would be for you to change the sort tag values so that they start with the first letter of the alphabetical group in which you want to place the item.

[eseb63]

my need was to handle these two use cases :

• if i know what i want to listen to (a Brahms trio), i choose Brahms as composer and pick the work in its first letter alphabetical group (T for Trio ...)
• if i want to listen to a trio but without knowing specifically which one, i choose Trio as Genre and want to list all works beeing trios, ordered by period and composer: I thought about using the alphabetical group T to retrieve the trios, then making a selection from the sorted list. However, as minimServer alphabetical groups are based on the sort tag first letter, it doesn't work.
  

So, i manage this another way:

• use case 1: Work_rated tag without a sort tag associated with it to use normally alphabetical grouping
• use case 2 : i create a Work_Listing index tag by script whose format is <Period> - <Composer> - <Genre> - <Work_Rated> and associate it with my sort tag. As all sort values start with a zero, alphabetical grouping is not shown : i can browse the ordered list and choose among the items.
  

the sort tag format is a bit different from the Work_Listing one:
<numPeriod><Period>§<Composer>§<Genre>§<Opus>§<Work>

• numPeriod : to sort the periods chronologically
• Opus : to sort the works in the opus order
  

[simoncn]

Thanks for posting this. I am pleased to hear that you have found a way to do what you need using the existing capabilities of MinimServer.