Bug 2164 - Use ARTISTSORT values where appropriate for display text for browse lists
: Use ARTISTSORT values where appropriate for display text for browse lists
Status: NEW
Product: Logitech Media Server
Classification: Unclassified
Component: Tagging
: unspecified
: PC Windows XP
: -- enhancement with 2 votes (vote)
: Future
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-21 05:50 UTC by Julian Anonymous
Modified: 2011-11-06 23:23 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Julian Anonymous 2005-09-21 05:50:56 UTC
I use FLAC and make use of the ARTISTSORT tag to enforce consistent sorting 
but I like to keep the ARTIST tag to display the "traditional" name for an 
artist so that this shows correctly on "Now Playing". For instance, for my 
David Bowie collection I have ARTIST="David Bowie" and ARTISTSORT="Bowie, 
David".

The above scheme works perfectly in enforcing the correct sort order but, when 
I am browsing the collection, I only see the display names (i.e. the ARTIST 
tag values) so this isn't always so easy for the user to immediately identify 
the alphabetic order (see my thread on the SlimDevices forum in the General 
board in the thread entitled "Artist/Artistsort tags not what is really 
needed" for more details).

The solution suggested is that when browsing an ordered list that has been 
sorted with reference to ARTISTSORT tags then there should be a SlimServer 
option to override the display names in the list with the value of the 
ARTISTSORT tag when it is set rather than the value of the ARTIST tag.

The above does make conceptual sense to me. If SlimServer has delivered a 
sorted list to the client and has used ARTISTSORT values to sort the list then 
it does seem obvious that the text fields that it delivers for the sorted list 
should be the text fields that were used for the sort, i.e. not just all the 
ARTIST values but rather the ARTIST values but with the appropriate ARTISTSORT 
replacements.

I guess it would make sense to make this a server-settable option to make sure 
noone gets upset by the an enforced change in behaviour. It might also make 
sense for consistency to provide a similar option for the ALBUM/ALBUMSORT 
behaviour although for this one I think it would be absolutely essential for 
it to be an option because for my useage I do want to keep the current 
behaviour, i.e. only ever display the ALBUM tag value and keep ALBUMSORT 
hidden at all time. This is because I currently use ALBUMSORT to enforce 
chronological ordering of my albums so for ALBUM="Young Americans" I have 
ALBUMSORT="Bowie, David, 1975". Clearly this would be a disaster if the 
ALBUMSORT value overwrote the ALBUM value in a display (although I do hope to 
be able to dispense with ALBUMSORT tags when the option for chronological 
ordering of albums is introduced into SlimServer).

Finally, please note that this suggestion for ARTIST/ARTISTSORT might help 
with the issue being discussed in bug 616.

- Julian
Comment 1 KDF 2005-09-21 09:02:40 UTC
why is it not a solution to set ARTIST tags to what you want displayed? It seems
to me that *** is the display tag and ***SORT is a backend tag.  It is up to you
what data goes into them, and confusing if slimserver starts changing them
around arbitrarily. 'optional' at this level adds a huge hit since it means
shuffling data around the tables
Comment 2 Julian Anonymous 2005-09-21 11:11:19 UTC
The problem with your suggestion (set ARTIST to what I want displayed) is that 
there are two different things that I want displayed depending on whether it 
is for the browse artists list or for the "Now Playing" display.

When I am viewing the "Now Playing" display then I would like to see the 
artist name as it is traditionally written. Noone says "I'm playing the latest 
Bowie, David album" but rather "I'm playing the latest David Bowie album" so 
for the Now Playing display I would like to see the artist name as "David 
Bowie" (i.e. the ARTIST tag). When I am browsing artists however I would like 
to see the artist name in its "alphabetically optimised" form, e.g. "Bowie, 
David" (i.e. the ARTISTSORT tag) so that it is much easier to immediately see 
the alphabetical sorting (seeing a list "Black Eyed Peas", "David 
Bowie", "Jeff Buckley" isn't quite as obviously alphabetical to the brain 
as "Black Eyed Peas", "Bowie, David", "Buckley, Jeff").

I don't know the code of course but I'm a bit suprised that this would be 
a "huge hit" implementation wise. One thing I find interesting is the 
behaviour of the Telcanto client which I assume is using the defined 
SlimServer client server protocols. When I browse artists with Telcanto then 
the list I get on screen (which must have been delivered to the Telcanto 
client as the result of a request to the server) has clearly been sorted with 
reference to my ARTISTSORT tags but the list of names delivered to the 
Telcanto client are the values of the ARTIST tags. If the server code has done 
a sort using ARTISTSORT then surely the ordered list (or array) of the sort 
keys at the end of the sort is exactly the result that I am asking to be 
delivered to the client as the list of display names and in fact the current 
behaviour of delivering the list of ARTIST tag values involves the extra step 
of putting back in the ARTIST tags instead of the ARTISTSORT tags where a 
replacement was made for the sort.

- Julian
Comment 3 Jim McAtee 2005-09-21 13:48:54 UTC
One issue: The values for ARTISTSORT are stored in all upppercase, with 
punctuation characters removed, so won't be very attractive as display 
strings.  I never really understood why that is, unless either SQLite is case-
sensitive, or it's a throwback to when everything was done in Pearl hashes, 
perhaps for speed optimization.
Comment 4 Blackketter Dean 2005-09-22 16:07:40 UTC
It sounds like you want the original ARTISTSORT tag to be used when displaying an artist in the context 
of a sorted list of artists.  It's not unreasonable, but we'll have to look at this post 6.2.  
Comment 5 Julian Anonymous 2005-09-22 16:21:22 UTC
Thanks Dean for considering this, that is exactly what I am requesting. I 
should just add 2 clarifications though.

1) If Jim's observation about the ARTISTSORT tags being stored all uppercase 
is still valid post-6.2 then that kind of kills the whole idea because as Jim 
says, it would look terrible.

2) Just being pedantic (for clarity)... when you say "<I> want the original 
ARTISTSORT tag to be used when displaying an artist in the context 
of a sorted list of artists" I mean use the ARTISTSORT tag when it is set for 
an artist, if an ARTISTSORT tag is not set then it should just use the ARTIST 
tag (i.e. exactly the substitution algorithm applied for sorting). (Although 
if this complicated the implementation for some reason then it wouldn't be a 
big deal to make sure the ARTISTSORT field was set for all tracks.)

- Julian
Comment 6 Keith Briscoe 2006-11-02 14:19:23 UTC
Possible unintended consequence: My ARTISTSORT tags (for example) do not necessarily contain the same data as my ARTIST tags.  Using sorting tags for display purposes could cut out useful data, or add confusing data.

For example (from my collection):

ARTIST => ARTISTSORT

The Dave Brubeck Quartet => Brubeck, Dave
Elvis Costello => Costello, Elvis
Elvis Costello and the Attractions => Costello, Eric
Jie-Bing Chen, Bela Fleck, V.M. Bhatt => Fleck, Bela
Harold Budd, Elizabeth Fraser, Robin Guthrie, Simon Raymonde => Cocteau Twins
Maceo & The Macks => Parker, Maceo

In other words, sorting tags are best for sorting, display tags are best for display.  If two types of display are needed, a second alternate display tag should be used.
Comment 7 Alan Young 2011-11-06 23:23:12 UTC
Unassigned bugs cannot have a priority.