Display artist

[darrell-k]

Objective:

To capture the "human readable" artist tag from eg Musicbrainz as well as the underlying list of individual artists and provide this data to clients.
eg
ARTIST="Bill Evans Trio with Scott LaFaro and Paul Motian"
ARTISTS="Bill Evans; Scott LaFaro; Paul Motian"

Design:

New table contributor_display to hold these display names. Rows will not be created in the existing contributor table.

New join tables contributor_track_display and contributor_album_display to relate contributor_display.id to the tracks/albums and the actual contributors below the display name.

New columns in the albums and tracks tables to hold contributor_display.id.

Amend queries to return the new data.

Add the display artist to FTS album and track rows.

The scanning changes will be optional, with a new preference, in case users have already fixed their tags and do not want this functionality.

With thanks to @Rouzax

[Rouzax]

Also wanted to leave my draft documentation here as well
https://github.com/Rouzax/slimserver/blob/docs/artist-tags/docs/artist-tags-in-lms.md

[michaelherger]

I'm sorry, completely forgot about this PR 😖

New table contributor_display to hold these display names. Rows will not be created in the existing contributor table.

New join tables contributor_track_display and contributor_album_display to relate contributor_display.id to the tracks/albums and the actual contributors below the display name.

New columns in the albums and tracks tables to hold contributor_display.id.

Hmm... why would you have a direct albums -> contributor_display link AND with a join table?

Add the display artist to FTS album and track rows.

Is it worth this effort? Are you expecting many display names which would not be covered by the individual contributors? Eg. would you expect people to tag (just a stupid example) the display name as "The Beatles", and then the Fab Four as the actual artists?

I'll have to check out the code changes when I'm back at my computer.

[darrell-k]

There may be further changes, will get back to developing/testing this with @mikeysas once @CDrummond has made the Material changes based on #1585 that you just merged. Everything is connected!

[michaelherger]

Probably a question which has been discussed before, but it just crossed my mind while riding home: Couldn't the display name just another role? They would show up in the contributor tables like everybody else, just with this new role?

[darrell-k]

Probably a question which has been discussed before, but it just crossed my mind while riding home: Couldn't the display name just another role? They would show up in the contributor tables like everybody else, just with this new role?

It's a container for artists or albumartists. The UI implementation will be that clicking the display name will pop up a list of the actual contributors.

[mikeysas]

Probably a question which has been discussed before, but it just crossed my mind while riding home: Couldn't the display name just another role? They would show up in the contributor tables like everybody else, just with this new role?

It's a container for artists or albumartists. The UI implementation will be that clicking the display name will pop up a list of the actual contributors.

I will defer to you and @mherger as to the better approach, but would there be an advantage to creating a role and then adding an additional column to the contributor_track and contributor_album tables for the display value to handle the relationship and UI logic?

[michaelherger]

It's a container for artists or albumartists. The UI implementation will be that clicking the display name will pop up a list of the actual contributors.

I will defer to you and @mherger as to the better approach, but would there be an advantage to creating a role and then adding an additional column to the contributor_track and contributor_album tables for the display value to handle the relationship and UI logic?

That's exactly why I was wondering about this (in my uninformed opinion) simpler approach: no schema changes would be needed! You can already have as many contributors in as many roles as you want. There might be a need to treat the display name somewhat differently from other roles. But I'd assume this to be much simpler than dealing with a completely new table and other schema changes.

But as @darrell-k is still working on this I'll go back to lurking mode 😄.

[mikeysas]

That's exactly why I was wondering about this (in my uninformed opinion) simpler approach: no schema changes would be needed! You can already have as many contributors in as many roles as you want. There might be a need to treat the display name somewhat differently from other roles. But I'd assume this to be much simpler than dealing with a completely new table and other schema changes.

But as @darrell-k is still working on this I'll go back to lurking mode 😄.

The current design is built on a rule that a given contributor role on a track (or album) there can only be a single display name value in the singular tag (ARTIST) that represents the collection of one or more values in the plural tag (ARTISTS). This is enforced to point that if ARTIST contains multiple values by delimiter or tag values, the multiple values are treated as contributors like currently in 9.1.x and the plural tags (if any are if ignored). This is also a good thing as it protect current users from being impacted by this change defaulted on.

The DB design that @darrell-k implemented enforces this rule by design. With the role approach I guess technically the data could break this rule although that should only happen if some manipulated the db externally or some other problem, but would the code have to account for that possibility also.

I don’t have an opinion here. I am just sharing my thoughts out loud as it is interesting to me.