Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suddenly unable to play any tracks #972

Closed
kosimst opened this issue Mar 2, 2022 · 171 comments · Fixed by #1026
Closed

Suddenly unable to play any tracks #972

kosimst opened this issue Mar 2, 2022 · 171 comments · Fixed by #1026
Labels
SpotifyAPI Interop b/w librespot and Spotify

Comments

@kosimst
Copy link

kosimst commented Mar 2, 2022

I am using LibreSpot with the JACK Audio backend, and it worked perfectly, but since a few days I can't play any tracks. I didn't change any configurations on my side, so I assume there is a problem with spotify like it already occured here: #510

Setup

Custom compiled with --no-default-features and --features jackaudio-backend running as a user service on a Raspberry Pi.

Used Arguments:

  • backend: jackaudio
  • bitrate: 320
  • no-audio-cache & no-credential-cache

LibreSpot allows connections from any device just fine, but can't play any song, no matter of its length. Mots of the time it just skips every song after a few seconds without any audio played, but sometimes it also crashes completely.

Logs:

Mar 02 10:48:40 raspberrypi librespot[714]: [2022-03-02T15:48:40Z ERROR librespot_core::channel] channel error: 2 1
Mar 02 10:48:40 raspberrypi librespot[714]: [2022-03-02T15:48:40Z ERROR librespot_playback::player] Unable to load encrypted file: ChannelError
Mar 02 10:48:40 raspberrypi librespot[714]: [2022-03-02T15:48:40Z INFO  librespot_playback::player] Loading <Lightning Over Heaven> with Spotify URI <spotify:track:0S0zgiheqNBkRjEMo7pnig>
Mar 02 10:48:40 raspberrypi librespot[714]: [2022-03-02T15:48:40Z ERROR librespot_playback::player] Unable to load encrypted file: ChannelError
Mar 02 10:48:40 raspberrypi librespot[714]: [2022-03-02T15:48:40Z WARN  librespot_playback::player] Skipping to next track, unable to load track <SpotifyId { id: 38045326986839703698416089418933192304, audio_type: Track }>: ()
Mar 02 10:48:40 raspberrypi librespot[714]: [2022-03-02T15:48:40Z INFO  librespot_playback::player] Loading <Lightning Over Heaven> with Spotify URI <spotify:track:0S0zgiheqNBkRjEMo7pnig>
Mar 02 10:48:40 raspberrypi librespot[714]: [2022-03-02T15:48:40Z ERROR librespot_core::channel] channel error: 2 1
Mar 02 10:48:40 raspberrypi librespot[714]: [2022-03-02T15:48:40Z ERROR librespot_playback::player] Unable to load encrypted file: ChannelError
Mar 02 10:48:40 raspberrypi librespot[714]: [2022-03-02T15:48:40Z WARN  librespot_playback::player] Skipping to next track, unable to load track <SpotifyId { id: 38045326986839703698416089418933192304, audio_type: Track }>: ()
Mar 02 10:48:40 raspberrypi librespot[714]: [2022-03-02T15:48:40Z ERROR librespot_core::channel] channel error: 2 1
Mar 02 10:48:40 raspberrypi librespot[714]: [2022-03-02T15:48:40Z ERROR librespot_playback::player] Unable to load encrypted file: ChannelError
Mar 02 10:48:40 raspberrypi librespot[714]: [2022-03-02T15:48:40Z INFO  librespot_playback::player] Loading <Lightning Over Heaven> with Spotify URI <spotify:track:0S0zgiheqNBkRjEMo7pnig>
Mar 02 10:48:40 raspberrypi librespot[714]: [2022-03-02T15:48:40Z ERROR librespot_core::channel] channel error: 2 1
Mar 02 10:48:40 raspberrypi librespot[714]: [2022-03-02T15:48:40Z ERROR librespot_playback::player] Unable to load encrypted file: ChannelError
Mar 02 10:48:40 raspberrypi librespot[714]: [2022-03-02T15:48:40Z ERROR librespot_core::channel] channel error: 2 1
Mar 02 10:48:40 raspberrypi librespot[714]: [2022-03-02T15:48:40Z ERROR librespot_playback::player] Unable to load encrypted file: ChannelError
Mar 02 10:48:40 raspberrypi librespot[714]: thread '<unnamed>' panicked at 'Map must not be polled after it returned `Poll::Ready`', /home/pi/.cargo/registry/src/github.com-1285ae84e5963aae/futures-util-0.3.17/src/future/future/map.rs:62:17
Mar 02 10:48:40 raspberrypi librespot[714]: stack backtrace:
Mar 02 10:48:41 raspberrypi librespot[714]:    0:   0x8febfc - std::backtrace_rs::backtrace::libunwind::trace::h532c701585cd392d
Mar 02 10:48:41 raspberrypi librespot[714]:                        at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
Mar 02 10:48:41 raspberrypi librespot[714]:    1:   0x8febfc - std::backtrace_rs::backtrace::trace_unsynchronized::h15e96deae50ea7f1
Mar 02 10:48:41 raspberrypi librespot[714]:                        at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
Mar 02 10:48:41 raspberrypi librespot[714]:    2:   0x8febfc - std::sys_common::backtrace::_print_fmt::h2de65accbd58b3e4
Mar 02 10:48:41 raspberrypi librespot[714]:                        at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/sys_common/backtrace.rs:67:5
Mar 02 10:48:41 raspberrypi librespot[714]:    3:   0x8febfc - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h85671ae76efc2464
Mar 02 10:48:41 raspberrypi librespot[714]:                        at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/sys_common/backtrace.rs:46:22
Mar 02 10:48:41 raspberrypi librespot[714]:    5:   0x8f709c - std::io::Write::write_fmt::hcccb69ae7e0e5712
Mar 02 10:48:41 raspberrypi librespot[714]:                        at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/io/mod.rs:1697:15
Mar 02 10:48:41 raspberrypi librespot[714]:    6:   0x900c68 - std::sys_common::backtrace::_print::hedd1975fac8ef971
panicking.rs:211:50pberrypi librespot[714]:                        at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/sys_common/backtrace.rs:49:5
Mar 02 10:48:41 raspberrypi librespot[714]:    9:   0x900710 - std::panicking::default_hook::h76fa136e1f70a214
Mar 02 10:48:41 raspberrypi librespot[714]:                        at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:228:9
Mar 02 10:48:41 raspberrypi librespot[714]:   14:   0x61fd54 - <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll::h6cdb6d970c4ac361
Mar 02 10:48:41 raspberrypi librespot[714]:   15:   0x60d7d8 - <futures_util::future::try_future::MapErr<Fut,F> as core::future::future::Future>::poll::hfe2e84411f277e84
Mar 02 10:48:41 raspberrypi librespot[714]:   16:   0x5fbd10 - <librespot_playback::player::PlayerInternal as core::future::future::Future>::poll::h28a4cde177e46443
Mar 02 10:48:41 raspberrypi librespot[714]:   17:   0x4c7774 - std::thread::local::LocalKey<T>::with::h85f1e7d59454df33
Mar 02 10:48:41 raspberrypi librespot[714]:   18:   0x4bbad4 - futures_executor::local_pool::block_on::hefeadbfdb9a235f9
Mar 02 10:48:41 raspberrypi librespot[714]:   19:   0x567ff4 - std::sys_common::backtrace::__rust_begin_short_backtrace::ha9233c878f46eaea
Mar 02 10:48:41 raspberrypi librespot[714]:   20:   0x5287ac - core::ops::function::FnOnce::call_once{{vtable.shim}}::he863134c8af815b9
Mar 02 10:48:41 raspberrypi librespot[714]:                        at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/alloc/src/boxed.rs:1694:9
Mar 02 10:48:41 raspberrypi librespot[714]:   22:   0x9061e4 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h3a9e9491476f36e5
Mar 02 10:48:41 raspberrypi librespot[714]:                        at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/alloc/src/boxed.rs:1694:9
Mar 02 10:48:41 raspberrypi librespot[714]: [2022-03-02T15:48:41Z ERROR librespot_playback::player] Player Commands Error: channel closed
Mar 02 10:48:41 raspberrypi librespot[714]: [2022-03-02T15:48:41Z ERROR librespot_playback::player] Player Commands Error: channel closed
Mar 02 10:48:41 raspberrypi librespot[714]: [2022-03-02T15:48:41Z ERROR librespot_playback::player] Player Commands Error: channel closed
Mar 02 10:48:42 raspberrypi librespot[714]: [2022-03-02T15:48:42Z ERROR librespot_playback::player] Player Commands Error: channel closed
@michaelherger
Copy link
Contributor

Where about on this planet are you located? I've received a few similar reports from users in the past few days.

@cvejlbo
Copy link

cvejlbo commented Mar 2, 2022

Just in case you are gathering stats/data:
Same issue for me (in Denmark).

@jesperll
Copy link

jesperll commented Mar 2, 2022

Same here (via Spotty integration in Logitech Media Server) (also Denmark)

@michaelherger
Copy link
Contributor

michaelherger commented Mar 2, 2022

@jesperll - you're not JesperDB who's been reporting this similar issue to me, are you?

That then would be three Danish users. It's hard to believe this was a coincidence...

@kosimst
Copy link
Author

kosimst commented Mar 2, 2022

I am from Austria @michaelherger, so maybe the problem is in europe.

@ashthespy
Copy link
Member

Also saw similar channel errors from DK..

@JesperBarrit
Copy link

JesperBarrit commented Mar 2, 2022

@jesperll - you're not JesperDB who's been reporting this similar issue to me, are you?

No, that's me and I'm also in Denmark :)

I have the same issue here:
https://forums.slimdevices.com/showthread.php?111923-Announce-Spotty-4-0-integrate-local-library-with-your-Spotify-collection-(LMS-8-)&p=1049289&viewfull=1#post1049289

@cvejlbo
Copy link

cvejlbo commented Mar 3, 2022

FWIW: A similar issue seem to happen if I try using new-api branch, except the spotify client/UI on my PC/phone does not repeatedly skip fwd after ~5 secs [still no playback, though]

Console log with -v from new-api branch:

[...]
[2022-03-03T10:43:35Z TRACE librespot_connect::spirc] Frame has 48 tracks
[2022-03-03T10:43:35Z DEBUG librespot_playback::player] command=SetAutoNormaliseAsAlbum(false)
[2022-03-03T10:43:35Z DEBUG librespot_playback::player] command=Load(SpotifyId("spotify:track:2C0iEdLXanscPYGpwO2oSm"), true, 115962)
[2022-03-03T10:43:35Z TRACE librespot_connect::spirc] Sending status to server: [kPlayStatusPlay]
[2022-03-03T10:43:35Z DEBUG librespot::component] new SpClient
[2022-03-03T10:43:35Z INFO  librespot_core::spclient] Resolved "gew1-spclient.spotify.com:443" as spclient access point
[2022-03-03T10:43:35Z DEBUG librespot::component] new TokenProvider
[2022-03-03T10:43:35Z TRACE librespot_core::token] Requested token in scopes "playlist-read" unavailable or expired, requesting new token.
[2022-03-03T10:43:35Z TRACE librespot_connect::spirc] ==> kPlayStatusLoading
[2022-03-03T10:43:35Z TRACE librespot_connect::spirc] Sending status to server: [kPlayStatusLoading]
[2022-03-03T10:43:35Z ERROR librespot_core::mercury] error 403 for uri hm://keymaster/token/authenticated?scope=playlist-read&client_id=65b708073fc0480ea92a077233ca87bd&device_id=ce8d71004f9597141d4b5940bd1bb2dc52a35dae
[2022-03-03T10:43:35Z ERROR librespot_playback::player] Unable to load audio item: Error { kind: Unavailable, error: Response(MercuryResponse { uri: "hm://keymaster/token/authenticated?scope=playlist-read&client_id=65b708073fc0480ea92a077233ca87bd&device_id=ce8d71004f9597141d4b5940bd1bb2dc52a35dae", status_code: 403, payload: [[123, 34, 99, 111, 100, 101, 34, 58, 52, 44, 34, 101, 114, 114, 111, 114, 68, 101, 115, 99, 114, 105, 112, 116, 105, 111, 110, 34, 58, 34, 73, 110, 118, 97, 108, 105, 100, 32, 114, 101, 113, 117, 101, 115, 116, 34, 125]] }) }
[2022-03-03T10:43:35Z ERROR librespot_playback::player] Skipping to next track, unable to load track <SpotifyId("spotify:track:2C0iEdLXanscPYGpwO2oSm")>: ()
[2022-03-03T10:43:35Z ERROR librespot_core::session] could not dispatch command: Service unavailable { error handling Mercury response: MercuryResponse { uri: "hm://keymaster/token/authenticated?scope=playlist-read&client_id=65b708073fc0480ea92a077233ca87bd&device_id=ce8d71004f9597141d4b5940bd1bb2dc52a35dae", status_code: 403, payload: [[123, 34, 99, 111, 100, 101, 34, 58, 52, 44, 34, 101, 114, 114, 111, 114, 68, 101, 115, 99, 114, 105, 112, 116, 105, 111, 110, 34, 58, 34, 73, 110, 118, 97, 108, 105, 100, 32, 114, 101, 113, 117, 101, 115, 116, 34, 125]] } }
[2022-03-03T10:43:35Z DEBUG librespot_connect::spirc] Marked <gid: "U\332\267\0046uOl\202YV\344\261\037\241\332" context: "NonPlayable"> at 1 as NonPlayable
[2022-03-03T10:43:35Z DEBUG librespot_playback::player] command=Preload(SpotifyId("spotify:track:40NRy5xeT32HCLae48DVov"))
[2022-03-03T10:43:35Z DEBUG librespot_playback::player] Preloading track
[2022-03-03T10:43:35Z TRACE librespot_core::token] Requested token in scopes "playlist-read" unavailable or expired, requesting new token.
[2022-03-03T10:43:36Z ERROR librespot_core::mercury] error 403 for uri hm://keymaster/token/authenticated?scope=playlist-read&client_id=65b708073fc0480ea92a077233ca87bd&device_id=ce8d71004f9597141d4b5940bd1bb2dc52a35dae
[2022-03-03T10:43:36Z ERROR librespot_core::session] could not dispatch command: Service unavailable { error handling Mercury response: MercuryResponse { uri: "hm://keymaster/token/authenticated?scope=playlist-read&client_id=65b708073fc0480ea92a077233ca87bd&device_id=ce8d71004f9597141d4b5940bd1bb2dc52a35dae", status_code: 403, payload: [[123, 34, 99, 111, 100, 101, 34, 58, 52, 44, 34, 101, 114, 114, 111, 114, 68, 101, 115, 99, 114, 105, 112, 116, 105, 111, 110, 34, 58, 34, 73, 110, 118, 97, 108, 105, 100, 32, 114, 101, 113, 117, 101, 115, 116, 34, 125]] } }
[2022-03-03T10:43:36Z ERROR librespot_playback::player] Unable to load audio item: Error { kind: Unavailable, error: Response(MercuryResponse { uri: "hm://keymaster/token/authenticated?scope=playlist-read&client_id=65b708073fc0480ea92a077233ca87bd&device_id=ce8d71004f9597141d4b5940bd1bb2dc52a35dae", status_code: 403, payload: [[123, 34, 99, 111, 100, 101, 34, 58, 52, 44, 34, 101, 114, 114, 111, 114, 68, 101, 115, 99, 114, 105, 112, 116, 105, 111, 110, 34, 58, 34, 73, 110, 118, 97, 108, 105, 100, 32, 114, 101, 113, 117, 101, 115, 116, 34, 125]] }) }
[2022-03-03T10:43:36Z DEBUG librespot_playback::player] Unable to preload SpotifyId("spotify:track:40NRy5xeT32HCLae48DVov")
[...]

However, if I start librespot with -u <username> -p <password> with same build from new-api branch, I am able to play back the audio.
Maybe there were some recent changes to how the authentication is done with zeroconf?

@roderickvd
Copy link
Member

Put simply, we can't do anything about channel errors. They sometimes hit the Spotify infrastructure and then go away after some time.

The panic is due to trying to reload a track that couldn't be loaded the first time. This is fixed in new-api meaning that it won't panic anymore, but still won't be able to play the track.

There is no difference in authentication to the Spotify infrastructure between zeroconf and command line, all that matters is the way it receives the credentials (either from the command line or over the LAN). From there it authenticates against Spotify in the same way.

It's more likely that the time you logged in with command line credentials, you connected to an access point that didn't suffer from channel errors. You can check the access point in your (verbose) logs when librespot first connects.

I'm closing this as this is not something we can do anything about.

@kingosticks
Copy link
Contributor

kingosticks commented Mar 3, 2022

I do agree in general. But we could in theory provide an API to control what access point is used rather than always taking the first (or last, whatever it is, I find the comment there confusing). I am not saying that should then also be exposed to librespot application users (yet another program option) but it could.

@morphar
Copy link

morphar commented Mar 3, 2022

Just sharing info, in case it's helpful:
In DK.
2 official spotify clients working (1 not updated macOS, 1 latest releas iOS).
They play just fine, except for trying to use Spotify Connect, with anything derived from or using librespot to enable Spotify Connect (E.g. Volumio 3 and spotifyd).
Problem: Causes all tracks to skip.

@puerto-rico
Copy link

puerto-rico commented Mar 3, 2022

i am seeing same thing here. also in denmark. skips all tracks in playlist - happend on 2 pi's at the same time.
but because there where running a older version of dietpi i upgrade to bulseye and installed from scratch. with no luck.

All tracks get skipped and from journalctl -f i can see the error.

@michaelherger
Copy link
Contributor

Would everybody mind sharing

Though there have been reports from Germany and Austria, too, I strongly believe this is either a geographical thing, or some network having issues or blocking things.

@morphar
Copy link

morphar commented Mar 4, 2022

Of course! :)
Here you go:

ISP: Hiper A/S (Bought by TDC, so they probably run on their network now)
http://apresolve.spotify.com/ gives:

{"ap_list":["ap-gew4.spotify.com:4070","ap-gew4.spotify.com:443","ap-gew4.spotify.com:80","ap-guc3.spotify.com:4070","ap-gae2.spotify.com:443","ap-gew1.spotify.com:80"]}

I just did the test again and the client still does the skipping.

@roderickvd
Copy link
Member

You will also want to lookup those host names and report their IP. Same names could result in different IPs depending on geography, I’m not sure.

@morphar
Copy link

morphar commented Mar 4, 2022

ap-gew4.spotify.com: 34.158.0.131
ap-guc3.spotify.com: 104.154.127.126
ap-gae2.spotify.com: 104.199.240.237
ap-gew1.spotify.com: 104.199.65.124

@roderickvd
Copy link
Member

From The Netherlands (Ziggo) I get the same IP addresses for those hosts. My apresolve answer looks like this and I can play tracks fine:

{"ap_list":["ap-gew1.spotify.com:4070","ap-gew1.spotify.com:443","ap-gew1.spotify.com:80","ap-gew1.spotify.com:4070","ap-guc3.spotify.com:443","ap-gae2.spotify.com:80"]}

librespot picks the first access point from the list, in my case ap-gew1.spotify.com:4070. Again you can see this in your verbose logs.

@morphar
Copy link

morphar commented Mar 4, 2022

Interesting, mine chooses the ap-gew4:

[2022-03-04T11:10:10Z INFO  librespot_core::session] Connecting to AP "ap-gew4.spotify.com:4070"

And then starts skipping with these in the log:

[2022-03-04T11:10:12Z DEBUG librespot_connect::spirc] At track 4 of 30 <"spotify:playlist:37i9dQZEVXcEqdyS2qRIO4"> update [false]
[2022-03-04T11:10:12Z TRACE librespot_connect::spirc] Sending status to server: [kPlayStatusPlay]
[2022-03-04T11:10:12Z DEBUG librespot_playback::player] command=Load(SpotifyId { id: 239161766187612460604504651615889269027, audio_type: Track }, true, 0)
[2022-03-04T11:10:12Z TRACE librespot_connect::spirc] Sending status to server: [kPlayStatusPlay]
[2022-03-04T11:10:12Z INFO  librespot_playback::player] Loading <Uku> with Spotify URI <spotify:track:5tvSDMa9x46Rdd4ndtJBBh>
[2022-03-04T11:10:12Z DEBUG librespot_audio::fetch] Downloading file 3f9ee5484ef61d6d72cfccd30446eb01e2dee49a
[2022-03-04T11:10:12Z ERROR librespot_core::channel] channel error: 2 1
[2022-03-04T11:10:12Z ERROR librespot_playback::player] Unable to load encrypted file: ChannelError
[2022-03-04T11:10:12Z WARN  librespot_playback::player] Unable to load <SpotifyId { id: 239161766187612460604504651615889269027, audio_type: Track }>
    Skipping to next track

@morphar
Copy link

morphar commented Mar 4, 2022

I just tried to force the ap-gew4.spotify.com domain to point to the IP of ap-gew1.spotify.com, by setting this in /etc/hosts:

104.199.65.124  ap-gew4.spotify.com

That works!! Sooo.... Is Spotify having an issue? Or are Spotify changing something?

@michaelherger
Copy link
Contributor

Ha, you beat me to it! I wanted to test the opposite (using ap-gew4 instead of what I receive).

Yes, I believe there's a problem with that one host.

@morphar
Copy link

morphar commented Mar 4, 2022

That's annoying... Have you experienced this before? In that case: how long does this normally last? I'd rather not do this trick on my music streamer, but if it's normally a problem that takes a long time to fix, I might need to :)

Thanks for your time guys!
And thanks for this project! I love to have easy ability to get clean 320 bit directly into my DAC board :)

@michaelherger
Copy link
Contributor

I don't think it's a common problem. But it's probably still worth trying to report to Spotify?

And should librespot be smarter and not only rely on the first element in the list?

@morphar
Copy link

morphar commented Mar 4, 2022

I was thinking the same thing. Maybe there's some indicator that can be used to drop a host and try the other.
I guess in this case it could be difficult, since the server and API is responding on some calls.

@roderickvd
Copy link
Member

Channel errors are not new. If you use GitHub search on this project you will find a number of reports them. How long they'll last, only Spotify could say.

Programmatically detecting channel errors is not difficult, you literally see channel error: 2 1 in the log so we could act on that. But architecturally it's more difficult to let librespot reconnect to another access point. In new-api it's a bit easier to implement but still needs work.

@morphar
Copy link

morphar commented Mar 4, 2022

Nice that there is something to detect it by :)
But yeah... I can imagine how many little details has to be thought through in order for a total re-connect to work seamlessly.
I wish I had learned Rust by now, so that I could try to help out.

@puerto-rico
Copy link

i know it is not a beautiful solution but i can confirm that i works. as morphar suggested. :) thanks for the tip.

But instead of doing in all the pi's /etc/hosts we have implemented the redirect in our dns - 104.199.65.124 ponting to ap-gew4.spotify.com

@roderickvd
Copy link
Member

This backend is known to panic on several platforms.
Consider using some other backend, or better yet, contributing a fix.
Country: "US"
The application panicked (crashed).
Message:  could not find device
Location: /Users/brew/Library/Caches/Homebrew/cargo_cache/registry/src/github.com-1ecc6299db9ec823/librespot-playback-0.2.0/src/audio_backend/portaudio.rs:62

what is workaround? macOS 11.6

I don't think this is related to the subject of this issue.

But on Mac, just use Rodio instead of PortAudio. I don't know about this Homebrew recipe but Rodio should be the default backend anyway. Or specify --device with whatever PortAudio needs, because that's what it's complaining about.

@samflores
Copy link

samflores commented Mar 22, 2023

I've encountered this problem (I think) and don't know if it's better to create a new GH issue.

I installed the "0.5.0-dev" version yesterday and listened to a couple hours until it stopped and nothing I tried worked - changing backend, editing /etc/hosts, running under a vpn, etc.

The content of http://apresolve.spotify.com/ is:

{"ap_list":["ap-gue1.spotify.com:4070","ap-gue1.spotify.com:443","ap-gue1.spotify.com:80","ap-gew1.spotify.com:4070","ap-gae2.spotify.com:443","ap-guc3.spotify.com:80"]}

I'm starting librespot with librespot -u "<elided>" -p "<elided>" --backend pulseaudio --disable-audio-cache --enable-volume-normalisation --initial-volume=100 -v and seeing this in the log when I try to play anything:

[2023-03-22T12:37:44Z DEBUG librespot_core::spclient] Client token unavailable or expired, requesting new token.
[2023-03-22T12:37:44Z DEBUG librespot_core::http_client] Requesting https://clienttoken.spotify.com/v1/clienttoken
[2023-03-22T12:37:45Z TRACE librespot_core::spclient] Got client token: GrantedTokenResponse { token: "<elided>", expires_after_seconds: 1216800, refresh_after_seconds: 1209600, domains: [TokenDomain { domain: "spotify.com", special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }, TokenDomain { domain: "spotify.net", special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }], special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }
[2023-03-22T12:37:45Z DEBUG librespot_core::http_client] Requesting https://gue1-spclient.spotify.com:443/radio-apollo/v3/tracks/spotify:playlist:2UZNfy8WUroWSoirsnHtom?autoplay=false&product=0&country=BR&salt=1654385305
[2023-03-22T12:37:45Z TRACE librespot_core::spclient] Got client token: GrantedTokenResponse { token: "<elided>", expires_after_seconds: 1216800, refresh_after_seconds: 1209600, domains: [TokenDomain { domain: "spotify.com", special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }, TokenDomain { domain: "spotify.net", special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }], special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }
[2023-03-22T12:37:45Z DEBUG librespot_core::http_client] Requesting https://gue1-spclient.spotify.com:443/metadata/4/track/a1df9480c2bd4ffd9ea91ca2dee3e992?product=0&country=BR&salt=2730999404
[2023-03-22T12:37:45Z ERROR librespot_connect::spirc] ContextError: Error { kind: PermissionDenied, error: StatusCode(403) }
[2023-03-22T12:37:45Z TRACE librespot_connect::spirc] ==> kPlayStatusPause
[2023-03-22T12:37:45Z TRACE librespot_connect::spirc] Sending status to server: [kPlayStatusPause]
[2023-03-22T12:37:45Z ERROR librespot_playback::player] Unable to load audio item: Error { kind: PermissionDenied, error: StatusCode(403) }
[2023-03-22T12:37:45Z ERROR librespot_playback::player] Skipping to next track, unable to load track <SpotifyId("spotify:track:4VrWlk8IQxevMvERoX08iC")>: ()
[2023-03-22T12:37:45Z DEBUG librespot_connect::spirc] Marked <TrackRef { gid: Some([161, 223, 148, 128, 194, 189, 79, 253, 158, 169, 28, 162, 222, 227, 233, 146]), uri: None, queued: None, context: Some("NonPlayable"), special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }> at 0 as NonPlayable
[2023-03-22T12:37:45Z DEBUG librespot_playback::player] command=Preload(SpotifyId("spotify:track:1zeH4lyTUZBp567d6K6zTM"))
[2023-03-22T12:37:45Z DEBUG librespot_playback::player] Preloading track
[2023-03-22T12:37:45Z DEBUG librespot_core::http_client] Requesting https://gue1-spclient.spotify.com:443/metadata/4/track/3387daeed88e4ffc87a270defff49ebe?product=0&country=BR&salt=66342655
[2023-03-22T12:37:46Z ERROR librespot_playback::player] Unable to load audio item: Error { kind: PermissionDenied, error: StatusCode(403) }
[2023-03-22T12:37:46Z DEBUG librespot_playback::player] Unable to preload SpotifyId("spotify:track:1zeH4lyTUZBp567d6K6zTM")

@roderickvd
Copy link
Member

Weird. Have you tried blacklisting ap-gue1.spotify.com in /etc/hosts? See if another access point will work?

@samflores
Copy link

If I point it to 0.0.0.0 librespot just closes and in the log I get:

[2023-03-22T13:18:45Z INFO  librespot_core::session] Connecting to AP "ap-gue1.spotify.com:4070"
[2023-03-22T13:18:45Z DEBUG librespot_playback::player] Shutting down player thread ...
[2023-03-22T13:18:45Z DEBUG librespot_playback::player] drop PlayerInternal[0]
[2023-03-22T13:18:45Z DEBUG librespot_playback::player] PlayerInternal thread finished.
[2023-03-22T13:18:45Z ERROR librespot] could not initialize spirc: Service unavailable { Connection refused (os error 111) }

If I block apresolve.spotify.com, though, I see this:

[2023-03-22T13:22:09Z WARN  librespot_core::apresolve] Failed to resolve all access points, using fallbacks
[2023-03-22T13:22:09Z WARN  librespot_core::apresolve] Resolve access points error: Service unavailable { error trying to connect: tcp connect error: Connection refused (os error 111) }
[2023-03-22T13:22:09Z INFO  librespot_core::session] Connecting to AP "ap.spotify.com:443"

but when I try to play anything I get the same error, with a different URL:

[2023-03-22T13:23:09Z DEBUG librespot_core::http_client] Requesting https://spclient.wg.spotify.com:443/metadata/4/track/e666c6ccc4c7437f83552aa9bf4f2cfd?product=0&country=BR&salt=3571593297
[2023-03-22T13:23:09Z ERROR librespot_playback::player] Unable to load audio item: Error { kind: PermissionDenied, error: StatusCode(403) }
[2023-03-22T13:23:09Z DEBUG librespot_playback::player] Unable to preload SpotifyId("spotify:track:70LcF31zb1H0PyJoS1Sx1r")

@smilg
Copy link

smilg commented Mar 27, 2023

FWIW I'm having the same issue, though I'm unable to modify /etc/hosts due to some details of my setup. Did you happen to find a fix?

@bjorgvino
Copy link

I ran into this on a Raspberry Pi running raspotify. I've been able to use it to play music from Spotify without problems, but all of the sudden I started getting this error when trying to play tracks - and tracks just skipped ahead immediately all the time:

Aug 30 12:56:08 Grottan librespot[558]: [2024-08-30T10:56:08Z ERROR librespot_core::channel] channel error: 2 0
Aug 30 12:56:08 Grottan librespot[558]: [2024-08-30T10:56:08Z ERROR librespot_playback::player] Unable to load encrypted file: ChannelError
Aug 30 12:56:08 Grottan librespot[558]: [2024-08-30T10:56:08Z ERROR librespot_playback::player] Skipping to next track, unable to load track <SpotifyId { id: 293957129610060129689800402008964857369, audio_type: Track }>: ()
Aug 30 12:56:08 Grottan librespot[558]: [2024-08-30T10:56:08Z ERROR librespot_core::channel] channel error: 2 0
Aug 30 12:56:08 Grottan librespot[558]: [2024-08-30T10:56:08Z ERROR librespot_playback::player] Unable to load encrypted file: ChannelError

The output of http://apresolve.spotify.com/ for me is:

{"ap_list":["ap2-gew4.spotify.com:4070","ap2-gew4.spotify.com:443","ap2-gew4.spotify.com:80","ap2-guc3.spotify.com:4070","ap2-gue1.spotify.com:443","ap2-gew1.spotify.com:80"]}

If I block apresolve.spotify.com, i.e. add the following to /etc/hosts: 0.0.0.0 apresolve.spotify.com, raspotify on my Raspberry Pi starts working again because it falls back to ap.spotify.com:443:

Aug 30 13:29:01 Grottan librespot[2870]: [2024-08-30T11:29:01Z INFO  librespot] librespot 0.4.2 a6e1258 (Built on 2023-06-21, Build ID: g9ifMDjd, Profile: release)
Aug 30 13:29:15 Grottan librespot[2870]: [2024-08-30T11:29:15Z WARN  librespot_core::apresolve] Failed to resolve Access Point: error trying to connect: tcp connect error: Connection refused (os error 111)
Aug 30 13:29:15 Grottan librespot[2870]: [2024-08-30T11:29:15Z WARN  librespot_core::apresolve] Using fallback "ap.spotify.com:443"
Aug 30 13:29:15 Grottan librespot[2870]: [2024-08-30T11:29:15Z INFO  librespot_core::session] Connecting to AP "ap.spotify.com:443"

Yay!

@mrkickling
Copy link

mrkickling commented Sep 1, 2024

Had the same problem, can verify that @bjorgvino solution worked. Thanks!

EDIT: Stopped working sep 4th

@MitraMai
Copy link

MitraMai commented Sep 1, 2024

@bjorgvino 's solution worked for me! Many thanks!

@web-sash
Copy link

web-sash commented Sep 2, 2024

@bjorgvino 's solution worked for me also! Thanks a lot..

The fix stoppped working today 04. September. ap.spotify.com doesn't seem to be reachable anymore

@kingosticks
Copy link
Contributor

Are you all using zeroconf to authenticate ?

@kingosticks
Copy link
Contributor

I can answer my own question: no, it's not directly due to authentication method. Please correct me if I am wrong, but it's presumably because you're all using v0.4.x. This problem doesn't exist for me in the dev branch, but does in the master branch.

@bjorgvino
Copy link

Yeah I'm using the latest release, 0.4.2.

No authentication. It's just that the first access point doesn't seem to work for me (and others it seems), perhaps because of the port, or something completely different, and the fallback logic doesn't seem to kick in... i.e. it doesn't try the other access points.

Btw what I posted was not in any way "my solution", I just tried stuff already suggested in this thread and reported back how it went..

@kingosticks
Copy link
Contributor

It would only try the other access points it connecting fails. In the cases here, connection and authentication are seemingly work fine, it's the subsequent requesting of audio data that fails when using certain access points.

I appreciate not your solution, I was just trying to work out if further investigation was required. But given this all works in the latest code (that obtains audio data a different way), the answer is no.

@bjorgvino
Copy link

Understood. Perhaps a new release is in order then?

@truppelito
Copy link

Blocking apresolve.spotify.com on my AdGuard Home server worked for me too.

@bestlibre
Copy link

bestlibre commented Sep 3, 2024

It worked for me until this morning. I'm getting the same error with the ap.spotify.com fallback

@kingosticks
Copy link
Contributor

Then you'll have to switch to the real fix. which is to compile using the dev branch.

@mloskot
Copy link

mloskot commented Sep 4, 2024

#972 (comment) workaround does not work for me:

$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 s4ap
# spotify_player workaround, see https://github.com/librespot-org/librespot/issues/972#issuecomment-2320943137
0.0.0.0 apresolve.spotify.com
...

restart spotify_player and it keeps skipping as I show in

@jaypi95
Copy link

jaypi95 commented Sep 9, 2024

Then you'll have to switch to the real fix. which is to compile using the dev branch.

I did this two days ago because of the zeroconf thing but as of this morning it stopped working again. Overriding the DNS entry also didn't work this time.

But blocking apresolve.spotify.com did the trick!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
SpotifyAPI Interop b/w librespot and Spotify
Projects
None yet
Development

Successfully merging a pull request may close this issue.