Musicbrainz queries sometimes fail to find correct release in 2.4.0

[natchapman]

Importing AJJ's album Disposable Everything fails in 2.4.0, when it succeeded in 2.3.1:

[user@host music]$ beet version
beets version 2.4.0
Python version 3.13.7
plugins: musicbrainz
[user@host music]$ beet config
musicbrainz:
    source_weight: 0.0
    search_limit: 5
    host: musicbrainz.org
    https: no
    ratelimit: 1
    ratelimit_interval: 1
    genres: no
    external_ids:
        discogs: no
        bandcamp: no
        spotify: no
        deezer: no
        tidal: no
    extra_tags: []
disabled_plugins: []

[user@host music]$ beet import -t ajj/

/home/user/downloads/music/ajj (14 items)

Finding tags for album"AJJ - Disposable Everything".
  Candidates:
  1. (43.8%) Simon Bookish - Everything/Everything
             ≠ tracks, artist, unmatched tracks, ...
             MusicBrainz, CD, 2008, DE, Tomlab, TOM121, None
  2. (36.0%) Underworld - Everything, Everything
             ≠ tracks, unmatched tracks, artist, ...
             MusicBrainz, CD, 2000, US, Junior Boy’s Own, 63881-27078-2, None
  3. (36.0%) Underworld - Everything, Everything
             ≠ tracks, unmatched tracks, artist, ...
             MusicBrainz, CD, 2000, AU, Junior Boy’s Own, JBO1012542, None
  4. (24.7%) 遊佐春菜 - everything, everything, everything
             ≠ unmatched tracks, artist, album, ...
             MusicBrainz, Digital Media, 2022, XW, None, None, None
  5. (24.0%) Have a Nice Day! - Everything,Everything,Everything
             ≠ unmatched tracks, artist, album, ...
             MusicBrainz, Digital Media, 2018, XW, None, None, None
➜ # selection (default 1), Skip, Use as-is, as Tracks, Group albums,
Enter search, enter Id, aBort? b

The musicbrainz plugin added an additional parameter of alias: album to the query, presumably to help resolve an issue where the files are tagged with the alias instead of the canonical name. I don't see any reason this shouldn't work, but for whatever reason sometimes the musicbrainz api hates it:

album, artist, tracks works, album, alias, artist, tracks does not.

changing the query to (album OR alias) AND artist AND tracks works, but means that if e.g. there's missing tracks, the search fails, so i'm not sure what a good solution is

[snejus]

I've noticed this issue too. The PR that introduced the behaviour you mentioned: #5821.

I'm indeed leaning towards making this an OR query.

if e.g. there's missing tracks, the search fails, so i'm not sure what a good solution is

Could you expand a bit more about this? I'm not sure I understand what you meant

[natchapman]

so the default query is an implicit OR: "album:(disposable everything) artist:(ajj) tracks:(13)" == "album:(disposable everything) OR artist:(ajj) OR tracks:(13)" which still works even though the album actually has 14 tracks [link]

the thing that makes the final query work is changing it to AND, which means that if tracks:(13) is false the whole query breaks and you get no results at all [link]

which might be preferable to garbage results, but is much worse than the result you get from excluding the alias parameter

[snejus]

We've got an open PR #6052 where we drop musicbrainzngs and query MB API directly, so we will have the flexibility to form the query we want.

I'm thinking about making the tracks filter opt-in (using musicbrainz.extra_tags) and using (album:<album-query> OR alias:<album-query>) AND artist:<artist-query> by default.

For each configured musicbrainz.extra_tags we can add an AND condition, e.g., ... AND tracks:13.

What do you think?

[natchapman]

i do genuinely think this must be a bug in musicbrainz, because the all ORs query works fine for most cases, and i can't figure out why this one doesn't. perhaps it's worth submitting a ticket upstream and accepting a small number of broken queries in the short term, since they can easily be fixed by entering the release id manually.

one thing that does work for at least this specific case is very slightly boosting the release name over the alias. [link] it doesn't break the only other query i tried [link] and it keeps the example in that pr in the first slot [link]

i'd want to do quite a lot more testing before accepting that solution though (and imo it implies even more that this is a musicbrainz api bug)

[natchapman]

We've got an open PR #6052 where we drop musicbrainzngs and query MB API directly, so we will have the flexibility to form the query we want.

this is also possible using musicbrainzngs, you'd craft the query and call e.g. search_releases(query, limit=limit) instead of search_releases(limit=limit, **fields). if you don't include any fields, the query is used verbatim. might be able to do that while the larger re-write is happening

[catap]

See: https://musicbrainz.org/doc/MusicBrainz_API/Rate_Limiting#:~:text=We%20allow%20through%20300%20requests,(http%20503)%20the%20rest.

It has a global limite for all clients, and... thanks all that LLM, it can be, sometime, just overload and return 503.

Probably beets need to make more than one attempt to call it.

[natchapman]

this bug has nothing to do with rate limiting, the links i posted in october still return the same results they did two months ago