epoupon
Unequal artist separators on album page
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?
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.
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...
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.
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.
Hello, I don't manage to reproduce, can you send me this particular file @ [email protected]? Thanks!
I sent you a donwload link via email to that address, the file is a little big to send via email.
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)
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?
Just read the conversation again. Are you using v3.56 or v3.57? The last one has more fixes related to artist parsing
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?
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
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...
Would you mind testing the image fc3c376e? Caution: you can't rollback on 3.57.0 from this image
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.
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.
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.
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:
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 😀
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
By the way, LMS works better with default picard settings (using both
artistandartiststags), 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?