Thanks guys!
#2 That is a legit point, I haven't thought about yet. But... So why not only use the first value (when there are multiple values). If multiple values would be Piano/Violin/Guitar, then this file is only showed within the group 'Piano'. It kinda forces users to put the most important value in front, but that is pretty logical as well. When skeptical you can see it as a trade-off, but it is a trade-off for the better. If we leave the status quo would show a group called 'Piano/Violin/Guitar', which is less helpful for someone who intended to sort his list.
#3 I once asked how people use Custom Fields (
link). Indeed, some use PUID, or ID's from FreeDB/IMDB. Others use values to define Country, Occasion, Gender, Language, etc.
I think I have a solution to this. The people who do not use ID's, will be better of when full strings are used for Grouping. That is evident, ain't it? Currently, MM groups these values alphabetically. So every country that starts with an
S is grouped in the same group - Sarajevo and Spain together. It is clear that a user would rather see them all sorted on their 'full string'. It is more useful to see that you have 4 Spanish songs, and 3 songs from Sarajevo, rather than seeing that you have 7 songs from countries that start with an
S.
Now, are the people who use ID's happy with alphabetical grouping? Is it helpful to group the songs on the first character that they start with? Most ID's start with a number. So we would see a large group '0-9'. And a group of 'A', 'B' ... 'Z', is not helpful for this way of using the Custom fields. Also I think that an (unique) ID is never intended to group upon. Would someone ever group on IMDB ID's, or PUID's? These Id's are only reference to look up additional information.
I found one person who might find alphabetical grouping helpful for the Custom Fields. He uses a field as 'Additional Albums'. And I can imagine someone using it for 'Additional Artists' to tell what other artist did a cover of this song too (or something like that).
So here is my suggestion. Let the user define what the nature of the Custom field is. Is it to give the track an ID, or to Categorize. MM will handle these custom fields according to these settings.
Default -> Alphabetical order
Categorizing -> MM groups on full strings
Identification -> no grouping, (only sorting)
For all other pre-defined Field in MM, the developers can decide themselves what is most appropriated, just like they do now.