It's doing that because you already have a release id. It's a quick way of getting back at the associated release once found. Hit 'New Search' when the wizard starts ... or you can delete the MusicBrainz Release Id manually.

There seems to be a mixup in some releases between track ids (recoding within release) and recording ids. ie. they may be flipped. I should be able to get around this problem by matching either. I currently attempt to match both but I don't cross check. I'll look into it more today.

Not that I know of. I think its simply a case of the database being so large (good!) and that it sometimes causes inconsistencies.

I'm not sure how your originally populated the metadata but it is possible that the application was looking up tracks as opposed to releases. That method causes madness. When loading the metadata associated with a release, the XML stream contains tracks which contain recoding ids and release track ids. We support both and require at least one to match when batch processing. The release track ids which are not directly searchable on the MB site are essentially a recording id unique to the release. This data is all we have to go on. Now there are many cases where there are multiple recording ids for the same recording. Your Billy Joel tracks have references to recording ids which are not referenced when we get the release stream and they do not contain release track ids. So, they may be valid recording ids but there is no reference from the release to them. I've tried cross searching on the two id types and it doesn't help because they are correct in the stream, they're just not the ones you have.

As far as merging entities.... I would assume that inconsistencies get cleaned up from time to time. Thats one of the reasons we support an 'Import Time' for Discogs and MusicBrainz. It enables you to at least know when the data was imported so that you can write an action to test every month, six months or years to see if the remote data has changed. As long as you're importing both the track id fields you should be ok. If the recording id changes at least the release track id won't. (I've never seen it).

I will be trying again in 3.4 to standardize the descriptive names for the fields. The issue is that MB has descriptive names and internal names and that some users know and use both. We're changing the descriptive name for Track Id to Recording Id and the descriptive name for Track Position Id to Track Id. None of your settings will change as its only a descriptive name. Hopefully this is a better fit. (Not in the patch build).

Welcome to the fold 🙂