You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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.
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.
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?
The text was updated successfully, but these errors were encountered: