mirror of
https://github.com/misiektoja/spotify_monitor.git
synced 2026-04-25 14:45:50 +03:00
[GH-ISSUE #35] Requests taking forever #23
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @WurdahMekanik on GitHub (Feb 15, 2026).
Original GitHub issue: https://github.com/misiektoja/spotify_monitor/issues/35
I've had problems with this not being able to consistently capture real-time activity in the past couple weeks. I'm not sure if this is a Spotify issue or something else, but I've traced it down to the SESSION.get() calls seeming to take forever to return, usually on the order of an hour or more. I'm using use cookie + oauth_app to authenticate, have python 3.14.2 installed, and IPv6 disabled.
@misiektoja commented on GitHub (Feb 15, 2026):
Strange issue, I have never come across it before. Are there any errors, like 429? Are you using any VPN, proxy or corporate network? Are you on Windows or Linux/macOS ?
The only thing that comes to mind is the long 429 retry-after response returned by Spotify in your case, perhaps due to some proxy.
I capped it at 60 seconds in the newest dev version. Can you try it with the new
--debugflag and share the log when the issue happens again? If you installed via pip:@tomballgithub commented on GitHub (Feb 16, 2026):
FWIW, I was seeing this Friday night out of the blue. I wasn't sure if it was related to the latest code changes.
Super frustrated, I just left it alone and it was working correctly on Saturday morning. I attributed it to the Spotify API or something else unknown.
However, it was really odd, because I noticed the same thing, that it was not timing out as it should have been and was taking 'forever'.
While debugging, it sure looked like requests issue not timing out as it should, unless it was invisibly doing a backoff/retry.
I noticed instagram_monitor taking 24 mins to complete a request and then timeout. If that happens invisibly, it sure would explain what we noticed.
@misiektoja commented on GitHub (Feb 16, 2026):
Ok, it confirms my suspicion. Most likely, Spotify returned a 429 backoff with a very long retry-after due to some issues on their side and we behaved nicely by waiting the time indicated by Spotify (since doing it faster will typically result in another 429). Right now, it is capped at a maximum of 60 seconds, so if Spotify returns something longer, we ignore it and retry.
@tomballgithub commented on GitHub (Feb 16, 2026):
FWIW, I made these changes to instagram_monitor and it took the backoff/retry cycle down to 8 mins (from 24, which is 3 total tries), which is still too long.
I added
max_connection_attempts=1, request_timeout=30, fatal_status_codes=[302,400,401,429]at the endInstaloader also has settings for these, which I will try next:
request_timeoutand
rate_controller@tomballgithub commented on GitHub (Feb 16, 2026):
Seeing this in debug mode, is it expected (3 retries, 3 failures)?
I'm seeing the really long hangups right now.
Before this, I was getting the following, so I restarted:
@tomballgithub commented on GitHub (Feb 16, 2026):
Took 5 minutes for this:
@tomballgithub commented on GitHub (Feb 16, 2026):
I even tried with a new sp_dc
@tomballgithub commented on GitHub (Feb 16, 2026):
Here is the offending line:
And in my .conf, because I thought previously you told me to comment out the 61 to force it to fetch an update from the CIPHER_DICT_URL rather than trying to use a possibly old DICT.
It works fine if I uncomment and don't have a blank DICT
@tomballgithub commented on GitHub (Feb 16, 2026):
But it is still hanging for 5 minutes in the same spot, fetching a track.
Cookie mode
@WurdahMekanik commented on GitHub (Feb 16, 2026):
Mine suddenly seems to be working just fine.
No VPN, running on Linux, typically running on two different machines on two different networks (my home can have uptime issues, but I don't access the other machine as often)
However, over the weekend it seemed to be the case that it hung for exactly 24 hours (I saw timestamp output at a particular time, then an error sometime later, and the next time I saw a timestamp in the logs was 24 hours from the previous timestamp).
@tomballgithub commented on GitHub (Feb 16, 2026):
Client mode with protobuf hangs in the same place. I am seeing this at startup when it's trying to fetch info on the current user's track or last track.
@misiektoja commented on GitHub (Feb 16, 2026):
Wow, they are essentially aggressively throttling the traffic with 429s, the same as Instagram. Those 3 failed retries were actually a bug I was not aware of, fixed in
375c5293d2, it should save you 3 requests ;-)@misiektoja commented on GitHub (Feb 16, 2026):
What is interesting is we actually get 429s when using the official OAuth app token / Client Credentials flow (
/v1/tracksAPI calls), so it appears the announced February changes also introduced some limit on the number of requests.However, I have two instances of spotify_profile_monitor (checking every 6 hours) and one instance of spotify_monitor (checking every 60 seconds) running and they are all good so far. Maybe increasing the check interval can help?
@tomballgithub commented on GitHub (Feb 16, 2026):
I cannot even get started, so I am not sure the check interval will help
@tomballgithub commented on GitHub (Feb 16, 2026):
Hmm, my spotify_profile_monitor is still working, even if I restart it
@misiektoja commented on GitHub (Feb 16, 2026):
I guess you need to wait a couple of minutes for it to release the quota limit for you.
In spotify_profile_monitor, we use slightly different calls. The /v1/tracks endpoint is only used to check token validity, if I remember correctly.
@tomballgithub commented on GitHub (Feb 16, 2026):
I just verified and spotify_profile_monitor is not using this API period, even to check token validity:
https://api.spotify.com/v1/tracks/YYYIn cookie mode, it seems to be using:
https://guc-spclient.spotify.com/presence-view/v1/buddylistI verified this via debug print statements anywhere referencing the /tracks/ api
@tomballgithub commented on GitHub (Feb 17, 2026):
I tried again an hour later, same thing. I just tried again 5 hours later, and it worked. There's definitely a behavior change.
Is there a way to avoid these 5+ minute timeouts? The most recent change to cap at 60 seconds still resulted in 5 mins.
I changed to SPOTIFY_CHECK_INTERVAL = 60 at your recommendation.
I'd been running at 30 for a year without issue.
@WurdahMekanik commented on GitHub (Feb 17, 2026):
It seems like this is definitely a Spotify problem that quite a few people are upset about:
https://community.spotify.com/t5/Spotify-for-Developers/Low-number-of-requests-leading-to-429-response/td-p/7338415
https://community.spotify.com/t5/Spotify-for-Developers/Severe-429-Errors-in-Apps-with-Granted-Quota-Extension/td-p/7340780
@tomballgithub commented on GitHub (Feb 17, 2026):
Thanks for sharing those links. Interesting to see that Spotify is engaging on improvements.
@misiektoja commented on GitHub (Feb 17, 2026):
Fingers crossed they will adjust it properly.