Hi!
I’m wondering: what is the difference between update and mbsync? I have a music collection that is tagged uniquely using musicbrainz (as far as I know) but if I run beet up and beet mbsync after one another they find discrepancies.
As an example, this track was tagged with beet up and then with beet mbsync, that’s what mbsync modified:
Isaac Albéniz - Albéniz: Iberia / Granados: Goyescas - Iberia Suite, B. 47: V. Almería
albumstatus: official -> Official
original_day: 00 -> 15
composer: Albeniz (1860-1909) -> Isaac Albéniz
tracktotal: 10 -> 19
albumartist_credit: -> Albéniz, Granados; Alicia de Larrocha
original_month: 00 -> 01
composer_sort: -> Albéniz, Isaac
original_year: 0000 -> 1996
language: -> spa
work: -> Iberia, B. 47: Book II: II. Almería
label: -> Decca Classics
albumtype: album -> compilation
artist_credit: -> Isaac Albéniz
I don’t specify any source for the musicdata and I don’t use any plugin for discogs or similar, what is happening?
Regards,
Dorian
Edit: I use a slightly different version of beets (with parentwork plugin and additional work and work_id tags), but this shouldn’t change anything and I noticed this also on the regular beets.
Thanks! Now I understand it better. I’m also wondering: on MusicBrainz, there are very regular merges of recordings and albums (I have a 40k music collection and I get 50-100 merges every day) that change the mb_trackid and mb_albumids of the recordings. Does mbsync see and reflect an eventual change in mb_trackid and mb_albumid ? This is not a problem as far as fetching the data is concerned, since the old mbids redirect to the newer ones, but it doesn’t interact well with the duplicates plugin, since he uses the mb_trackid and mb_albumid as default keys. That could mean trouble if one adds a recording to the database that is already in the collection, but after some process the mbid of the recording changed. Then they wouldn’t be recognized as duplicates anymore. On the other hand mb_trackid is the most sensible choice for tracking duplicates if one uses MB as a metadata source.
Do you know if this could be a problem? I’m asking because I never noticed a change in mb_trackid fields and I noticed today that I have quite a few undetected duplicates and I wonder if it might be because of that.
Hi!
I finally found an occurence of mb_trackid: 33f1f557-d44b-4c5d-9087-5b6539f18843 -> d49b09ef-3771-4d6d-8111-1f3a3f72ca58 so I guess this is settled.
It doesn’t seem to be fully settled finally: I have a dupe with different trackids: one with f97bc3ca-9ae7-42d5-bbbc-df6813b3f4db an the other with f2d7c3a1-1cb5-407d-94b0-7590e98b9aa1 that both correspond to the same recording, but at other times I see that the mb_trackid is updated. There seem to be some cases where the update doesn’t work. I’m checking it more in detail.
It’s pretty strange: mbsync calls beets.autotag.hooks.track_for_mbid(recording_id) which calls beets.autotag.mb.track_for_id(releaseid)which calls musicbrainzngs.get_recording_by_id(trackid, TRACK_INCLUDES) and feeds the output of this into beets.autotag.mb.track_info, where it is shoved into a beets.autotag.hooks.trackinfo object by doing info = beets.autotag.hooks.TrackInfo(recording['title'], recording['id'],...)
I checked the result of musicbrainzngs.get_recording_by_id(trackid, TRACK_INCLUDES) for this specific example and it returned the correct trackid (i. e. the updated trackid in case of a merge). This should settle it once and for all, and I don’t know what happened with the 9 tracks that were reluctant to adapt (they didn’t only not update the track_id, their title was also obsolete and corresponded to an older tracklist).