Why is Emby scan overriding settings?

[nospotify 194]

34 minutes ago, Luke said:

OK there is some special sauce happening here. Because you have fanart enabled, that forces musicbrainz to be enabled as well. This is because fanart is based on musicbrainz ids, and before we put this in place, users who had disabled musicbrainz were constantly reporting that fanart wasn't finding any images. The same also applies for audiodb. It's all based on musicbrainz ids. If you disable those, then you'll get the behavior you want.

 

I will test this in the morning. (And if you're right, there should be some indication of this in the library configuration page!)

But in the meantime the bigger question remains: why does Emby have musicbrainz lookups overwrite user implemented metadata? That just seems fundamentally wrong. Why can that not be fixed?

[nospotify 194]

 @Luke@ebr- I just don't understand: when a music library is set not to download anything other than embedded metadata for an album, why would reaching out to Musicbrainz for artist info (or a track having an embedded Musicbrainz id for any reason at all) overwrite track/album metadata, or in fact any embedded metadata at all? Everywhere in Emby, shouldn't the order of priority should be 1. user-embedded metadata, 2. externally retrieved metadata based on rules selected in library config screen? The Music Library configuration screen allows sorting of priority of all the external metadata and image retrievals. Why couldn't/shouldn't the first one just be "user-embedded metadata"? Am I still not clear on how Emby works, or why are things not implemented this way?

And I am afraid you are wrong about the scanners/fetchers. I just did a scan with every single fetcher turned off and still Emby somehow pulled in - and overwrote with - MusicBrainz ID and year data for the albums, when none of the individual music files have a musicbrainz id, before or after import/scan. What the heck is going on?!

 

[edit: looking at 2nd logfile no mention of musicbrainz - so back to my earlier question, might Emby database have artifacts from earlier imports?]

[edit2: In Emby I opened the metadata window and removed the year from album number 2 in the set. And I made sure that the MusicBrainz ID was removed from the album as well as the individual FLAC music files. Then I refresh the metadata on that folder/album in the folder screen. And now utterly bewilderingly, there is no year at all for the album. And then when I go into individual music files, even though the year is clearly in the metadata within the files, it isn't in Enby. See the two screen caps below. What is Emby doing with year metadata on a scan!?]

embyserver.txt

embyserver2.txt

01._Gesualdo_Baci_Soavi_E_Cari_Part_1.flac-metadata.pdf

Edited 6 hours ago by nospotify
added second, basic log for new import only

[Luke 42592]

I believe we have a sanity check in place to ignore unrealistic dates such as 1594. That’s probably why it is blank.

[Luke 42592]

The logs you provided do not contain any outgoing requests to musicbrainz.

[nospotify 194]

1 minute ago, Luke said:

The logs you provided do not contain any outgoing requests to musicbrainz.

Yes, that's why I'm asking whether there could be artifacts in the Emby database. I have done the Emby dance multiple times including multiple scans and even restarting the server entirely while all of these files were nowhere near the Emby library directory. So why, @Luke, is Emby still showing Musicbrainz ID, when, as you can see from the files uploaded above, there is no musicbrainz ID anywhere in the individual Flac files. How are "albums" created that would have a musicbrainz ID associated with them, when not a single one of the individual track files has that information inside it.?