Still receive the warning “too many requests”

[Mondmarmelade]

I get a "too many requests" warning every 10 seconds. I thought the bug was fixed in version 1.3.0.

Screenshots & Logfiles

Versions:

• Adapter version: 1.3.1
• JS-Controller version: 5.0.16
• Node version: v18.17.1
• Operating system: linux (docker)

[aruttkamp]

Hello Mondmarmelade, yes, i fixed this. feedback from other users is positive. please verify version of adapter and please send me your configuration of the adapter. ( Screenshot )

[aruttkamp]

@Mondmarmelade - please send your configuration.

[ManiacKill]

Good Morning,

I have the same problem.

[aruttkamp]

@ManiacKill @Mondmarmelade Welche Admin Version setzt Ihr bitte ein ?

[aruttkamp]

I can't reproduce the error in my system. I am using the adapter in my normal environment and i do some tests in my testsystem just now.

Can anyone give me an tip how to reproduce this ?

[c-hum]

~~Also had this problem and did the following: Deleted all objects in spotify-premium.0. Afterwards restarted the adapter (objects were generated new) and then I reauthorized through instace settings. Since some days the error did not come again. Perhaps worth a try ;-)~~

Problem showed up again today :-(

Admin v6.13.15 Settings:

One thing I changed after it seem to work was that I started to use VIS again to send commands to the adapter. E.g. I used spotify-premium.0.getDevices & spotify-premium.0.getPlaylists more often.

[ManiacKill]

Admin Version 6.12.0

[n1tr0-5urf3r]

Hi there! I got the same issue. My settings in the Spotify iobroker instance are all set to the recommended ones. I am using the jarvis adapter for my visualization. From there I am using the "MediaControl" widget, which links to the spotify premium iobroker adapter. I noticed that the "too many requests" log entry only occurs when the visualization is loaded somewhere, e.g., if I open the webpage of jarvis and the Spotify media control is displayed. I further noticed that the adapter causes a lot of DNS queries during the same period. Approx. 10000 queries to api.spotify.com (A and AAAA). Probably that helps you in reproducing it. I am using js-controller 5.0.17, admin adapter 6.12.0, spotify adapter 1.3.1 and jarvis 3.1.8

[aruttkamp]

Probably that helps you in reproducing it. I am using js-controller 5.0.17, admin adapter 6.12.0, spotify adapter 1.3.1 and jarvis 3.1.8

Yeah. i think that will help. i try to fix it - but it will take a few more days.

[Technology89]

Hi, any news on that?

[mcm1957]

@aruttkamp

Are you still working on this? Seems to be a problem affecting more than one user:

https://forum.iobroker.net/topic/69146/spotify-too-many-requests/27

[aruttkamp]

Yes, i am still working on this. last weeks there was no time left beside my job - sorry.

[n1tr0-5urf3r]

@aruttkamp I tracked the issue down a bit.

I think the problem is that in your implementation:

1. A request is sent every statusPollingDelaySeconds seconds
2. If this request is replied with a http 429 tooManyRequests, you a. Check for the retry-after in the reply header b. Wait that time and then send a new request

But in this implementation, a new request is sent after statusPollingDelaySeconds. This results in another tooManyRequests response and an increased timeout.

I suggest adding a global flag like tooManyRequests that is set when you get a 429 code and reset when the timeout is over. We then need to check for this flag in the sendRequest method and only send a request if it is not set.

I have a possible fix in my development branch: https://github.com/n1tr0-5urf3r/ioBroker.spotify-premium/commit/69bf32fa5f8260a99ec35459e898385cb05be648, but I have not been able to verify it because the problem is not happening for me at the moment. I'll create a PR for a beta if you want.

Edit: Correct me if i missed something in your code and this is not the actual issue :P

[n1tr0-5urf3r]

Update after I've run in the "too many requests" again: The backoff seems to work, meaning that the API is not continuously queried after rate limitting ... But the main issue why we go into rate limitting is the querying for playlists, more specifically the getPlaylistTracks function. I will do some more debugging

[n1tr0-5urf3r]

After carefully observing the behaviour of my adapter for the past week, I think its fixed now. The playlist update interval should be increased to a higher value, maybe to ~60 minutes depending on the number of playlists and songs in a playlist.

For each playlist, an API call is sent for every 50 songs in that playlist. This can result in a lot of API calls at once leading to the 429. I got some more updates in my PR.

[mcm1957]

fixed with 1.5.0