Currently LB uses recording MBID to identify tracks that are being listened to.
But what about audio collectors that have multiple different releases for the same recording?
For example this recording https://musicbrainz.org/recording/318cb42f-9a11-482b-a25b-529cc9466f05 appears on many different releases over many years.
The question behind that: when importing a listen to a self hosted media server, if there are multiple tracks matching this recording mbid, we cannot just associate the listen to the correct track.
Why not just using track mbid to identify the track being listened to?
Track MBIDs are much more fine grained than recording MBIDs, clearly.
However, for the context of ListenBrainz, often times we’re given nothing more than the artist name and “track name” as part of a listen and LB has the job of working out what that means and matching it to something in MB. And this is a really difficult task to get right under the best of circumstances.
If we were to try and match “track name” against track IDs, we’d almost guaranteed to get them wrong, there is just not enough information available.
This task is best left up to content resolvers that resolve MBIDs to local content – on that level there is different data available and users can decide how to resolve tracks based on their own rules for their own fine grained desires.
Thanks for your answer. I understand it may be difficult to match partial information like a track name with a recording MBID. That’s why MBIDs are for, after all!
But my point is more when the client already knows the track MBID. Today, it has to send a recording MBID and unfortunately it is less precise, and more difficult to match when synchronizing listens, as I said in the first post.
So, would it be possible to identify a listen using a track MBID, and get it back when getting the listens?
Ah! Looking for JSON Documentation — ListenBrainz 0.1.0 documentation just makes me realize this is already handled using the track_mbid field in additional_info so everything is fine
