[scott967]

I seem to be getting a similar/same problem.

It appears that the tags being read are different to the tags being displayed in the library.

As a result the same artist can be listed multiple times this appears to happen where multiple artists are involved in the creation of one track

I think the display is showing the Album Artist, but the grouping is based on the Artists tag.

A solution nearer to perfection, but not impossibly difficult would be to have a library view for each tag, so we could have Artists as a library view, using the Artists Tag and displaying the Artists Tag and to have a separate Album Artists view, displaying the Album Artists tag. Extending this concept we could have a Release Country view a Record Label View and if we made custom tags we could even use those. I doubt anyone would want all possible views, so perhaps you might need to fiddle with the config to get any thing exotic such as a year-month view or the record label view.

Perhaps the way to do it would be to provide a name for the tag view, The tag for the view and a regular expression to apply to the tag.

I guess there is an issue with multiple artists in that you want the track to appear under each artist when in artist view. Perhaps having multiple reg ex captures to extract multiple values from a single field and create multiple indexed entries in the library.

First, you have the settings option to show compilation artists or not. Effectively, that allows the option of showing just "album artists" or both "artists" and "album artists" (but, not as "views" per se).

Note that there is an "artist" tag (text string) and Kodi by default uses the text string " / " to separate multiple artists (for tag formats which don't allow multiple instances of an "artist" tag).

The text string for each artist is stored in 2 places in the database: the artist table and the song_artist table. I'm not sure having two different database attributes for the same logical concept is a good database design (but I'm not an RDBMS guy so leave that for others) but that's the way it is.

You have the option as user to store the artist text string as found in the tag, or to supply an MBID and accept whatever MB has determined is the "correct" text string (override tag option). As it happens, the design seems to be that only the text string in the artist table is changed based on override tag with MBID, not the one in the song_artist. I don't know the reasoning, but assume that this was done because the artist table is the one used for storing the "additional info" for an artist and that is really why MBID was added, to aid in finding the correct additional artist info.

Note that MusicBrainz employs devices such as an "alias" attribute to provide more flexibility to set whivh text string is used for an artist (this is quite useful for example when an artist name has both a latin1 script text string and another text string using some other script).

Any change to this is a fairly extensive undertaking, maybe an idea for Kodi 15. It will have to compete with other ideas for music library changes, such as better handling for classical music.

Separately, there is the question of the semantics of the connective "feat.". The song_artist table does have a boolean featured attribute for each song_artist, but I don't know exactly how that attribute gets set. That might be something that needs to be looked at.

scott s.
.