Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rate Limit exceeds for some songs while Importing Metadata From Musicbrainz #10795

Closed
mixxxbot opened this issue Aug 23, 2022 · 4 comments
Closed

Comments

@mixxxbot
Copy link
Collaborator

Reported by: fatihemreyildiz
Date: 2022-07-31T12:54:51Z
Status: Confirmed
Importance: Medium
Launchpad Issue: lp1983204


I have been playing with the DlgTagFetcher. There were some songs that was having an unknown error all the time (in my branch #⁠4871), normally it returns Mixxx can't connect to MusicBrainz, Code:403, http status:-1. I tried to find out why.

And I realized that the metadata is available, I can see the respond on console but we can't fetch the metadata for some songs. These songs are generally has a lot of recordings found by AcoustIDTask (more than 10 generally). After a lot of retrying sometimes they are found if my internet connection is slowed down.

This is only happening for some songs. In my case the songs that cause rate limits are:
DVBBS & Borgeous - TSUNAMI (Original Mix) -> 16 recordings found (Always failed)
Linkin Park - Numb -> 12 recordings found (Sometimes success-sometimes failed)
Linkin Park - Numb (another version) -> 21 recordings found (Always failed)

Maybe there are more songs that can hit the rate limits in this way. Did you have this issue before?

What I suggest is, if the song has recordings more than 10 we should slow the MusicBrainz task, or maybe we can slow the task after every 4 requests. so with that we will have a chance to fix this error.

I actually tried to do it poorly and it worked, I got results for TSUNAMI. I would like to fix this issue while slowing down the process if it is okay.

What do you think?

@mixxxbot
Copy link
Collaborator Author

Commented by: fatihemreyildiz
Date: 2022-07-31T13:32:10Z


If you can approve this is a bug, I would like to work-fix and open a PR about it.

My solution is we can slow down the process after every fourth request for a second, or all requests for a half second if the recordings are more than 8-10 or all requests.

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2022-07-31T20:53:40Z


According to: https://wiki.musicbrainz.org/MusicBrainz_API#Application_rate_limiting_and_identification

MusicBrainz has a quite restrictive rate limit of one request per second.
So if a track has ten released the result will take 10 seconds, if we respect the rate limit requirements.

Picard MusicBrainz own application does only return the first release in the database.
This thoes not work for us, because often the original release is listed in later results.

Since sometimes even a track with 10 releases returns immediately, there must be some everaging code on the server. Maybe we can deal with it.

I suggest to implement the version that behaves correctly and in parallel discuss this with the MusicBrainz people. Maybe they can give us an advice.

@mixxxbot
Copy link
Collaborator Author

Commented by: fatihemreyildiz
Date: 2022-08-01T22:19:58Z


I am working to fix this issue on #4871 with the better feedback system.

For now we decided to put a delay one second for each query. Just putting this delay to the existing Tag Fetcher Dialog would be bad in use-case. So at the same time, we will have progress bar. So we can slow the task and user will notified that it is fetching the metadata.

@mixxxbot mixxxbot transferred this issue from another repository Aug 24, 2022
@daschuer daschuer added this to the 2.3.4 milestone Sep 8, 2022
@daschuer
Copy link
Member

daschuer commented Sep 8, 2022

fixed by #10874

@daschuer daschuer closed this as completed Sep 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants