Closed kevincornish closed 10 months ago
Hello! What reverse proxy are you using? It seems to be something related to your architecture.
Thanks for replying!
I did think it might be partly to-do with the reverse proxy not being able to go external, but why would it be able to fetch info if i force it to relog to spotify?
I'm using swag with the following config's for the server and client:
client
server {
listen 443 ssl;
server_name music.xxx.xxx;
include /config/nginx/ssl.conf;
client_max_body_size 0;
location / {
include /config/nginx/proxy.conf;
resolver 127.0.0.11 valid=30s;
proxy_pass http://192.168.1.82:6447;
}
}
# Redirect HTTP requests to HTTPS
server {
listen 80;
server_name music.xxx.xxx;
return 301 https://$host$request_uri;
}
server
server {
listen 443 ssl;
server_name mapi.xxx.xxx;
include /config/nginx/ssl.conf;
client_max_body_size 0;
location / {
include /config/nginx/proxy.conf;
resolver 127.0.0.11 valid=30s;
proxy_pass http://192.168.1.82:8886;
}
}
# Redirect HTTP requests to HTTPS
server {
listen 80;
server_name mapi.xxx.xxx;
return 301 https://$host$request_uri;
}
If this doesn't look like an issue, I could try attaching the 3 containers to the same docker network as swag.
The client_max_body_size 0 seems weird to me. But in my opinion you should go step by step on rebuilding your architecture and see where it hangs. I don't why you sometimes get info sometimes not.
Ok, just had tried putting the containers onto the same docker network with no luck. Removed the client_max_body_size too.
Will attach another log, i'll try deleting the containers + data (keeping the mongo data)
_spotifystats-server-1_logs(4).txt
I have just rebuilt the containers with no change. I do have 3 users but unable to compare their stats using affinity. They were fresh signups after i moved from internal only.
Checked out a few more things this morning and also tried replicating the request, if i manually make a request to https://api.spotify.com/v1/me/player/recently-played?after=1689422404563
using the same bearer token, i get the same reply:
{
"error": {
"status": 504,
"message": "Service didn't reply before timeout"
}
}
Found a couple other people with the same issue trying to hit the same endpoint - here and here
@Yooooomi, do you have multiple users on your server?
Hello. It seems really weird. I do have like a dozen of users on my instance and everything works flawlessly. Can you try requesting from another network like phone data or something? We got to investigate wether it's caused by your account or your router.
Hmm interesting. Ok just tested the same request with new bearer token via mobile network and got the same 504 timeout. I did notice that i didn't add the two additional users to the app on the dev portal so i've done that, rebuilt + asked them to relog to spotify but no difference there.
At this point you can maybe try contacting the support.
I've replied to the open threads i've found on the spotify forum and referenced this issue. I also noticed that it looks like it's only the 2 users that signed up getting the 504 response, my account is syncing ok. They have nothing on their accounts since they joined yesterday and have listened to spotify since.
I'm sorry I can't do anything for you about this. I really hope they come up with an explanation or fix for this. I will also check if my instance has any issues like this.
Hi @Yooooomi, figured it out. The 2 new users supplied me with emails that were different from the ones they had linked to on spotify. Might be worth chucking a catch in for the 504 error on the /v1/me/player/recently-played api call? Happy to commit one if needed, if you don't like that approach then we can close off this issue!
Oh I wouldn't have thought of that. Yes we could catch something off of that. If you still have some logs it could be great as I don't know if it's easily reproducible. Glad you found out!
@kevincornish I don't know if you could solve the problem already, but i stumbled over the same problem today.
For me it did the trick because my Developer app was still in the "development mode". Therefore you need to add the users permitted to use your app in the spotify developer portal. Otherwise you'll get those weird 504 errors.
You can add them here:
@kevincornish I don't know if you could solve the problem already, but i stumbled over the same problem today.
For me it did the trick because my Developer app was still in the "development mode". Therefore you need to add the users permitted to use your app in the spotify developer portal. Otherwise you'll get those weird 504 errors.
You can add them here:
Haha yeah, same issue. The two users supplied with me different emails than the ones linked to their Spotify accounts. I answered it somewhere along this issue. I didn't close it out as I was going to push a PR with an updated catch but completely forgot!!
Just switched from running internally only to subdomain and noticed that the api call to fetch songs is 504'ing. If i reboot the containers or relog to spotify it will catch the missing songs but i think that'll only work if there are less than 50 played in that period.
Still using mongo 4.4.8 as the newer versions wont work on my system.
my compose