Mixed case MusicBrainz ID result in file not being added to library

[paolapersico1]

What version of Music Assistant has the issue?

2.0.4

What version of the Home Assistant Integration have you got installed?

2024.5.1

Have you tried everything in the Troubleshooting FAQ and reviewed the Open and Closed Issues and Discussions to resolve this yourself?

• [X] Yes

The problem

When trying to add files from the local storage, I got errors like this in the logs:

[music_assistant.providers.filesystem_local] Error processing A Head Full of Dreams (2015)/12 Vinyl 01/05 Adventure Of A Lifetime.flac - Invalid MusicBrainz identifier: Cc197bad-Dc9c-440d-A5b5-D52ba2e14234

All files were tagged using either MusicBrainz Picard or by Lidarr automatically (which also uses the MusicBrainz database).

Browsing the server code, I found out that this error is related to this function https://github.com/music-assistant/server/blob/main/music_assistant%2Fcommon%2Fhelpers%2Futil.py#L382-L388, which returns False when comparing lowercase UUID and IDs with some uppercase characters.

So I tried manually converting the MusicBrainz ID tags with MP3Tag to all lowercase and it solved the problem.

How to reproduce

Add file with mixed case MusicBrainz IDs from local storage.

Music Providers

Local Storage

Player Providers

Not relevant

Full log output

No response

Additional information

I raise this issue here because I think that MA should either allow mixed case IDs or clarify in the documentation that IDs should be lowercase.

What version of Home Assistant Core are your running

2024.5.4

What type of installation are you running?

Home Assistant Supervised

On what type of hardware are you running?

Generic x86-64 (e.g. Intel NUC)

[OzGav]

I assume this would have been lidarr that created this mixed case ID as the MB database doesn’t use capitals to my knowledge. Will see what Marcel says in due course as to whether he will allow for this or we specify that tags must exactly match the MB database..

[OzGav]

@paolapersico1 Im just looking at https://docs.python.org/3/library/uuid.html which refers to https://datatracker.ietf.org/doc/html/rfc4122.html

This states this in reference to UUIDs (emphasis added)

Each field is treated as an integer and has its value printed as a zero-filled hexadecimal digit string with the most significant digit first. The hexadecimal values "a" through "f" are output as lower case characters and are case insensitive on input.

Therefore, I suggest that whatever has tagged these files has not complied with the specification. I think you should raise an issue with the Lidarr. I will leave this open for a bit longer in case Marcel wants to allow for this anyway.

[paolapersico1]

@paolapersico1 Im just looking at https://docs.python.org/3/library/uuid.html which refers to https://datatracker.ietf.org/doc/html/rfc4122.html

This states this in reference to UUIDs (emphasis added)

Each field is treated as an integer and has its value printed as a zero-filled hexadecimal digit string with the most significant digit first. The hexadecimal values "a" through "f" are output as lower case characters and are case insensitive on input.

Therefore, I suggest that whatever has tagged these files has not complied with the specification. I think you should raise an issue with the Lidarr. I will leave this open for a bit longer in case Marcel wants to allow for this anyway.

I think they've already fixed it, my library was very old so I've tried all week fetching new albums and IDs appear to be all lowercase. Thank you for taking the possible issue into consideration anyway (and in general for MA, it's a wonderful piece of software!)