[GH-ISSUE #779 ] Exceeded API request limit #310

Author

Owner

@rogeruiz commented on GitHub (Jun 9, 2021):

I'm experiencing this as well. I believe it's just a limitation that Spotify puts on their API requests. I am not entirely sure what approach I'm going to use to figure out how to fix this. I may wrap my usage of spt pb in an interval function which only runs if a certain amount of time between the last run has passed? I'm not entirely sure how I will implement this.

I know I ran into this issue because I was calling spt pb in my Tmuxline every second in order to output what song was playing. I am considering using spotifyd and it's event on_song_change_hook to unblock the spt pb call to leverage the API rather than the local file I will generate on the first call of spt pb.

As I stated before, I'm not sure if it's in scope of this repository. Perhaps the only thing I can think of is that spt pb checks for the Retry-After header and makes sure it doesn't issue any requests until after that time. I believe that hitting the API within your time window Spotify replies with resets how long you have to wait for all over again, but I haven't done testing of that hypothesis.

@rogeruiz commented on GitHub (Jun 9, 2021): I'm experiencing this as well. I believe it's just a limitation that Spotify puts on their API requests. I am not entirely sure what approach I'm going to use to figure out how to fix this. I may wrap my usage of `spt pb` in an interval function which only runs if a certain amount of time between the last run has passed? I'm not entirely sure how I will implement this. I know I ran into this issue because I was calling `spt pb` in my Tmuxline every second in order to output what song was playing. I am considering using `spotifyd` and it's event `on_song_change_hook` to unblock the `spt pb` call to leverage the API rather than the local file I will generate on the first call of `spt pb`. As I stated before, I'm not sure if it's in scope of this repository. Perhaps the only thing I can think of is that `spt pb` checks for the `Retry-After` header and makes sure it doesn't issue any requests until after that time. I believe that hitting the API within your time window Spotify replies with resets how long you have to wait for all over again, but I haven't done testing of that hypothesis.

kerem commented

Author

Owner

@AckslD commented on GitHub (Jun 10, 2021):

@rogeruiz Yeah, my issue was the same, I want to display what song is playing in my status bar. I did this previously with ncspot by querying every second or so. If would indeed be nice if spotify-tui could store the information of the current song locally so that one can query it without the need for the query to go through the Spofify API every time. I don't know how the spotifyd events work but it seems like this local information could be updated whenever the on_song_change_hook triggers.

@AckslD commented on GitHub (Jun 10, 2021): @rogeruiz Yeah, my issue was the same, I want to display what song is playing in my status bar. I did this previously with [ncspot](https://github.com/hrkfdn/ncspot) by querying every second or so. If would indeed be nice if `spotify-tui` could store the information of the current song locally so that one can query it without the need for the query to go through the Spofify API every time. I don't know how the `spotifyd` events work but it seems like this local information could be updated whenever the `on_song_change_hook` triggers.

kerem commented

Author

Owner

@crypticC0der commented on GitHub (Jun 18, 2021):

yeah i have had this, no workaround either

@crypticC0der commented on GitHub (Jun 18, 2021): yeah i have had this, no workaround either

kerem commented

Author

Owner

@rogeruiz commented on GitHub (Jun 19, 2021):

@AckslD and @crypticC0der Mulling this over a bit more, I don't think this is in scope for this project. I'd consider closing this issue as there are a number of ways, especially on macOS, to be able to do this without using spotify-tui. I believe the best course of action here is to add some information to the README documentation to warn folks that this may cause them to hit the Spotify API rate-limiting if they decide to use it to query for what's currently playing. I'll work on a PR for that documentation, but my original comment is a moot point and I don't agree that spotify-tui needs to actually solve this problem.

@rogeruiz commented on GitHub (Jun 19, 2021): @AckslD and @crypticC0der Mulling this over a bit more, I don't think this is in scope for this project. I'd consider closing this issue as there are a number of ways, _especially on macOS_, to be able to do this without using `spotify-tui`. I believe the best course of action here is to add some information to the README documentation to warn folks that this may cause them to hit the Spotify API rate-limiting if they decide to use it to query for what's currently playing. I'll work on a PR for that documentation, but my original comment is a moot point and I don't agree that `spotify-tui` needs to actually solve this problem.

kerem commented

Author

Owner

@dvignoles commented on GitHub (Jun 24, 2021):

I'm running into the API limits as well except I have not used spt pb whatsoever. I've been using the client normally with spotifyd, without any status bar scripts or anything like that. I checked my spotify developer dashboard and the requests to v1/me/player are causing the problem.

@dvignoles commented on GitHub (Jun 24, 2021): I'm running into the API limits as well except I have not used `spt pb` whatsoever. I've been using the client normally with spotifyd, without any status bar scripts or anything like that. I checked my spotify developer dashboard and the requests to `v1/me/player` are causing the problem.

kerem commented

Author

Owner

@rogeruiz commented on GitHub (Jun 24, 2021):

Thanks @dvignoles could reproduce your use some more, please? More information like how you use the app, do you keep it open or open it on demand? Etc etc.

Thanks for mentioning you were only using the TUI interface and not the playback functionality.

It seems like it might be a good idea to introduce caching locally for some requests to prevent so many API requests from happening. I'll do some testing on my end as well.

@rogeruiz commented on GitHub (Jun 24, 2021): Thanks @dvignoles could reproduce your use some more, please? More information like how you use the app, do you keep it open or open it on demand? Etc etc. Thanks for mentioning you were only using the TUI interface and not the `playback` functionality. It seems like it might be a good idea to introduce caching locally for some requests to prevent so many API requests from happening. I'll do some testing on my end as well.

kerem commented

Author

Owner

@dvignoles commented on GitHub (Jun 24, 2021):

I've been leaving the TUI open 24/7 (usually idle, not playing) in a tmux session. I'm guessing that if you leave a track paused with the TUI open, the playback information keeps being retrieved on some interval.

I'm surprised more people haven't run into this problem, considering this github issue is a few months old now. Is it more likely something in my configuration/environment?

@dvignoles commented on GitHub (Jun 24, 2021): I've been leaving the TUI open 24/7 (usually idle, not playing) in a tmux session. I'm guessing that if you leave a track paused with the TUI open, the playback information keeps being retrieved on some interval. I'm surprised more people haven't run into this problem, considering this github issue is a few months old now. Is it more likely something in my configuration/environment?

kerem commented

https://developer.spotify.com/documentation/web-api/#conditional-requests

Author

Owner

@rogeruiz commented on GitHub (Jun 25, 2021):

Thanks @dvignoles. Looks like this project should do more caching if that's the case. I'll do a deep dive into the code base to see where this caching would make the most sense to do.

@rogeruiz commented on GitHub (Jun 25, 2021): Thanks @dvignoles. Looks like this project should do more caching if that's the case. I'll do a deep dive into the code base to see where this caching would make the most sense to do. https://developer.spotify.com/documentation/web-api/#conditional-requests

kerem commented

Author

Owner

@Yantrio commented on GitHub (Jul 1, 2021):

If it helps I'm also hitting this and most of the requests seem to be also /v1/me/player. (up to 63181 times on one day)

@Yantrio commented on GitHub (Jul 1, 2021): If it helps I'm also hitting this and most of the requests seem to be also `/v1/me/player`. (up to 63181 times on one day) ![ss](https://user-images.githubusercontent.com/237469/124085788-5005f400-da48-11eb-9b75-f35de55bb221.png)

kerem commented

Author

Owner

@gnarliprime commented on GitHub (Jul 6, 2021):

Just want to chime in that I'm also seeing this issue under the same circumstances: spotify-tui always running in a screen, only not idle during working hours. Not sure if it matters but I am using it to control spotifyd on another machine.

One interesting thing in my case, when my spike in requests happened I was not actively using spotify-tui or spotifyd on any machines.

I'm running centos 7 with spt installed via snap

@gnarliprime commented on GitHub (Jul 6, 2021): Just want to chime in that I'm also seeing this issue under the same circumstances: spotify-tui always running in a screen, only not idle during working hours. Not sure if it matters but I am using it to control spotifyd on another machine. One interesting thing in my case, when my spike in requests happened I was not actively using spotify-tui or spotifyd on any machines. I'm running centos 7 with spt installed via snap ![Screen Shot 2021-07-06 at 9 31 26 AM](https://user-images.githubusercontent.com/8890065/124627774-11ec4400-de3d-11eb-94ca-1d5308f25d46.png)

kerem commented

Author

Owner

@gnarliprime commented on GitHub (Jul 6, 2021):

A quick update, I found that I wasn't able to connect after getting the api request limit error, closing spt, and waiting till the x amount of seconds had transpired to launch it again (same error with a shorter amount of x seconds). Looking around I found that I had another instance of spt running on the box that is running spotifyd, I killed that one and was able to reconnect on the proper box after the timeout period

@gnarliprime commented on GitHub (Jul 6, 2021): A quick update, I found that I wasn't able to connect after getting the api request limit error, closing spt, and waiting till the x amount of seconds had transpired to launch it again (same error with a shorter amount of x seconds). Looking around I found that I had another instance of spt running on the box that is running spotifyd, I killed that one and was able to reconnect on the proper box after the timeout period

kerem commented

Author

Owner

@hexploder commented on GitHub (Jul 7, 2021):

I've been leaving the TUI open 24/7 (usually idle, not playing) in a tmux session. I'm guessing that if you leave a track paused with the TUI open, the playback information keeps being retrieved on some interval.

I'm surprised more people haven't run into this problem, considering this github issue is a few months old now. Is it more likely something in my configuration/environment?

I think that many people that have the issue just doesn't come here.
In my case I'm having the same issue.
I installed spt and spotifyd yesterday and I'm getting a 7 hours timeout, I'm pretty sure the issue must be when you pause the song, I'm not using anything out of the ordinary since I didn't have time to do so, I just installed spt and did the default config alongside spotifyd where I put the spotifyd.service on my .config/systemd/user so I have that service up and running.

The strange thing about this issue was that I had a song paused, then I play another song it started playing and then I got the error, after that I closed spt and the song kept running because of spotifyd, it kept running until I restarted the spotifyd.service.

I would like to provide with a screenshot of the Number of Request/Endpoint like the other ones but I'm still a noob in that regard and I don't have anything in my dashboard.

I guess I should do some config to get that information there right?.

I guess it was just a matter of time here is a picture:

Regards

@hexploder commented on GitHub (Jul 7, 2021): > I've been leaving the TUI open 24/7 (usually idle, not playing) in a tmux session. I'm guessing that if you leave a track paused with the TUI open, the playback information keeps being retrieved on some interval. > > I'm surprised more people haven't run into this problem, considering this github issue is a few months old now. Is it more likely something in my configuration/environment? I think that many people that have the issue just doesn't come here. In my case I'm having the same issue. I installed spt and spotifyd yesterday and I'm getting a 7 hours timeout, I'm pretty sure the issue must be when you pause the song, I'm not using anything out of the ordinary since I didn't have time to do so, I just installed spt and did the default config alongside spotifyd where I put the spotifyd.service on my .config/systemd/user so I have that service up and running. The strange thing about this issue was that I had a song paused, then I play another song it started playing and then I got the error, after that I closed spt and the song kept running because of spotifyd, it kept running until I restarted the spotifyd.service. _I would like to provide with a screenshot of the Number of Request/Endpoint like the other ones but I'm still a noob in that regard and I don't have anything in my dashboard._ ![image](https://user-images.githubusercontent.com/39159150/124822952-008f5e80-df47-11eb-9a88-205f4b6b9959.png) _I guess I should do some config to get that information there right?._ I guess it was just a matter of time here is a picture: ![image](https://user-images.githubusercontent.com/39159150/124979177-19f8df00-e009-11eb-8794-6c62492d2107.png) Regards

kerem commented

Author

Owner

@ale64bit commented on GitHub (Jul 20, 2021):

I'm having this issue every morning. My computer is on but idle during the night: I usually play music and leave the app open with the music paused until the next day. I have >150k requests to v1/me/player endpoint according to the dashboard.

Version        : 0.22.0_2
Architecture   : FreeBSD:13:amd64

@ale64bit commented on GitHub (Jul 20, 2021): I'm having this issue every morning. My computer is on but idle during the night: I usually play music and leave the app open with the music paused until the next day. I have >150k requests to `v1/me/player` endpoint according to the dashboard. ``` Version : 0.22.0_2 Architecture : FreeBSD:13:amd64 ```

kerem commented

Author

Owner

@aviexk commented on GitHub (Jul 24, 2021):

same issue here too.

hitting api limit upon a few hours of usage. running daemon for 5/6 hours.

@aviexk commented on GitHub (Jul 24, 2021): same issue here too. hitting api limit upon a few hours of usage. running daemon for 5/6 hours.

kerem commented

Author

Owner

@rabfel-hobmet commented on GitHub (Jul 25, 2021):

it's pretty constant for me. :(

@rabfel-hobmet commented on GitHub (Jul 25, 2021): ![image](https://user-images.githubusercontent.com/76716724/126888540-0691251e-ebc0-4088-a5ee-a2f0be059723.png) it's pretty constant for me. :(

kerem commented

Author

Owner

@alejandro-angulo commented on GitHub (Jul 31, 2021):

I've also been running into this. Not sure if it helps but I set up logging and I noticed this popping up a bunch when nothing was queued up (shows up one or two times a second)

[2021-07-31T15:06:13Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&

I don't notice this if I pause my music though. Seems to only happen when there's no information about a currently playing track.

EDIT: I reproduced this by letting spt run overnight (no music playing) and that request I mentioned earlier was returning a 429 response

[2021-08-01T15:31:06Z DEBUG reqwest::async_impl::client] response '429 Too Many Requests' for https://api.spotify.com/v1/me/player?additional_types=episode,track&

Spotify's API docs say they return a Retry-After header but seems like this isn't being respected when querying for the currently playing track. It is being read at some point though because there's an error telling me how much longer I need to wait -- ~32000s in my case.

@alejandro-angulo commented on GitHub (Jul 31, 2021): I've also been running into this. Not sure if it helps but I set up logging and I noticed this popping up a bunch when nothing was queued up (shows up one or two times a second) `[2021-07-31T15:06:13Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&` I don't notice this if I pause my music though. Seems to only happen when there's no information about a currently playing track. EDIT: I reproduced this by letting spt run overnight (no music playing) and that request I mentioned earlier was returning a 429 response `[2021-08-01T15:31:06Z DEBUG reqwest::async_impl::client] response '429 Too Many Requests' for https://api.spotify.com/v1/me/player?additional_types=episode,track&` Spotify's API docs say they return a `Retry-After` header but seems like this isn't being respected when querying for the currently playing track. It is being read at some point though because there's an error telling me how much longer I need to wait -- ~32000s in my case.

kerem commented

Author

Owner

@alejandro-angulo commented on GitHub (Aug 1, 2021):

I took a shot at trying to fix this https://github.com/Rigellute/spotify-tui/compare/master...alejandro-angulo:aa/rate-limit . Gonna leave this running for a bit to make sure it actually fixes my issue before opening a PR.

In case anyone else wants to try out my change, run RUST_FMT=debug target/debug/spt 2>> log to store logs in a file.

EDIT: I left spt running overnight and still ran into the rate limit issue :(

@alejandro-angulo commented on GitHub (Aug 1, 2021): I took a shot at trying to fix this https://github.com/Rigellute/spotify-tui/compare/master...alejandro-angulo:aa/rate-limit . Gonna leave this running for a bit to make sure it actually fixes my issue before opening a PR. In case anyone else wants to try out my change, run `RUST_FMT=debug target/debug/spt 2>> log` to store logs in a file. EDIT: I left spt running overnight and still ran into the rate limit issue :(

kerem commented

Author

Owner

@alejandro-angulo commented on GitHub (Aug 5, 2021):

I saw this in the logs I have

[2021-08-02T13:36:30Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:30Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:31Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:31Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:32Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:32Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:33Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:33Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:34Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:34Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:35Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:35Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:36Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:36Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:37Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:37Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:38Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:38Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:39Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:39Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:40Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&
[2021-08-02T13:36:40Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track&

I think we should only be polling for playback every 5s though https://github.com/Rigellute/spotify-tui/blob/master/src/app.rs#L465

I think maybe the issue is that we set/check self.is_fetching_current_playback but we have multiple app instances running.

@alejandro-angulo commented on GitHub (Aug 5, 2021): I saw this in the logs I have ``` [2021-08-02T13:36:30Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:30Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:31Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:31Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:32Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:32Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:33Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:33Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:34Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:34Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:35Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:35Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:36Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:36Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:37Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:37Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:38Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:38Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:39Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:39Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:40Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& [2021-08-02T13:36:40Z DEBUG reqwest::async_impl::client] response '204 No Content' for https://api.spotify.com/v1/me/player?additional_types=episode,track& ``` I think we should only be polling for playback every 5s though https://github.com/Rigellute/spotify-tui/blob/master/src/app.rs#L465 I think maybe the issue is that we set/check `self.is_fetching_current_playback` but we have multiple app instances running.

kerem commented

Author

Owner

@SageSyS commented on GitHub (Aug 5, 2021):

Yeah.

@SageSyS commented on GitHub (Aug 5, 2021): <a href="https://ibb.co/7pNXC1J"><img src="https://i.ibb.co/qgFdjrM/Screenshot-20210805-172826.png" alt="Screenshot-20210805-172826" border="0" /></a> Yeah.

kerem commented

Author

Owner

@Rigellute commented on GitHub (Aug 7, 2021):

Ah interesting. I've not run into this myself but definitely sounds like a problem - sorry to hear it!

I'm afraid I don't have to much spare time to work on this at the moment - so any help here would be appreciated.

@Rigellute commented on GitHub (Aug 7, 2021): Ah interesting. I've not run into this myself but definitely sounds like a problem - sorry to hear it! I'm afraid I don't have to much spare time to work on this at the moment - so any help here would be appreciated.

kerem commented

Author

Owner

@alejandro-angulo commented on GitHub (Aug 8, 2021):

@Rigellute I might be able to help out here. Thanks for the work on spotify-tui btw, it's super neat to be able to control spotify from my terminal. 👍

I think the issue might be that we're not updating app.instant_since_last_current_playback_poll if we get an empty response from spotify (which is the case if there's an empty queue). From the logs I've seen so far it seems like it's now pinging every 5s as intended. I'm going to let this run overnight before I tidy it up and submit a PR. Here are my changes if anyone is interested in looking https://github.com/Rigellute/spotify-tui/compare/master...alejandro-angulo:aa/rate-limit

@alejandro-angulo commented on GitHub (Aug 8, 2021): @Rigellute I might be able to help out here. Thanks for the work on spotify-tui btw, it's super neat to be able to control spotify from my terminal. :+1: I think the issue might be that we're not updating `app.instant_since_last_current_playback_poll` if we get an empty response from spotify (which is the case if there's an empty queue). From the logs I've seen so far it seems like it's now pinging every 5s as intended. I'm going to let this run overnight before I tidy it up and submit a PR. Here are my changes if anyone is interested in looking https://github.com/Rigellute/spotify-tui/compare/master...alejandro-angulo:aa/rate-limit

kerem commented

Author

Owner

@alejandro-angulo commented on GitHub (Aug 11, 2021):

I got around to putting up #852 which should resolve this issue 🎉

@alejandro-angulo commented on GitHub (Aug 11, 2021): I got around to putting up #852 which should resolve this issue :tada:

kerem commented

Author

Owner

@Septem151 commented on GitHub (Aug 21, 2021):

I got around to putting up #852 which should resolve this issue

Fantastic! I also just started using spt yesterday, and I was using it like normal (have it open to "simple playback" mode to show the song, playing music for roughly 3 hours) and after that time, I started getting the API quota exceeded warning from Spotify. I checked the Spotify dashboard and this was the result:

All those requests to /v1/me/player (28,640 of them) within a matter of roughly 3 hours of normal usage (songs constantly playing in the background, showing information about the currently playing song).

I seriously hope this PR gets merged ASAP. In the meantime, I'll probably start using your fork.

@Septem151 commented on GitHub (Aug 21, 2021): > I got around to putting up #852 which should resolve this issue Fantastic! I also just started using spt yesterday, and I was using it like normal (have it open to "simple playback" mode to show the song, playing music for roughly 3 hours) and after that time, I started getting the API quota exceeded warning from Spotify. I checked the Spotify dashboard and this was the result: ![image](https://user-images.githubusercontent.com/32029081/130324974-4b5c1bdf-95ab-4bc2-884d-e1e974ad68fe.png) All those requests to /v1/me/player (28,640 of them) within a matter of roughly 3 hours of normal usage (songs constantly playing in the background, showing information about the currently playing song). I seriously hope this PR gets merged ASAP. In the meantime, I'll probably start using your fork.

kerem commented

Author

Owner

@alejandro-angulo commented on GitHub (Aug 23, 2021):

@Septem151 My PR was just merged so you should be able to switch back the official repo (don't think it's part of any release yet so you'll have pull down the master branch yourself).

@alejandro-angulo commented on GitHub (Aug 23, 2021): @Septem151 My PR was just merged so you should be able to switch back the official repo (don't think it's part of any release yet so you'll have pull down the master branch yourself).

kerem commented

Author

Owner

@Rigellute commented on GitHub (Aug 23, 2021):

I will do some testing tomorrow and hopefully cut a new release with @alejandro-angulo 's fix!

@Rigellute commented on GitHub (Aug 23, 2021): I will do some testing tomorrow and hopefully cut a new release with @alejandro-angulo 's fix!

kerem commented

Author

Owner

@alejandro-angulo commented on GitHub (Aug 28, 2021):

I haven't noticed the issue anymore with the new release.

@alejandro-angulo commented on GitHub (Aug 28, 2021): I haven't noticed the issue anymore with the new release.

kerem commented

Author

Owner

@Rigellute commented on GitHub (Sep 1, 2021):

Thanks to @alejandro-angulo this is now fixed and released in v0.25!

@Rigellute commented on GitHub (Sep 1, 2021): Thanks to @alejandro-angulo this is now fixed and released in v0.25!

kerem commented