>My response to your question therefore would be: no, let's not try to be >smart. If the user wants to be able to browse by ALBUMARTIST, he shall >fix his tags. If we try to guess, then we'll always fail for some users. >If we strictly follow the user's data, then it's up to him to create the >data he wants to get.
Whilst I generally think this is a good approach to some matters (eg. accented characters and exact equality of artist names), I don't think this would be a good idea. A user doesn't want to browse the tag "ALBUMARTIST", a user wants to browse artists that have albums. Any change from what is currently displayed would be bad. Behind the scenes, Browse Artists could potentially be improved for simplicity and performance: 1) by pre-calculating "artists that have albums". i.e. currently it is a mixture of contributor roles Artist and Album Artist. If there were an Album Artist role automatically created by the scanning process, using the same logic that is applied when browsing artists, the browse query could be simplified. This would be at the expense of additional scanning time. I worry that this might not be straight forward, as it has to be a post scan job - need to know state of all songs before Album Artist can be calculated, and Browse Music Folder to dynamically read latest file tags means this could break. 2) By removing logic for providing the Various Artists item at the top of the artists list, creating a Compilations browse method as a replacement. "Various Artists" would just appear like any other aritst or album artist in the list. _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
