Love/unlove tracks support

[regorxxx]

Self explanatory.

Although some kind of exposed tag would be needed to display status via TF.

[phw]

That'll be cool for sure. The problem with this currently are the API endpoints exposed by ListenBrainz for that, they expect the recording MBID to be submitted for the loved / unloved tracks (see https://listenbrainz.readthedocs.io/en/latest/users/feedback-json.html#feedback-json-doc). So this would cause two limitations:

1. Love / unlove would in general be only available for tracks with MusicBrainz metadata
2. For MP3 which have the MB recording ID stored as UFID it would also not work

I think I had seen some discussions that they wanted to provide love / unlove endpoints that can be used with basic track metadata instead (similar to how submission works, and have LB do the matching if necessary). I need to see if I can find the discussion again, or ping the relevant people on IRC about the plans here.

But unless the endpoints changes and become more flexible I consider the existing endpoints not really suitable to be used with a general purpose player like foobar2000.

[phw]

Ok, I misremembered the discussion a bit. Originally the API only supported MSIDs (MessyBrainz IDs), which made it pretty much unusable for third-parties. The change was that it supports recording MBIDs as well. See the discussion at https://community.metabrainz.org/t/feedback-api-question/562335/5

So yes, the current state allows this to be implemented for third party tools as long as that tool has access to the recording MBID for a track. So if we accept the above limitations of making this only available for tracks with the recording ID this could be implemented. But I'll also ask if there has been considerations to make the endpoint more open to allow metadata similar to listening submissions.

[regorxxx]

Well, in practice I would say most users using foo_listenbrainz also tag their files with picard/musicbrainz plugin within foobar, so MBID requirement is not a problem I think and makes sense.

Since it only affects to the love/hate feature, an idea of design would be exposing it via contextual menus for selected tracks. For tracks without the required tag it would be greyed out, being consistent with the requirements. A warning can be added to the contextual menu using '\t[no MBID]' along the menu entry name or something like that. When having multiple selection, it would only process tracks with tags.

Finally, slso note nothing stops you to perform a lookup against musicbrainz api for non tagged tracks first, just to complete the listenbrainz data. i.e. if an user doesn't tag their files with MBIDs, then they doesn't care about exact matching of recordings, releases, etc. So only the love/hate part would be relevant here. And tracks can be easily matched with artist, date [,album] which is a minimum for the plugin anyway to export listens. So in fact ListenBrainz is performing lookups for those listens at some point, which you can do manually first. This part could be optional.

[regorxxx]

Hey, did it myself in JS, in case you wanna take a look at the implementation. Missing MBIDs can be retrieved with an artist/track lookup.

https://github.com/regorxxx/ListenBrainz-SMP/blob/main/helpers/playlist_manager_listenbrainz.js Look for: listenBrainz.lookupMBIDs listenBrainz.sendFeedback

[phw]

Thanks, looks good.It's using some experimental APIs from LB, though, not sure I'd want to publish functionality based on those currently.

Anyway, would be great to have the love functionality in this plugin. I won't have time to work on this anytime soon, though. But if anyone wants to give this a go please do. Just give a quick note here so we don't duplicate any work.