chroma: submission error (rate limit exceeded)

[amogus07]

Problem

Running this command:

$ beet submit

Led to this problem:

[...]
chroma: acoustid submission error: error 14: rate limit (10.000000 requests per second) exceeded, try again later

Setup

• OS: Fedora Linux 43 (Workstation Edition)
• Python version: 3.13.12
• beets version: 2.8.0
• Turning off plugins made problem go away (yes/no): no

My configuration (output of beet config) is:

plugins:
 - chroma

[snejus]

@ShimmerGlass what do you think about tackling this one given that you've touched this plugin recently?

[ShimmerGlass]

sure I can have a look

[ShimmerGlass]

The pyacoustid library that beets uses for submitting fingerprint already has throttling implemented to stay under AcoustId's 3 req/s limit (thanks @semohr for the input). AFAICT the implementation is correct, so it seems like beets is behaving correctly.

However, reviewing AcoustId server code revealed that there are several rate limiters in place:

• a global one
• an application one (beets)
• a per-ip one

I didn't dive too much into the specifics, but the default rate limit of the application rate limiter has a default value of 10, suspiciously the exact value you're getting in the error message.
This leads me to believe that the beets API_KEY is being rate limited at times due to users submitting (maybe fingerprint lookups count towards this too ?) at the same time.

I believe there are several things we could do:

• implement some retry loop when we detect a rate limit, sleeping for a while before retrying
• store whether a track was submitted already in beets' db, allowing to restart the submit process with only unsubmitted tracks
• if both lookups and submits count toward the same limit, ask the fine people at acoustid whether it would be ok to have 2 different api keys for the 2 usages

@snejus what are your thoughts on this ?

[amogus07]

It seems to be working again, at least when only submitting one item. But for some reason, a few items have an acoustid_fingerprint, but no acoustid_id. That's not normal, right?

[ShimmerGlass]

@amogus07 I believe acoustid_id is set on import on acoustid match. acoustid_fingerprint is locally computed. so thats normal, you have some niche music :p

[amogus07]

it's not that niche, reimporting fixed it. Anyway, imo beet submit should check if acoustid_id is missing and set it in that case. Otherwise, something could go wrong while importing (which seems to have happened in my case), and there's no way to fix it other than to reimporting.

[snejus]

This leads me to believe that the beets API_KEY is being rate limited at times due to users submitting (maybe fingerprint lookups count towards this too ?) at the same time.

That's exactly it. With the rest of MusicBrainzAPIs we try to stay on the safe side by rate limiting every user to one request per second (given that the beets application is rate limited to 10).

[ShimmerGlass]

@amogus07 reimport "fixed" it because either:

• you didn't have the chroma plugin enabled during import of these tracks
• an error happened during lookup on import
• you submitted the fingerprints after you imported them
• someone else submitted fingerprints for these tracks in the meantime

[ShimmerGlass]

I looked some more and I believe this rate limiting issue is not limited to fingerprint submits.
Doing a few lookup tests manually I hit the rate limit error more often than not. This is not very visible during import as error are just logged as debug and ignored.
I didn't conduct extensive testing on this as this would just put load on acoustid and result in legitimate requests being ratelimited, but it seems the chroma plugin lookup on import feature is pretty broken due to this, and most users probably don't realize it.
I didn't look at the MusicBrainz plugin but I guess we do ~1 req / album on import. Acoustid lookup is per track, so more like 10-15 req / album average.