[GH-ISSUE #667] Failure to authenticate (first connection) - tried too many access points #388

New issue

Closed

opened 2026-03-02 23:47:08 +03:00 by kerem · 2 comments

kerem commented

2026-03-02 23:47:08 +03:00

Owner

Originally created by @qnicoud on GitHub (Jan 16, 2025).
Original GitHub issue: https://github.com/aome510/spotify-player/issues/667

Issue description
While attempting to launch the application for the first time, after having installed it via yay (and checked dependencies), the application fails to authenticate with error :

Error: initialize new Spotify session

Caused by:
    0: connect to a session
    1: Deadline expired before operation could complete { timed out }

To Reproduce
Install & launch :

yay -S spotify-player
spotify_player

Follow up the provided link, authenticate on the official web interface and then go back to terminal as prompted.
This happens even if I tried to execute spotify_player authenticate beforehand. In this particular case, the commands output no additional log in STDOUT & the exit code is 0:

$ spotify_player authenticate
No cached credentials found, please authenticate the application first.
Browse to: https://accounts.spotify.com/authorize?  ...etc...
$ echo $?
0

However, running spotify_player afterwards yields the same behavior as described above.

Expected behaviour
I guess a successfull authentication message (never got here yet 😆 )

Log and backtrace
Removed the first line with the loaded config info

2025-01-16T18:29:25.469887Z  INFO librespot_oauth: OAuth server listening on 127.0.0.1:8989    
2025-01-16T18:29:41.172548Z  INFO librespot_core::session: Connecting to AP "ap-gew1.spotify.com:4070"    
2025-01-16T18:29:47.251707Z  WARN librespot_core::session: Try another access point...    
2025-01-16T18:29:47.251769Z  INFO librespot_core::session: Connecting to AP "ap-gew1.spotify.com:443"    
2025-01-16T18:29:53.330324Z  WARN librespot_core::session: Try another access point...    
2025-01-16T18:29:53.330387Z  INFO librespot_core::session: Connecting to AP "ap-gew1.spotify.com:80"    
2025-01-16T18:29:59.412121Z  WARN librespot_core::session: Try another access point...    
2025-01-16T18:29:59.412179Z  INFO librespot_core::session: Connecting to AP "ap-guc3.spotify.com:4070"    
2025-01-16T18:30:05.491506Z  WARN librespot_core::session: Try another access point...    
2025-01-16T18:30:05.491560Z  INFO librespot_core::session: Connecting to AP "ap-gue1.spotify.com:443"    
2025-01-16T18:30:11.570019Z  WARN librespot_core::session: Try another access point...    
2025-01-16T18:30:11.570080Z  INFO librespot_core::session: Connecting to AP "ap-gew4.spotify.com:80"    
2025-01-16T18:30:17.651175Z ERROR librespot_core::session: Tried too many access points

Trying to ping those URL gives an answer but I have indeed a timeout with curl.

Environment

OS: ArchLinux
Application version: 0.20.4
Application features: built through yay so no clue about the cargo parameters.

Additional context
Nothing to report

Originally created by @qnicoud on GitHub (Jan 16, 2025). Original GitHub issue: https://github.com/aome510/spotify-player/issues/667 **Issue description** While attempting to launch the application for the first time, after having installed it via yay (and checked dependencies), the application fails to authenticate with error : ``` Error: initialize new Spotify session Caused by: 0: connect to a session 1: Deadline expired before operation could complete { timed out } ``` **To Reproduce** Install & launch : ``` yay -S spotify-player spotify_player ``` Follow up the provided link, authenticate on the official web interface and then go back to terminal as prompted. This happens even if I tried to execute spotify_player authenticate beforehand. In this particular case, the commands output no additional log in STDOUT & the exit code is 0: ``` $ spotify_player authenticate No cached credentials found, please authenticate the application first. Browse to: https://accounts.spotify.com/authorize? ...etc... $ echo $? 0 ``` However, running spotify_player afterwards yields the same behavior as described above. **Expected behaviour** I guess a successfull authentication message (never got here yet 😆 ) **Log and backtrace** Removed the first line with the loaded config info ``` 2025-01-16T18:29:25.469887Z INFO librespot_oauth: OAuth server listening on 127.0.0.1:8989 2025-01-16T18:29:41.172548Z INFO librespot_core::session: Connecting to AP "ap-gew1.spotify.com:4070" 2025-01-16T18:29:47.251707Z WARN librespot_core::session: Try another access point... 2025-01-16T18:29:47.251769Z INFO librespot_core::session: Connecting to AP "ap-gew1.spotify.com:443" 2025-01-16T18:29:53.330324Z WARN librespot_core::session: Try another access point... 2025-01-16T18:29:53.330387Z INFO librespot_core::session: Connecting to AP "ap-gew1.spotify.com:80" 2025-01-16T18:29:59.412121Z WARN librespot_core::session: Try another access point... 2025-01-16T18:29:59.412179Z INFO librespot_core::session: Connecting to AP "ap-guc3.spotify.com:4070" 2025-01-16T18:30:05.491506Z WARN librespot_core::session: Try another access point... 2025-01-16T18:30:05.491560Z INFO librespot_core::session: Connecting to AP "ap-gue1.spotify.com:443" 2025-01-16T18:30:11.570019Z WARN librespot_core::session: Try another access point... 2025-01-16T18:30:11.570080Z INFO librespot_core::session: Connecting to AP "ap-gew4.spotify.com:80" 2025-01-16T18:30:17.651175Z ERROR librespot_core::session: Tried too many access points ``` Trying to ping those URL gives an answer but I have indeed a timeout with curl. **Environment** - OS: ArchLinux - Application version: 0.20.4 - Application features: built through yay so no clue about the cargo parameters. **Additional context** Nothing to report

kerem

2026-03-02 23:47:08 +03:00

closed this issue
added the
bug
label

kerem commented

2026-03-02 23:47:09 +03:00

Author

Owner

@aome510 commented on GitHub (Jan 17, 2025):

Sounds like there is some issue with your network setup. I found this thread which might be helpful for you.

@aome510 commented on GitHub (Jan 17, 2025): Sounds like there is some issue with your network setup. I found [this thread](https://github.com/librespot-org/librespot/issues/1401) which might be helpful for you.

kerem commented

2026-03-02 23:47:09 +03:00

Author

Owner

@qnicoud commented on GitHub (Jan 17, 2025):

Oooh you are right!
I had totally forgotten I still had a local DNS server running with pihole!
It seems it could not resolve/reach the URLs used to fetch the credentials.
I temporarily removed it with :

nmcli con mod "<connection name>" ipv4.ignore-dns-auto yes
nmcli con mod "<connection name>" ipv4.dns "<correct dns ip (not pihole)>"
systemctl restart NetworkManager

Checked the conf is properly reloaded in /etc/resolv.conf
And that was it ! I'll have to look into pihole to figure out why it couldn't resolve/reach these URLs though.
Thanks a lot !

@qnicoud commented on GitHub (Jan 17, 2025): Oooh you are right! I had totally forgotten I still had a local DNS server running with pihole! It seems it could not resolve/reach the URLs used to fetch the credentials. I temporarily removed it with : ``` nmcli con mod "<connection name>" ipv4.ignore-dns-auto yes nmcli con mod "<connection name>" ipv4.dns "<correct dns ip (not pihole)>" systemctl restart NetworkManager ``` Checked the conf is properly reloaded in /etc/resolv.conf And that was it ! I'll have to look into pihole to figure out why it couldn't resolve/reach these URLs though. Thanks a lot !

kerem referenced this issue

2026-03-02 23:49:38 +03:00

[PR #388] [MERGED] don't refresh playback on new streaming player event #747

kerem referenced this issue

2026-03-14 13:39:17 +03:00

[GH-ISSUE #387] ResumePause doesn't always register. Play/Pause Icon is confused. #1143

kerem referenced this issue

2026-03-14 15:27:28 +03:00

[PR #388] [MERGED] don't refresh playback on new streaming player event #1685