Overcoming API rate limiting

MusicBrainz Development
1

can you explain this a bit?

A new MusicBrainz user script was released
2

The ‘resource’ parameter can be specified multiple times (up to 100) in a single query

The response will contain a url-list in this case, rather than a single top-level url, and any ‘resource’ that is not found will be skipped.

When fixing the original script this was one of the first things that had to be improved because I quickly ran into Chrome’s own throttling mechanism while testing and querying one URL at a time was way too slow for my taste. (Beatport can display up to 150 releases per page)

1 Like
3

they should do that for all things so you can always request multiple stuff (of any type)

4

You mean something like this?

5

i think so, for me it is mainly to get information quicker when parsing events like festivals and stuff.

for example:
if i want to get everything on rock herk 2025 Rock Herk 2025 - MusicBrainz
i have to request all these individually:

  • main event
    • day1
    • day2
      • day1stage1
      • day1stage 2
      • day1stage 3
      • day1stage 4
      • day2stage 1
      • day2stage 2
      • day2stage 3
      • day2stage 4
        so that is 11 requests as 1 request per second that = 11 seconds.

if i could group them i would end up at:

  • main event
    • day1 + day2
      • day1stage1 + day1stage2 + day1stage3 + day1stage4 + day2stage1 + day2stage2 + day2stage3 + day2stage4

this way i would ALWAYS (or almost always) have the full event in 3 requests.

if i would for example change to graspop 2025 Graspop Metal Meeting 2025 - MusicBrainz
it has 1 main event, 4 Day events, 6 stage events each day.
that totals to 1 + 4 + (4x6) = 29 requests

while if i could do multiple stuff it would be 3
1 of the main event that tells me the id’s of all the days
1 of all the days that gives me the id’s of all the stages for each day
1 of all the stages from all the days

going from 30 seconds waiting to load everything to 3 seconds would make a HUGE difference

2 Likes
6

I already requested that: https://tickets.metabrainz.org/browse/MBS-13963

7

the idea of getting a full event in 1 request would be nice, but that then ideally should work in both directions. (if i request a day/stage event i want the parent and parent-parent aswel).

but i think the solution provided in the comment feels bigger then just events, by just being able to do a lookup with multiple id’s you would get multiple responses at once.

this then could also work for artists, if for instance you want to lookup the members of a band, you can get all the members information from all members with just one request.

8

Yeah my plugin would work great with this. I’m working with a music player (specifically MusicBee) and I have to do multiple requests just to retrieve data. I tried what I could to mitigate this, but ultimately this would be the ideal option. (sending data is completely fine)

It seems like on the other ticket, someone did commit something in 2017(!!) under the json-dump branch, but it doesn’t seem to have been merged into the main branch. :confused:

2 Likes
9

BTW, You can do burst requests.
For alistral I set the rate limit to be 5 token, with a recovery of 1 token per second. So you can use user input/data processing to recover some tokens, making the app look more snappy.

… Until you need to fetch 5000 recordings… 1 request per second…

2 Likes
10

Honestly, all of the enhancement requests to the API will just reinvent GraphQL but in URL parameters.

2 Likes
11

Never used graphql, but if it allows for faster fetching, I want it!

1 Like