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 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.

yeah i have had this, no workaround either

@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.

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.

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.

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?

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

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)

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

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

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

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

same issue here too.

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

it's pretty constant for me. :(

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.

I took a shot at trying to fix this 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 :(

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.

Yeah.

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 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 master...alejandro-angulo:aa/rate-limit

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

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 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).

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

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

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

Still persist for me :/

I use spt playback to output the actual playing song into my tmux status.

  System Version: macOS 12.6.2 (21G320)
  Kernel Version: Darwin 21.6.0
  spotify-tui 0.25.0