Enhancement request: Leverage Musicbrainz RELEASETYPE tag when present to inform album browse

[audiomuze]

LMS currently includes all albums where an artist makes an appearance in a long list sorted by the sort criteria selected by the user.

The end result is that the listing blends together Albums, EP's, Singles, Appearances, Compilations and Various Artists albums, diminishing the ability to quickly find an item of interest where an artist has many entries. As an example browsing Don Henley:

LMS already reads the RELEASETYPE tag from files when present, but does not leverage the information.

Leveraging it would enable LMS to present albums in a more structured fashion e.g:

• Albums
• Compilations
• EP's
• Singles
• Appearances
• Various Artists

Doing so would significantly enhance the user experience, particularly where an artist has many entries within a user's album collection.

[audiomuze]

Implementing the suggestion above will enable the above presentation to be turned into something akin to this:

Thoughts from others?

[erspearson]

I have a ton of singles for some artists and I'd love to stop them drowning out the album view.

How can I help? (goes to blow dust off the camel book...)

[michaelherger]

Would one of you have a bunch of sample files with different release types in them? Feel free to strip the audio. All I'm interested in is a few files of (possible) different types (Flac, mp3,...) and release types.

https://www.dropbox.com/request/T3RctyzGgNg0oFDubq6a

I can't find RELEASETYPE or the like on https://docs.mp3tag.de/mapping/. Would anybody know the actual tag name?

[michaelherger]

Some of the steps I could imagine:

• extend database schema "albums" with a "release type" column, and likely
• store release type info in that column
• extend browse modes to filter by that column

I believe this should be feasible. Not as a plugin, though, it would have to be implemented in the core of LMS.

One of the issues that might crop up: the release type comes with each track file. What if the release type varies between the various tracks of an album? Would you create multiple albums of different type? Would you assign all tracks to the same album, using the release type of the first track scanned?

[erspearson]

I could generate some files but I don't have any to hand. It's a bit 'chicken and egg', I've never considered tagging with releasetype as LMS makes no use of it. I do all my tagging in my own data preparation scripts (in Perl) and that just uses metaflac to add the tags to the files so that should be easy.

On the album/track relationship - well that's as old as LMS, I guess - scanning has always tried to recreate the upper levels of the schema from the track files. In my setup the track-album-artist relationship is present in my folder structure. And then again in Music Collector which I use for the master catalogue. Users of MusicBrainz get its artist/release/recording/track hierarchy flattened into a a set of UUIDs tagged into every track.

So my feeling would be that tags like releasetype will have originated higher up in some data model external to LMS and flattened into a set of track files from which LMS is attempting to reverse engineer the higher levels. LMS can reasonably assume that they are therefore consistent across track files (as a result of the external denormalization).

From your options above about inconsistent sets then I'd go for considering the album ID as the combination (tuple) of album title and release type. A set of tracks with all the same 'album' title but different release types would generate distinct 'albums' that surface separately in the UI. I can't think of a real world example just now but I bet there exists an album on which there is a track that has the same title as the album and that was also released separately as a single (including also a B side or remixes not present on the album).

[audiomuze]

Would one of you have a bunch of sample files with different release types in them? Feel free to strip the audio. All I'm interested in is a few files of (possible) different types (Flac, mp3,...) and release types.

https://www.dropbox.com/request/T3RctyzGgNg0oFDubq6a

I can't find RELEASETYPE or the like on https://docs.mp3tag.de/mapping/. Would anybody know the actual tag name?

If you give me till Monday I’ll be able to upload examples for you, which will reflect Picard tagging and thus most closely map to musicbrainz.

Mapping info is here:

https://picard-docs.musicbrainz.org/en/appendices/tag_mapping.html

[audiomuze]

One of the issues that might crop up: the release type comes with each track file. What if the release type varies between the various tracks of an album? Would you create multiple albums of different type? Would you assign all tracks to the same album, using the release type of the first track scanned?

If any tracks in an album have differing release type data then it’s the tagging that’s poor and I’d use the release type of the first track. One thing you will encounter is that tracks can have multiple release types: https://beta.musicbrainz.org/doc/Release_Group/Type

Ideally there would be a config option in LMS where a user defines the release type entries they want LMS to group albums by. This way the user gets to have LMS behave in a way that meets their needs/tagging schema.

There’s also the question of handling artist appearances in albums by other artists and in Various Artists albums. I’ll paste some screen shots on Monday demonstrating how that’s been handled elsewhere.

[erspearson]

One thing you will encounter is that tracks can have multiple release types

I don't see anything on that page suggesting that a track can be tagged with more than one release type.

Ideally there would be a config option in LMS where a user defines the release type entries they want LMS to group albums by.

I'm happy to keep things simple and just let the set of tag values found drive the behavior.

Would anybody know the actual tag name?

It's here for various file types: https://picard-docs.musicbrainz.org/en/appendices/tag_mapping.html#id32

Extend browse modes to filter by that column

Yes, browse modes would be a flexible way of using this. For me, having a couple of extra sort order options in the artist and album modes would be my main interest. I generally favour"Artist, Year, Album". I'd imagine "Artist, ReleaseType, Year, Album" being my new favourite as I'd see a chronological list of Albums (uncluttered by singles) followed by a chronological list of just the singles. I do appreciate this would need to be done on a skin by skin basis.

[audiomuze]

I don't see anything on that page suggesting that a track can be tagged with more than one release type.

I’ve seen plenty in the wild tagged directly via Picard, when I get home I’ll pull a list of all the distinct combos I’ve come across.

Right, pulling a list from my own library this is what's been added by Picard (there's been no hand involved in this, so it's purely what's come from musicbrainz):

album
album\\audio drama
album\\audiobook
album\\compilation
album\\compilation\\dj-mix
album\\compilation\\live
album\\compilation\\soundtrack
album\\demo
album\\dj-mix
album\\live
album\\live\\soundtrack
album\\remix
album\\soundtrack
anthology
broadcast\\audio drama
broadcast\\live
compilation
compilation\\demo\\ep
compilation\\ep
demo\\ep
ep
ep\\live
ep\\remix
ep\\soundtrack
live
other
remix\\single
single
single\\interview
single\\live
single\\soundtrack

[audiomuze]

Would one of you have a bunch of sample files with different release types in them? Feel free to strip the audio. All I'm interested in is a few files of (possible) different types (Flac, mp3,...) and release types.

@michaelherger I've uploaded flac and mp3 examples of album and ep. In both cases the PW is mherger

[michaelherger]

Are you saying there can be multiple values, and they're separated by backslashes?... Would you want them to be available by all of them? Or top level (first) only?

Would any of the sample files you sent me have multiple values? I've only seen single types so far (album or ep).

[audiomuze]

Would any of the sample files you sent me have multiple values? I've only seen single types so far (album or ep).

I'll upload one that has multiple values.

Are you saying there can be multiple values, and they're separated by backslashes?

Ignore the backslashes, they're just a delimiter used when tags are imported into a SQLite table. But yes, I am saying there can be multiple values based on what I've seen pulled from Musicbrainz via Picard.

... Would you want them to be available by all of them? Or top level (first) only?

If one adds an album to MusicBrainz it provides for a Primary and Secondary releasetype.

Primary:

• Album
• Single
• EP
• Broadcast
• Other

Secondary:

• Audio Drama
• Audiobook
• Compilation
• Demo
• DJ-mix
• Field recording
• Interview
• Live
• Mixtape/Street
• Remix
• Soundtrack
• Spokenword

If one then has a look over at Discogs the list of Formats (their releasetype) is endless.

If one considers how music is traditionally released:

• Album
• EP
• Single
• Promotion
• Bootleg

Then when one sets aside what the likes of MusicBrainz and Discogs use, I think there's merit in letting users define which RELEASETYPE values they'd like to use to break an artist's work into discrete sections. This would provide them with the flexibility to control how an artist's work is broken into discrete sections within LMS.

All of this belies an underlying complexity in that the fundamental problem we are trying to solve is distinguishing between an artist's:

• Albums
• Compilations
• EP's
• Singles
• Appearances
• Various Artists

Doing so would mean having to evaluate RELEASETYPE as well as incorporate the existing logic that LMS uses to include appearances in albums where the artist is not the albumartist as well as Various Artists albums.

So ideally, when one selects an artist to browse one would want to see sections returned, and if that we not possible in the construct of how LMS operates and interacts with its front-ends, one long list (as we have it today) but showing:

• Albums
• Compilations
• EP's
• Singles
• Appearances
• Various Artists

in that order, with each subset of the list sorted by a (universal) sort order the user chooses. The screenshot in my first post illustrates that, albeit I appreciate it may not be possible to present different sections in LMS.

[michaelherger]

You're right that the UI presentation might be the biggest challenge. I have code now which would store the information in the database, and return it in relevant queries. It allows me to create new menus like "Singles" using the "Extended Browse Modes" plugin. And excluding some types from the main "Albums" list should be pretty easy, too.

But how to present the UX for an artist?... As you said the devices are rather limited. We can't have headings, unless we introduce eg. text only items between the various releases. Or we create sub-menus for them.

Maybe @CDrummond would be able to do something smarter/nicer with Material? As you can get the release type as part of the albums query, would you be interested and have ways to have a grouping in an artist's menu implemented?

I could release the changes so far to get the basics tested. Or I push it to a branch I pushed it to https://github.com/Logitech/slimserver/tree/release-type - if you wanted to run LMS from a git clone. Even being able to exclude some release types from the albums list might be helpful for some. Eg. even Spotify would return "Album" or "Single", which would allow me personally to get rid of the singles 😁.

[michaelherger]

I re-read your latest comment about the grouping, @audiomuze. I think what you're trying to achieve goes way beyond the release type, but ventures more into the contributor role field. "Appearance" isn't a release type, but probably defines what a contributor's role was on a publication. This can't be handled using the release type information. So I'll concentrate on what are considered the "Primary" types.

[CDrummond]

@michaelherger I can certainly add sub-menus for this. What I'm thinking of is that if I ask for a list of "albums" and there are multiple release types then I will show a list. e.g.

• 2 Albums
• 5 EPs
• 1 Single

Clicking on each would then show the items of the relevant type. Pretty sure the requester would prefer a mix of headings and items all in 1 list/grid. The issue, however, is adding headers to the grid view would be a major pain - and simply not worth the effor for me. So, I think the above should suffice - and be reasonaby easy to implement.

[michaelherger]

I plan to have a setting in LMS to not distinguish the release types. In that case you'd only get the type album. Would be nice if in that case no menu was generated 😉. I hope to have something usable for testing, soon.

[CDrummond]

@michaelherger My idea was to only show the menu if there were multiple types. So, only singles the Material would show 1 list (but would show "X Singles" in its toolbar). If your setting as turned off, then there'd be only 1 type (as there is none, so I'd default to album), and no menu would be shown.

...I have a few EPs, but no singles, and no release-type set on any of my collection, so woudl not want this menu showing anyway :)

[audiomuze]

I think what you're trying to achieve goes way beyond the release type, but ventures more into the contributor role field. "Appearance" isn't a release type, but probably defines what a contributor's role was on a publication. This can't be handled using the release type information. So I'll concentrate on what are considered the "Primary" types.

@mherger, you're right that it goes beyond what's achievable using only release type.

Whether or not you end up focusing only on the Primary types I think users that would want to use this feature would benefit greatly from the ability to define a delimited list of release types they consider to be primary for their purposes. It might default to something, but having the ability to add/remove other values would embed an ability for user's specific preferences to be met.

When one enters an artist view through LMS or Material's main menu by clicking on an artist name somewhere in the interface I'm guessing there's a SQL albums query being run that returns all "albums" where that artist has a contributor role, sorted by album and year, or whatever the user has last used as sort criteria. Would it not be possible to include the contributor role in addition to the release type and return one list sorted by Primary type and then the contributor roles pertaining to album artist, appearances and various artists

In my mind's eye I was envisaging appending the results of a series of queries to a temp table and then returning the records from that temp table. In this way the queries could incrementally append the matching records to the temp table first adding say: Album, Compilation, EP, Single, Bootleg, Appearances, Various Artists, with each subset ordered by the order that LMS would currently use. That would mean front-ends would not need to create sub-menus nor in fact (worst case) do anything with the list other than display it in the order received. For front-ends that wanted to they could parse the results and insert headers, extra space or whatever they felt appropriate in order to "split" the presentation.

Having sub-menu's would to my mind be counter to how users would typically want to explore music. Having one long list would be preferable, even if it didn't differentiate between types but only presented the list ordered by type.

[CDrummond]

For front-ends that wanted to they could parse the results and insert headers, extra space or whatever they felt appropriate in order to "split" the presentation.

Add headers to Material's list is easy. Adding it to the grid, not (easily) possible - each row in the grid needs to be the same height, and large headers would look stupid.

Having sub-menu's would to my mind be counter to how users would typically want to explore music. Having one long list would be preferable, even if it didn't differentiate between types but only presented the list ordered by type.

I would not want one long list with some weird sorting, so sorry not going to happen that way in Material. But anyhow, this discssion does not belong here.

[michaelherger]

@audiomuze I think you got a point in that we can currently query albums for a contributor's role, but we don't expose the role in the response. That's probably something else which should be feasible.

That said the frontends would still require work to expose that new feature (if it got implemented). Maybe there could even be a plugin completely taking over the artist album menu. Hmm...

[michaelherger]

A former SB team buddy at some point mentioned he'd never want to work in UI design, because there are as many opinions as there are people in a discussion 😂.

[michaelherger]

@audiomuze you said

I'll upload one that has multiple values.

Could you please do so? While I think I've got @erspearson mostly covered (getting rid of unwanted singles in the album list), I'm not sure about how to deal with multiple values. Starting with the lack of knowledge how they would come along.

[audiomuze]

@audiomuze you said

I'll upload one that has multiple values.

Could you please do so? While I think I've got @erspearson mostly covered (getting rid of unwanted singles in the album list), I'm not sure about how to deal with multiple values. Starting with the lack of knowledge how they would come along.

@michaelherger. Done. Same as before.

How they come about is users ctrl-click different selections from the primary and secondary releasetype dropdowns when adding albums to MusicBrainz. From a tagging perspective they'll appear exactly as any other multi-value tag.

[michaelherger]

Great! Here's what LMS is reporting ("Show Tags"):

RELEASETYPE: [ album, compilation, soundtrack ]

"compilation"... that was already causing headaches before I tried to implement MB release types 😂.

But you'd also want to be able to group by "soundtrack", I guess? that would require even more database work. We'd likely have to introduce another table, very much like the genre_track or contributor_album tables to represent the m:n relationships. What a nightmare 😖.

[CDrummond]

Not sure how "soundtrack" is a release type? Looks more like a genre to me. album, compilation, single, EP, etc, yes - but soundtrack?

[michaelherger]

Yeah, if you look at https://beta.musicbrainz.org/doc/Release_Group/Type then you'll see that most of the secondary types are not exactly what you'd consider a release type. But it's what they've decided to use...

[audiomuze]

Don’t be bound by MucicBrainz choices, let the user decide what values in releasetype matter to them. When I referenced ‘Compilation’ here it’s based on the presence of that string in releasetype, not some underlying logic that determines whether or not an album is deemed a Compilation or VA album in LMS’s scanning/ database logic.

[audiomuze]

Also, seeing as musicbrainz tagger writes both primary and secondary types to releasetype, don’t try distinguish them. Treat all entries as primary and let the user specify which keywords matter to them - I’m guessing simpler to code, and ultimate flexibility for users to put whatever they like in releasetype, nominate which are important to them and have LMS behave accordingly.

[michaelherger]

Thanks a lot for your input and thoughts! Unfortunately thinking through a potential implementation and looking at your sample files I see several issues with what you wish for:

1. the code complexity will increase considerably
2. with the higher complexity there will be a performance impact
3. ... and more potential for bugs/failure
4. ... and a massive potential for opinionated implementation decisions

Numbers 1 & 2 are caused by the need for yet another table (vs. just an additional column in an existing table), causing more relations in queries. And the need to clean them up when tagging changes etc. All those issues we're already facing with grouping albums or a contributor's work. And we're only talking about the backend, the database handling. The frontend might not even able to take advantage of all of this.

Number 4 will bring up questions like

• should we "normalise" type names or use them as is (eg. "various artists" vs. "Various Artists")
• should an album only be listed under the first of those types? On Cat Stevens' page, should the above album be listed once or thrice? If only once, which one?
• if we want to have a list of albums only, should the above still be listed, though we don't want to include compilations?
• should the "compilation" type override the "compilation" flag? What if the flag is there but not the release type?
• similarly there's an overlap between what some would consider a genre and this release type ("Soundtrack")

The "ultimate flexibility" you mention comes at a price. And eventually it might likely cause more frustration than it would find power users who use it at full. People are already struggling with "Pretenders" vs. "The pretenders".

And funnily enough all of this wouldn't even give you what you initially wanted, as that was contributor role based, rather than release type based.

So... I don't know what to do next. I think I have a working solution for the primary release type (not hard-coded, but simply the first in the list). Is half the loaf better than no bread? Will it only cause confusion (people don't like changes) and lust for more, or does it solve some of the problems, satisfy some of the needs?

[audiomuze]

@michaelherger

I think first and foremost, put aside that Musicbrainz can be/ is a source for releasetype tags. Work on the basis users would add whatever releasetype entries best served their use case, so no need to hard code a MB specific outcome.

If users could define a comma delimited string in LMS' config that specifies the releasetype tags they care about, in the order they'd like to see albums listed that should suffice for most use cases and would be better than a half-loaf and a huge step forward from the tangled mess that appears at present if you view a popular artist and have a lot of VA albums in a library. Default that string to 'Album, EP, Single', but have an ability to overwrite that with a user's preference. If the preference is blank, LMS behaves exactly as it does today. If it's populated the query is modified to take account of releasetype tags the user has specified, in the order they're listed in the comma delimited string.

Regarding 1, 2 & 3 above, would it really be necessary to add another table to cater for the 1:1, 1:many relationships between a track and its releasetype entries? Even with multiple releasetype entries relating to an album could the queries not leverage WHERE releasetype LIKE '%%' ORDER BY preferred_sort_criteria and simply build out a temp table in the manner I described earlier, then feed the output of that table to the front-end? I appreciate there'll be as many additional queries as there are releasetype entries in the delimited string, but performance impact would be minimal, even more so if releasetype were indexed. It'd be " just an additional column in an existing table". All the additional scanner, update and delete query complexity would be eliminated through such an approach , and front-ends needn't do anything other than ingest the input from the back-end in exactly the same manner they do at present.

If feedback from front-end providers then indicates that it'd be useful to also pass them the releasetype associated with every query result that should also be a relatively quick thing to handle in the back-end and the front-end, which would then give those front-end providers that choose to the ability to filter by releasetype or change sort order by releasetype etc. No biggie if they're not interested, the list arrives from LMS in a manner the user would like to see it.

Regarding the questions raised under point 4:

• should we "normalise" type names or use them as is (eg. "various artists" vs. "Various Artists") Leave them as is and ignore case in the SELECT statement. There's no need for LMS to curate user's metadata - they get out what they put in. This is not dissimilar to the present status quo of 'Queen' and 'queen' being two different artists in LMS - if a user wants them merged they need to fix their underlying metadata

• should an album only be listed under the first of those types? On Cat Stevens' page, should the above album be listed once or thrice? If only once, which one?

To keep it simple the queries that build up the table that is fed to the front end runs against whatever the user specified in their delimited string. By definition that would mean an album appears in as many places as it matches keywords in their delimited string. Given multiple values, that would give them the best of all outcomes because LMS would return matches against any values they have specified is important to them.

• if we want to have a list of albums only, should the above still be listed, though we don't want to include compilations?

I'm not sure I'm following here. If a user only wanted to see releasetype = Album then they'd configure LMS accordingly and that'd be all they see. If they wanted to see both, their delimited string would include both.

• should the "compilation" type override the "compilation" flag? What if the flag is there but not the release type? I think it's important not to conflate the meaning of Compilation as a releasetype e.g. a Greatest Hits album by a specific artist/band and what I understand LMS to term a Compilation i.e. an album containing performances by various artists e.g. 'All I Ever Wanted: Tribute to Depeche Mode'. I'm not sure which you are referring to. In my library I don't populate ALBUMARTIST=Various Artists when I'm dealing with the latter. I simply add a tag COMPILATION = 1 and LMS knows how to treat the album.

• similarly there's an overlap between what some would consider a genre and this release type ("Soundtrack")

Agreed, but I'd not get caught up in that debate - if a user adds releasetype=Soundtrack to their tags and chooses to use it as a value in their releasetype delimited string, then so be it. LMS' back-end just returns the results based on their preference and their tags.

So to attempt to summarise:

1. let users define a delimited string of releasetypes they'd like an artists work to appear ordered by. If this string is left BLANK then LMS runs the same query/queries it always has to produce results
2. if not blank, write out a series of query results to a temp table, with each successive query parsing the next keyword in the delimited string. I'm guessing (and no doubt grossly oversimplifying) something along the lines of

• INSERT INTO temp_table SELECT whatever WHERE selected_artist = albumartist AND releasetype like '%keyword_1%' ORDER by whatever_the_LMS_sort order_is
• INSERT INTO temp_table SELECT whatever WHERE selected_artist = albumartist AND releasetype like '%keyword_2%' ORDER by whatever_the_LMS_sort order_is
• INSERT INTO temp_table SELECT whatever WHERE selected_artist = albumartist AND releasetype like '%keyword_n%' ORDER by whatever_the_LMS_sort order_is

4. append those albums INSERT INTO temp_table SELECT whatever WHERE artist = albumartist AND releasetype NOT IN (delimited string) ORDER by whatever_the_LMS_sort order_is
5. append appearances INSERT INTO temp_table SELECT whatever WHERE artist != albumartist and compilation != '1' ORDER by whatever_the_LMS_sort order_is
6. append compilation albums INSERT INTO temp_table SELECT whatever WHERE artist != albumartist and compilation = '1' ORDER by whatever_the_LMS_sort order_is
7. return the records from temp_table to font-end

[audiomuze]

@michaelherger I’m guessing silence is disagreement? If I’ve offended that was not my intent.

[michaelherger]

@michaelherger I’m guessing silence is disagreement? If I’ve offended that was not my intent.

No, it's not. While I agree to disagree on some aspects, there's just a lot to digest in your request. And as my family is away for a few days, I thought I'd give some of your ideas a try to better understand the issue. And to concentrate on code instead of the argument 😁.

[audiomuze]

Did you forget Album? Still think tying LMS to Musicbrainz' data model is a mistake. User defined values for RELEASETYPE would be a much better solution that could cater to the needs of the user rather than tie them to Musicbrainz. Anyone wanting to for e.g. leverage Discogs release types or their own couldn't under this method. If performance is the concern, cap the number of releasetype's your prepared to parse. In any event you know my lib, so it'd be a good indicator of how LMS would perform using releasetype.

[audiomuze]

@michaelherger I like what you've done with Composer... but you know that begs for introduction of the concept of Compositions and being able to drill down to all performances of a composition in a library.

[michaelherger]

Did you forget Album? Still think tying LMS to Musicbrainz' data model is a mistake. User defined values for RELEASETYPE would be a much better solution that could cater to the needs of the user rather than tie them to Musicbrainz. Anyone wanting to for e.g. leverage Discogs release types or their own couldn't under this method. If performance is the concern, cap the number of releasetype's your prepared to parse. In any event you know my lib, so it'd be a good indicator of how LMS would perform using releasetype.

I deliberately removed Album from that list as it should always be part of the Albums menu. If you want specific menus for Singles or EPs only you can create them using the Advanced Browse Modes plugin. I'll add a note to the description.

Is this the list you are seeing with your collection? It should be populated with custom values if available. But I don't have any in my test library. Maybe there's still a bug there. Like in other places I haven't finished yet. There's a reason why I haven't merged this yet. It's still very rough around some edges.

BTW: you might have noticed that this version will require a full wipe & rescan when first installed. It does change the database schema.

And yes, I knew this is a can of worms. And whatever I do, there will me demand for more. I wouldn't even know how to deal with compositions, where that data would be available. I mean... isn't every song or track a composition?

[michaelherger]

@CDrummond I just realised that all the browse mode changes I've been working on wouldn't work with Material... I've implemented them in Slim::Menu::BrowseLibrary - which you don't use. What would be the best approach for you to achieve the same? The albums query can report back release types and contributor roles. But you'd still have to re-implement the grouping.

I considered implementing a CLI command for this. But it's not trivial. If I didn't want to duplicate all the albums query code for all the logic around what is an album, I'd rely on that query instead. This is what I'm currently doing, and it's fine when doing it for a single artist. There rarely are more than a few dozen albums per artist. And even a few hundred won't hurt (I think of Frank Zappa...). But trying to evaluate them for a full library with potentially tens of thousands of albums, that's a problem. The query could be named artistreleasetypes - and require an artist ID. That would solve this problem...

Are you even using browselibrary query at any point?

[CDrummond]

@michaelherger Adding release type to the albums command response should be enough. I can then group, filter, or show a menu based upon that. I'm thinking of either adding a filter (allowing the user to restrict what is currently shown), or using the menu listed above - can't do abitrary grouping as can't create headers for grid view.

I dont use browselibrary as its too limited - no way to specify sort order, and returned data does not have all fields (e.g. all artists, durations, genres, etc.)

[audiomuze]

Is this the list you are seeing with your collection? It should be populated with custom values if available. But I don't have any in my test library. Maybe there's still a bug there. Like in other places I haven't finished yet. There's a reason why I haven't merged this yet. It's still very rough around some edges.

BTW: you might have noticed that this version will require a full wipe & rescan when first installed. It does change the database schema.

It is, but it's a small subsection of my library and stuff that's been recently added so the metadata isn't yet complete. I installed this as a testing instance and deleted the database, figuring a clear and rescan would be required.

Going to enrich the metadata quickly and have it rescan again and I'll revert re what I see in the list.

And yes, I knew this is a can of worms. And whatever I do, there will me demand for more. I wouldn't even know how to deal with compositions, where that data would be available. I mean... isn't every song or track a composition?

A song e.g. Hotel California written/composed by Don Felder, Don Henley & Glenn Frey is a composition. That song appearing on an album is a performance. So it's a 1:many composition:performances. But that's a discussion for another day.

[CDrummond]

Actually might be able to add headers to grid view. As long as there are not too many items then performance should be OK. So, as stated just having release type in response should be enough. Perhaps even sorting by this would also help - e.g. have Albums (these then sorted by user's criteria), then EPs (again sorted), etc. As to the sort order of release-types, guess that should just be hard-coded?

[michaelherger]

Here's what I'm currently working with:

• iterate through all the "albums" of the artist
• if the artist is of primary artist role (ARTIST, ALBUMARTIST) I'd put the album to its role type
• for albums where he's a contributor in a different role, I group by role

That creates menus by release type first, contributions second. Eg. "Albums", "Singles", "EPs", "Composer", "Track artist".

See https://github.com/Logitech/slimserver/blob/release-type/Slim/Menu/BrowseLibrary/Releases.pm#L57-L72

I haven't thought of the sort order, as in the LMS driven UIs I can't group in one menu, but have to use sub-menus (where the order would be handled). I think it'll be difficult to achieve, as my grouping is based on various criteria which can't easily be sorted without processing the grouping.

[audiomuze]

Going to enrich the metadata quickly and have it rescan again and I'll revert re what I see in the list.

@michaelherger, updated to db30e36, ran a clear and rescan and still get only the following:

[michaelherger]

Would you mind sharing your library.db with me? https://www.dropbox.com/request/T3RctyzGgNg0oFDubq6a

[audiomuze]

• if the artist is of primary artist role (ARTIST, ALBUMARTIST) I'd put the album to its role type

I think including ARTIST in addition to ALBUMARTIST causes all tracks that an artist appears in also appears under track artist:

• Where they're albumartist all albums should appear under Album
• Where they're on a track but not the albumartist and not a VA album that should appear under what I'd term Appearances rather than track artist within the Artist browse
• Where they're on a track but not the albumartist and a VA album that album should appear under Various Artists within the Artist browse

[michaelherger]

In LMS the ARTIST is usually handled like the ALBUMARTIST, isn't it? And TRACKARTIST obviously would be the track artist. Again: if I had access to your library.db I could investigate why that wouldn't work for you. In my case I don't have overlapping Albums and Trackartist appearances.

[audiomuze]

Would you mind sharing your library.db with me? https://www.dropbox.com/request/T3RctyzGgNg0oFDubq6a

Done. Apologies, I had an onsite meeting I couldn't escape.

[michaelherger]

Thanks! Trying to find the case you're referring to about ARTIST being in TRACKARTISTS. I found one such case which might be misleading: the "Monument Box Set 2013". It shows up in both categories. But that's because the artist is indeed tagged as ALBUMARTIST as well as TRACKARTIST, but not ARTIST.

If that's not the case you're referring to, please let me know what other artist I should look into.

[audiomuze]

I just pulled c681652 and ran a clear and rescan.

Here's the result of querying my own SQLite table created from ingesting tags from the exact same dataset that LMS is pointed to:

Still not seeing all entries in LMS settings:

In regards to Album browse vs Track Artist:

Track artist is essentially what we currently have with the main branch of LMS - all albums thrown into a single list?

I'm going to switch to a much smaller library subset with a handful of albums and releasetypes that include instances of an artist being albumartist and appearing on another albumartist's album and then finally also making an appearance on a "Compilation / Various Artists" album. Will revert.

[michaelherger]

Looked at "A Handful of Dust". And it comes with TRACKARTIST as well as ALBUMARTIST again. I only tag TRACKARTIST when it's different from the ALBUMARTIST. Maybe I can add something to dedupe this way in code.

Going to look into the settings next.

[michaelherger]

Multiple release types: can you share a sample file with me? I believe that what you list as one single release type value in your DB request actually are values stored separately, and the LMS scanner only sees the first one, or does return it in unexpected ways. That's why "Album\Demo" would only create "Album" etc.

[michaelherger]

Ok, ok. I guess I have to revise my earlier statement: ARTIST is not considered the ALBUMARTIST in LMS, but rather a TRACKARTIST. Which means that my grouping indeed was badly wrong so far.