Beets: mbcollection: Cannot add to a collection of "recordings"

[hashhar]

Use case

I'm trying to use beets' mbcollection plugin to push my library's tracks (recordings in MB terminology) to a collection of type recordings.

I get an HTTP 400: Bad Request when using the collection id for a Recording Collection but it works fine with a collection id for a Releases Collection.

Solution

Add support to mbcollection plugin to be able to handle collections of recordings too. I can see that the MB web service has an API for the same but it looks like the python bindings don't expose all the knobs on it. From the docs at https://musicbrainz.org/doc/Development/XML_Web_Service/Version_2

collections

To add or remove releases (for example) from your collection, perform a PUT or DELETE request to /ws/2/collection//releases, respectively:

PUT /ws/2/collection/f4784850-3844-11e0-9e42-0800200c9a66/releases/455641ea-fff4-49f6-8fb4-49f961d8f1ad;c410a773-c6eb-4bc0-9df8-042fe6645c63?client=example.app-0.4.7
DELETE /ws/2/collection/f4784850-3844-11e0-9e42-0800200c9a66/releases/455641ea-fff4-49f6-8fb4-49f961d8f1ad;?client=example.app-0.4.7

Other types of entities supported by collections can be submitted, too; just substitute "releases" in the URI with one of: areas, artists, events, labels, places, recordings, release-groups, or works, depending on the type of collection.

Proposal

1. Upstream a change to the Python bindings to pass identifiers allowing the handling of all types of collections.
2. Introduce a new key to the mbcollection plugin config called type which can be one of areas, artists, events, labels, places, recordings, release-groups, works, or releases.
3. Use the config in the plugin to decide which metadata field to submit to MB API.

Alternative

1. Upstream a change to the Python bindings to pass identifiers allowing the handling of all types of collections.
2. Create a new plugin for this.

[hashhar]

I need this feature and am willing to see this to completion. I just wanted the opinion of the maintainers on what they think is the best way forward in this scenario so that I we can arrive at a conclusion and I can start implementing.

[sampsyo]

Awesome; sounds great to me!

[hashhar]

Just FYI, I've started work on this for the musicbrainzngs part which interested people can follow along at https://github.com/hashhar/python-musicbrainzngs/tree/extended-collections.

[hashhar]

The PR for upstream is open now at https://github.com/alastair/python-musicbrainzngs/pull/259.

I'll try and integrate the changes into beets now to test it all end to end and wait for upstream to merge it and release a new version.

[hashhar]

Hi @sampsyo, since the PR upstream isn't merged yet I didn't start work on this yet.

But seeing as how it's a trivial change and the API is unlikely to change, I'll start work on this anyway this weekend.

Just wanted to check with you regarding how beets currently handles MusicBrainz ratelimits? Since submitting a collection of recordings for the same number of albums can take potentially more API calls compared to collection of releases I expect some people to run into ratelimits.

[sampsyo]

OK, too bad! Thanks for looking into it though.

The API library rate-limits internally:
https://github.com/alastair/python-musicbrainzngs/blob/e4bca39720c7c0a1de38b1663faa3475cf5b7eff/musicbrainzngs/musicbrainz.py#L372

Perhaps it would make sense to use that same infrastructure—either by reusing the decorator or the low-level API wrapper functions that already use that limiting functionality.