Multiple artists in Local SQLite

General
1

Hey guys!
This topic has been discussed every now and then, but I couldn’t find it together with Mopidy, so here it goes.
When using Picard to tag my music, there are songs with multiple artists. ID3v2.4 uses multiple artists fields for this. However, Local SQLite can’t handle this.
So, for example the album Red Gone Wild by Redman has 23 tracks. 12 of these tracks have features, so Picard gives them multiple artist IDs. When I select Artist, Mopidy shows the artist Redman twice. Each entry has the Album Red gone wild, but one of them includes only the tracks with features (-> 12 songs) while the other one includes all the tracks.
Needless to say I only want the artist (and album) to appear once.

Did you guys encounter this issue, too?

Regards,
mancer

2

Mopidy-Local-SQLite doesn’t handle multiple artist tags, as clearly stated in the README: https://github.com/mopidy/mopidy-local-sqlite/blob/develop/README.rst#known-bugs-and-limitations
If multiple artist tags are present, this may have unexpected effects.

3

Hi tkem,

I know, thats why I posted the link.
I just found it hard to believe that I’m the only one with these issues…

4

@mancer: Oh, sorry, should have paid more attention :wink:
To find out what happened here, you’d probably have to post all tags of the tracks in question. Also, the last time I checked (several months ago), Picard did not add multiple artist tags for multi-artist tracks or albums, IIRC. So did you verify you actually got the log entries mentioned in the README? Otherwise, this may be unrelated to (lack of) multi-artist support in mopidy-local-sqlite.

5

Generally speaking, you should only get two artist entries with the same name if they have different MusicBrainz IDs. How the same track would appear in two distinct albums (if I understand correctly) beats me, though.

6

I actually did not get the log entries mentioned, that’s what made me wonder, too… but that was my last straw :wink:
I remember Kodi (versions prior Jarvis) having issues with this, too.
Let’s take this tag for example:

Unbenannt.JPG473×502 47.3 KB

Do you see anything suspicious…?

7

If you don’t get the warnings in the log, then you don’t have multiple artist tags, at least as far as gstreamer is concerned.
To list a file’s tags as interpreted by gstreamer, which is used by Mopidy, I use the following command:

gst-launch-0.10 -t filesrc location=file.mp3 ! id3demux ! fakesink

8

Thanks for the hint!
I forgot to mention that I’m storing the songs on a network drive. Can you tell me how I get it ID3 tag for a network location? gst-launch-0.10 -t filesrc location=192.168.178.172/.../03-redman-put_it_down.mp3 ! id3demux ! fakesink doesn’t do the trick…

Edit: Another strange thing I noted is that if I include the tag artistsort, I get entries for Redman for each(!) of the feature tracks + 1 entry with all the songs (-> 13x Redman) instead of just 2 entries.

9

Your network files should be mounted under the directory configured as local/media_dir, otherwise Mopidy won’t scan them.

10

Ah, gotcha!

So here’s the tag for the track that has a feature artist:
FOUND TAG : found by element "id3demux0". title: Put It Down (feat. DJ Kool) artist: Redman track count: 23 track number: 3 album: Red Gone Wild: Thee Album disc count: 1 disc number: 1 date: 2007-03-27 ID3v2 frame: buffer of 13 bytes, type: application/x-gst-id3v2-tmed-frame, version=(int)4 : buffer of 22 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 28 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 39 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 106 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 21 bytes, type: application/x-gst-id3v2-tdor-frame, version=(int)4 : buffer of 17 bytes, type: application/x-gst-id3v2-tso2-frame, version=(int)4 : buffer of 36 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 33 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 76 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 76 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 26 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 29 bytes, type: application/x-gst-id3v2-tpub-frame, version=(int)4 : buffer of 44 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 47 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 album artist ID: 1f1f6737-b930-46fc-8d25-110bb99f7490 album ID: 20e05081-5075-4697-a9cc-1c76542c5162 album artist: Redman image: buffer of 85846 bytes, type: image/jpeg, width=(int)500, height=(int)500, sof-marker=(int)0, image-type=(GstTagImageType)GST_TAG_IMAGE_TYPE_FR ONT_COVER track ID: e79248cb-a3c7-4582-a164-e8a20909e935 artist sortname: Redman feat. Kool, DJ container format: ID3 tag

An here’s one without a feature artist:
FOUND TAG : found by element "id3demux0". title: Bak Inda Buildin artist: Redman track count: 23 track number: 2 album: Red Gone Wild: Thee Album disc count: 1 disc number: 1 date: 2007-03-27 ID3v2 frame: buffer of 13 bytes, type: application/x-gst-id3v2-tmed-frame, version=(int)4 : buffer of 22 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 28 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 39 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 21 bytes, type: application/x-gst-id3v2-tdor-frame, version=(int)4 : buffer of 17 bytes, type: application/x-gst-id3v2-tso2-frame, version=(int)4 : buffer of 36 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 25 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 76 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 76 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 26 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 29 bytes, type: application/x-gst-id3v2-tpub-frame, version=(int)4 : buffer of 44 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 47 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 album artist ID: 1f1f6737-b930-46fc-8d25-110bb99f7490 artist ID: 1f1f6737-b930-46fc-8d25-110bb99f7490 album ID: 20e05081-5075-4697-a9cc-1c76542c5162 album artist: Redman image: buffer of 85846 bytes, type: image/jpeg, width=(int)500, height=(int)500, sof-marker=(int)0, image-type=(GstTagImageType)GST_TAG_IMAGE_TYPE_FRONT_COVER track ID: 208210c3-5b5d-46e2-a594-0081808931bb artist sortname: Redman container format: ID3 tag

Seems to me as if gstreamer can’t read the artist ID for the track with the feature artist (-> should have 2 artist IDs, instead it has none).

11

Thanks for bearing with me, now this gets a lot clearer :wink:
As I said before, artists with the same name but different MusicBrainz IDs are treated as distinct artists. Following SQL tradition, artists with no MBID are also treated separately. If gstreamer only returns the ID for tracks without features, you’ll therefore get two “Redmans”.
Support for artist “sortname” was introduced in Mopidy v1.0, IIRC. Since then, artists with different sortnames are also treated separately. This all works fine when your tagger uses something like “Redman feat. XY” as artist name, as for example beets does. I last tried Picard several months ago without noticing this, so this might have changed in recent versions if Picard.

12

Reading up on this, the “ARTISTS” (plural) tag that you/Picard are using here, according to your screenshot, seem to be nonstandard. Chances that other media players/tools understand them are therefore pretty low. Kodi 16.0 seems to include support for this, but whether this will ever be supported by gstreamer (and Mopidy) I don’t know.

13

IIRC Picard puts the “feat.” as artist name by default, I just use a plugin script to put the “feat.” into the title tag, so I only have Redman 1x in my library instead of 100x with every feature.

However, the question for me is why gstreamer doesn’t return MB IDs for tracks the with the feature. Picard uses ; as a divider - could it be the gstreamer can’t handle this?