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
Actually I still have the same “issue” for the love/hate feedbacks, as it is based on recording_mbid.
When importing a feedback from LB on the media player, does this mean we automatically want to mark the same feedback for all the tracks that share this recording_mbid?
That would make sense, but that’s also more work for the player when feedbacks are sent: setting a feedback on a track will require to apply the same feedback on other tracks that share the same track_mbid.
Essentially all of the LB features are based around recordings rather than tracks, therefore it would be best to work with only recording_mbids when interacting with LB. While submitting listens, its recommended to send all info you can send but FWIW we don’t make any use of the track_mbid at the moment.
I think if you have track_mbids available, you probably also have recording_mbid available in the metadata. If not, and a track → recording and recording_mbid → track_mbids translation API doesn’t already exist, we can look into adding such an API to help.
