The '<n> albums' sort order (again)

[simoncn]

Thanks for your thoughtful reply. I've made some brief comments inline below.

(09-09-2013 16:35)DavidHB Wrote:  Well, we are fully agreed on the nature of the problem, but we are approaching it from opposite ends of the telescope. You quite reasonably want to feed MinimServer data it will not choke on. I am concerned that the data in online databases in is not in that form, so will have to be separately formatted for use with MinimServer; I know that you too want to impose on users as little as possible. For myself, I believe that, using MP3Tag, the workload required to make composer and artist data MinimServer-friendly is entirely manageable. Users who wish to steer clear of filter instructions and regular expressions may think differently. In the end, it's your call.

I agree that doing this from my end of the telescope would require an extra tagging step for users who want to sort by last name. Ideally, there would be a tool of some kind (not part of MinimServer) that would take care of this tagging step in a user-friendly and intuitive fashion. What I've proposed should be regarded as a simple starting point for an initial implementation of custom sorting, not a final and complete solution.

Quote:Indeed. That works well now in the individual tag-based indexes. In my original post, I did not perhaps make it clear enough that all my suggestions related only to the '<n> albums' index.

The <n> albums list is not an index (in terms of how MinimServer treats indexes), but is a flat list of the albums with no further index selections possible. The only customizations possible are sort order (using a fixed list of tags) and alphabetical grouping (by the first letter of the album title). You can get a "normal" Album index by adding Album to indexTags, but there's little reason to do this.

I think you could achieve your desired sort order by setting Album.sortTags to something like:

Genre, Composer, AlbumArtist, Album

but this wouldn't be compatible with alphabetical grouping, as you have said. The code that implements alphabetical grouping is quite complex and is used for all alphabeticallly grouped lists, and I wouldn't want to attempt to tweak this code to do something different for the special case of "<n> albums".

Quote:UPnPlay on Andoid, for example, always shows the '<n> albums' index on startup, and this (if I use software with this behaviour as standard) makes it useful to tune '<n> albums' as closely to my needs as possible.

I tried this, and I get the normal top-level menu on startup. Have you done some configuration of UPnPlay to make it show the "<n> albums" list instead?

Quote:Indeed; this is what I have. So I suppose I am asking (1) that these options could be applied (if need be, optionally) to the album.Sort option, and (2) that, in album.Sort, the values of any ungrouped tag(s) that are sorted before the grouped tag appear in the '<n> albums' list, as shown in the example in my last post.

I think this would be a step too far in complexity for the "<n> albums" list, which is intended to be a simple list. The MinimServer indexes are intended to be the place where more complex structuring and selection can be done.