Unequal artist separators on album page

[splintering]

I have a compilation disc with tracks from one artist (George Benson), sometimes accompanied by another artist. Tags are like this:

• album artist: George Benson
• artist: [accompanying artist] / George Benson

The artists tag is not set. Sort artist and sort album artist correspond to above tags, with the sort artists separated by " / " In the LMS scanner config, the "Delimiters to be used for splitting artist tags" is also set to " / " MB artist and album artist IDs are set for all those artists.

Now I have this result on the album page:

I can find no difference in the file tags that would cause this kind of different display. The only thing coming to my mind is that Miles Davis was already an album artist in my database before this album was added, while Stanley Turrentine was not (he appears only on this album). Other non-album artists on this compilation appear exactly as Turrentine.

I tried to find a pattern with other albums, but it is incoherent. Both mid-dot and comma appear as separators in different constelations. Is there any logic to it, or is there a bug in the display algorithm?

[epoupon]

Hello, I think this is likely fixed in the develop branch. I am currently refactoring things in the scanner and hope to emit a release after that.

[epoupon]

Please reopen if not fixed in v3.55.0

[splintering]

I saw this (the mid dot) again today on v 3.56. The file in question initially had two artists but only one MB artist ID, leading to LMS creating non-MB artists for both, and the UI showed them separated with a comma. After I added the second MB artist ID and re-scanned, both artists where proper MB artists, but the UI separated them with a mid dot.

Should I send the file or can I produce any logs to solve that? Maybe I remove and add the file again to see if it is reproducible...

[epoupon]

In order to match an artist name with a mbid, there must be the same count in both tags (otherwise, we can't really be sure). But the mid dot thing is quite surprising: apart from not associating a mbid to these artists, the behavior should be the same in the UI.

[splintering]

The mid dot only appeared after I corrected the MB IDs, and only for this one track. Without proper MB IDs, it was still a comma, as it is for other tracks of the same album.

I just reproduced by removing and re-adding the album in question, mid dot again appearing on the one track.

[epoupon]

Ok thanks for the info, will investigate on my side!

[epoupon]

Hello, I don't manage to reproduce, can you send me this particular file @ tmp49-tmp49@yahoo.com? Thanks!

[splintering]

I sent you a donwload link via email to that address, the file is a little big to send via email.

[epoupon]

Thanks! The file you sent me appears with its track artists separated by a comma. Would you mind sending me the version where it appears with a mid dot? (for some reason, I don't manage to properly reproduce)

[splintering]

That is the file that appears with a mid dot here... So maybe not an issue with the file, but with my library or so?

[epoupon]

Just read the conversation again. Are you using v3.56 or v3.57? The last one has more fixes related to artist parsing

[splintering]

3.56 when I added the album, but upgraded to 3.57 in between. Should I "rescan all files", or remove and add the album?

[epoupon]

Upgrading from 3.56 to 3.57 requires you to rescan your files to apply changes like that. If you just hit scan, it should automatically rescan them all

[splintering]

I added files since the update, and the first scan took very long, so I guess it did that. No change in the mid dot case though...

[epoupon]

Ah, and you use the docker version I guess?

[splintering]

That is correct.

[epoupon]

Would you mind testing the image fc3c376e? Caution: you can't rollback on 3.57.0 from this image

[splintering]

I would happily, but I need it built for arm64 (it runs on a RPi 4).

[epoupon]

Ok I have pushed 8af2d9cc then!

[splintering]

Installed, rescanned all files, still the same result.

[epoupon]

I still don't manage to reproduce with the same docker image:

Can you please send me another file of this album, split on your side with , in the UI ? So that I will have one working file and the offending file.

[splintering]

I sent you another link via email.

[epoupon]

Thanks! And can you tell me all the custom separators you have set?

[splintering]

Sure, that would be "/" and "feat."

[epoupon]

Ok, now I have both files, I understand!

Track 06: Key = 'ARTIST', value = 'Bobby Rose / Maclaine Diemer' Key = 'MUSICBRAINZ_ARTISTID', value = '9c7d8b5b-4b3d-4def-82a4-b008f91d9681;3083b0b1-947a-4750-aad0-627b0d4ed696'

Track 17: Key = 'ARTIST', value = 'Bobby Rose / Jarryd Elias' Key = 'MUSICBRAINZ_ARTISTID', value = '3083b0b1-947a-4750-aad0-627b0d4ed696;3c30d5ea-5bbf-48d0-8bc2-743849db68af'

First file parsed: each artist is assigned a MBID. Second file parsed: since MBIDs are provided, artists are matched using them (notice the wrong order here). Since the names don't match what is set in the artist tag, lms fallbacks on the mid dot output.

That's why it was always good with a single file: only the first parsed file is correct. To help you spot things like that, I can add some checks and list in the scan report the artist names that do not match previously parsed mbids.

[splintering]

Good catch!

I would say it came like this from MB, because I usually do not tinker with the artist MB IDs. I replaced the separator in the artist tag though, and I remove the artistS tag - maybe they were there in a different order...

Interestingly, the artists are matched by LMS with their proper MB ID in both cases, but they might have been matched with that on a previous file already.

Adding that to the report will be helpful for future cases.

[epoupon]

On MB, looks like there are just single artists in all tracks? https://musicbrainz.org/release/57d87e77-7ab1-4d77-a98b-fd9b67bf86b0

By the way, LMS works better with default picard settings (using both artist and artists tags), with no custom delimiter, since it has a chance to use nicer strings. Example: https://musicbrainz.org/release/40b3f258-0033-4e8b-9a53-d45310ea22d4 is displayed like that:

[splintering]

Ah, yes, then I corrected the artists from some other source and introduced the error myself. I am sorry.

I decided about 8000 tracks ago when I started switching from Kodi to LMS how to tag artists, based on how I did it before manually, using only / as a separator, and removing most feat., with and other additions of secondary artists - which is why I remove artists automatically because it is too much manual correction work otherwise.

Maybe I should reevaluate that, also looking again how they show up on the client side. Using the files also in a local library with MusicBee complicates things even more, as that parses no MB tags at all.

I need to find some universal tagging procedure for myself which also works for future products. I hope LMS will stay for as long as I live, but who knows 😉

But again, thanks for the support, and great detective work 😀

[epoupon]

In the current state of the scanner code, it is not easy to accurately report heterogeneous names for the same MBIDs. For now, I have added some debug logs to help identify them. Will think about it

[splintering]

By the way, LMS works better with default picard settings (using both artist and artists tags), with no custom delimiter, since it has a chance to use nicer strings.

It tried this again now, and it seems to work pretty well for me. One question for a better understanding: is LMS taking the delimiter from the artist string in this case for display, and applies it to the entries from the artists field?

[epoupon]

In that (ideal) case, the string in artist is used untouched, that's why you may have whatever join strings used (feat. /, ; ...)

[splintering]

Thanks for the confirmation, that is exactly what I am looking for: I mostly use / as a separator in artist, which is why I had it configured as a custom seperator. But if I do not have to worry about that because LMS reads from artists and handles whatever (reasonable) separator I put in artist, then it is perfect :-)

[splintering]

This is really beautiful (bottom line), but I got another one (middle line). I looked at the four MB IDs and they seem to be in the correct order. Ther artist string is Frank Sinatra with Connie Haines, The Pied Pipers & Tommy Dorsey and His Orchestra - maybe too complex?

[epoupon]

Interesting! Would you mind sending the file to me by email?

[splintering]

I sent you the link via email.

[epoupon]

Thanks! Indeed it looks fine only when no custom delimiter is used:

But if one custom delimiter is hit in the artist tag, it then reconstructs the string. If I remember correctly, this is because of #445. If you put Artist1 ; Artist2 ; Artist 3 in artist and set a custom delimiter ; you would like a nicer string for display.

[splintering]

I removed the custom delimiters in my LMS scanner config before scanning this file, so you say it should be displayed properly?

[epoupon]

Yes, it should be correctly parsed. Unless you have again one of these artists already parsed with another name with the same MBID? (You can try to put debug level in logs to catch this.)

[splintering]

Yes, I suspected that and looked preliminary, but will investigate deeper on my side then.

[splintering]

Sorry to ask, but how to I enable debug in the docker container? I can enter the container and probably manage to edit /etc/lms.conf, but when I restart the container then I guess the file is being overwritten? Is there any other way?

[epoupon]

See examples in https://hub.docker.com/r/epoupon/lms

[splintering]

Thanks! It was indeed a tricky typo:

Tommy Dorsey and His Orchestra vs. Tommy Dorsey And His Orchestra

Now everything looks great:

Thank you thank you thank you again :-) I fixed all my tracks now to properly use artists as recommended by you.

[epoupon]

Ah I was thinking about something like that. I will try to relax the string comparison and make it case insensitive