Suddenly unable to play any tracks

[kosimst]

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

[roderickvd]

Yes blocking apresolve blocks the resolving mechanism altogether.

It would be helpful if you could list those other access points besides ap-gew4 on those 2/3 devices that did not work for you?

[HippieWithGuns]

Fix worked for me aswell! Thank you so much <3 User from Switzerland here. and just to be clear the fix for me was: add this line to etc/hosts 0.0.0.0 apresolve.spotify.com

[Boobybandit]

Yes blocking apresolve blocks the resolving mechanism altogether.

It would be helpful if you could list those other access points besides ap-gew4 on those 2/3 devices that did not work for you?

Unfortunately I can't extract logs from my spotify implementation in Hifiberry (or don't know how). But, I just randomly tried adding other servers and apparently my 1 Hifiberry device uses "ap-guc3.spotify.com". Rerouting this to 104.199.65.124 did the trick. Seems completely random as I have 3 Hifiberry devices here and 1 uses the ap-gew4, the other ap-guc3 and the third I haven't checked yet. My ISP is KPN (glasvezel).

My (foolproof) suggestion would be to add multiple servers to the hosts file, pointing to 104.199.65.124 or blocking apresolve.

[roderickvd]

Hmm. You’re the first to report defunct servers other than ap-gew4 but this may be because so many others are blocking the resolver completely.

I’d like some confirmation on this because it matters for the PR I linked to. I don’t like blocking the resolver completely but if access point compatibility is dropping like flies then we might have to. Note that the GeoIP-based fallback might still direct you to a broken server so it’s not entirely foolproof.

HiFiBerryOS runs Spotifyd right? That’s a good crew but know that it’s still running on librespot 0.2 so I am unsure how fast they will pick up a librespot point release with a small fix.

[jarmoniuk]

I have just made a test by using each gateway's IP address for all hosts in /etc/hosts and it turns out only 34.158.0.131 (which is ap-gew4) is using the new interface so far.

[raabf]

librespot also did stop working for me since this morning due to the problem described in this issue. I am located in Bavaria, Germany. my apresolve.spotify.com also contains the ap-gew4 as first entry.

root@al:~# curl apresolve.spotify.com
{"ap_list":["ap-gew4.spotify.com:4070","ap-gew4.spotify.com:443","ap-gew4.spotify.com:80","ap-gew1.spotify.com:4070","ap-guc3.spotify.com:443","ap-gae2.spotify.com:80"]}

Can confirm that adding

0.0.0.0                apresolve.spotify.com

OR

# IP of ap-guc3.spotify.com
104.154.127.126         ap-gew4.spotify.com

to /etc/hosts both work for me.

[piotrzieba]

Hello, noob here – I added following line to /etc/hosts of Spotify service (via Balena dashboard -> Terminal -> Spotify target -> then editedd with vi, saved with :x), but the changes are not kept after rebooting.

Could you please explain step by step how to make this fix?

Context: unable to play songs since this morning, I'm also located in Germany. I'm using BalenaSound, not Librespot, but this issue has been seen across many platforms (also Volumio afaic)

[coaxial]

Hello, noob here – I added following line to /etc/hosts of Spotify service (via Balena dashboard -> Terminal -> Spotify target -> then editedd with vi, saved with :x), but the changes are not kept after rebooting.

Could you please explain step by step how to make this fix?

Context: unable to play songs since this morning, I'm also located in Germany. I'm using BalenaSound, not Librespot, but this issue has been seen across many platforms (also Volumio afaic)

It seems like you're running in a container. You have to make this change in the container's config or network wide (typically in your router). It very much depends on your particulars: ask the community support for your container image or check how to do it with your particular router model.

[roderickvd]

I merged #1026 with a fix for ap-gew4. If nothing else pops up I will do a 0.4.2 release the coming days.

[marciogranzotto]

@roderickvd also having the same problem with ap-gue1

[miguelprates]

@roderickvd also having the same problem with ap-gue1

Here in Brazil ap-gue1 is the problem. I had to redirect dns from ap-gue1 to ap-gew1 on my router and now it's working.

[mario-ruoff]

Hello, noob here – I added following line to /etc/hosts of Spotify service (via Balena dashboard -> Terminal -> Spotify target -> then editedd with vi, saved with :x), but the changes are not kept after rebooting.

Could you please explain step by step how to make this fix?

Context: unable to play songs since this morning, I'm also located in Germany. I'm using BalenaSound, not Librespot, but this issue has been seen across many platforms (also Volumio afaic)

I just temporary fixed the issue for BalenaSound by adding a command in the start.sh file of the Spotify Docker container:

1. locate the file in plugins/spotify/start.sh
2. Add the following line before the "set" command for librespot (almost last command): echo "104.154.127.126 ap-gew4.spotify.com" >> /etc/hosts
3. Push the new code to BalenaCloud via balena push or git

[roderickvd]

Thanks @miguelprates and @marciogranzotto, I will add ap-gue1 to the blacklist and do a release. Hope this will cover most of the cases and otherwise people can use any of the workarounds mentioned in this issue.

Will thereafter focus on development of new-api which is where the real fix is -- that new API doesn't run into trouble with any of these access points because it downloads files over HTTP instead of Mercury.

[roderickvd]

v0.4.2 has been released: https://github.com/librespot-org/librespot/releases/tag/v0.4.2

[nis65]

Just to help others that come here with the same error: I have a setup with a dnsmasq in my internal network and multiple librespot devices in that. network. So if you add

0.0.0.0 apresolve.spotify.com

to your dnsmasq config (e.g. /etc/hosts) on your (wlan) router, all librespot devices profit immediately from that fix. Of course it's better to upgrade :smile:

[HippieWithGuns]

Just to help others that come here with the same error: I have a setup with a dnsmasq in my internal network and multiple librespot devices in that. network. So if you add

0.0.0.0 apresolve.spotify.com

to your dnsmasq config (e.g. /etc/hosts) on your (wlan) router, all librespot devices profit immediately from that fix. Of course it's better to upgrade 😄

May i ask what you mean by, of corse it's better to update? is there any newer client to stream spotify to a pi, or what do you mean? :)

[roderickvd]

v0.4.2 works around the issue for two known bad access points.

You can also compile 0.5.0-dev from source which fixes the issue entirely by using another API. It’s in actively development so expect other bugs (and we’d welcome the feedback).

[JasonLG1979]

v0.4.2 works around the issue for two known bad access points.

You can also compile 0.5.0-dev from source which fixes the issue entirely by using another API. It’s in actively development so expect other bugs (and we’d welcome the feedback).

Not so much. I'm getting 403 errors for hm://keymaster/token/authenticated?scope=playlist-read on 0.5.0-dev I have no problems with v0.4.2 though.

It looks like they're shutting down or at least scaling back that interface.

...
[2022-08-25T16:30:20Z ERROR librespot_core::mercury] error 403 for uri hm://keymaster/token/authenticated?scope=playlist-read&client_id=65b708073fc0480ea92a077233ca87bd&device_id=ce8d71004f9597141d4b5940bd1bb2dc52a35dae
...

[roderickvd]

v0.4.2 works around the issue for two known bad access points. You can also compile 0.5.0-dev from source which fixes the issue entirely by using another API. It’s in actively development so expect other bugs (and we’d welcome the feedback).

Not so much. I'm getting 403 errors for hm://keymaster/token/authenticated?scope=playlist-read on 0.5.0-dev I have no problems with v0.4.2 though.

Which commit of 0.5.0-dev is this, the latest?

It looks like they're shutting down or at least scaling back that interface.

I don't know, 0.4.2 uses the old keymaster ID only, so if it works on that version then it would be evidence to the contrary...

...
[2022-08-25T16:30:20Z ERROR librespot_core::mercury] error 403 for uri hm://keymaster/token/authenticated?scope=playlist-read&client_id=65b708073fc0480ea92a077233ca87bd&device_id=ce8d71004f9597141d4b5940bd1bb2dc52a35dae
...

I'll try and fiddle with this tonight. With @SuisChan's code to solve the hashcash challenge, I can revert-and-update https://github.com/librespot-org/librespot/commit/cdf84925ad0bf3b872a13922a0e9ee9523e17f26 and pass the real client ID everywhere. This should be the way forward, I think.

[JasonLG1979]

Which commit of 0.5.0-dev is this, the latest?

Yep. I started having issues last night. My PR branch and the latest dev have the same problem (which stands to reason since I didn't mess with those bits).

I don't know, 0.4.2 uses the old keymaster ID only, so if it works on that version then it would be evidence to the contrary...

I don't know either? I haven't really dug that deep in the network code?

[roderickvd]

From the top of my head it might not send the device_id and now that we do, some servers may not like when that device_id does not correspond to some authenticated client_id, I don't know. No matter, let's focus on solving the challenge and then we can test that.

I can't reproduce your issue here from The Netherlands. Let me see if I can get it working tonight, so you can still test on a "misbehaving" access point.

[JasonLG1979]

From the top of my head it might not send the device_id and now that we do, some servers may not like when that device_id does not correspond to some authenticated client_id, I don't know. No matter, let's focus on solving the challenge and then we can test that.

I can't reproduce your issue here from The Netherlands. Let me see if I can get it working tonight, so you can still test on a "misbehaving" access point.

Sounds good. I'm pretty keen on providing reasonably full metadata over events. I think that would make users and upstream pretty happy to not rely on some other separate mechanism to retrieve it.

But again I think that should be a separate PR after my current one is merged.

[roderickvd]

Working on it now. For posterity, the hashcash challenge is not presented when you say you're a Mac, but it is when you say you're on Linux 😕

[JasonLG1979]

Working on it now. For posterity, the hashcash challenge is not presented when you say you're a Mac, but it is when you say you're on Linux

Can we just lie?

[JasonLG1979]

Working on it now. For posterity, the hashcash challenge is not presented when you say you're a Mac, but it is when you say you're on Linux

I just tried it again after the revert. No go. Still not working.

[roderickvd]

Yes I see it too on Linux (and not on macOS). It's not even that we're presented a hash cash challenge, it just fails outright with a HTTP/400 when requesting the client token. The Spotify servers are really picky about the header values that you send, it must be that we're sending some they don't like all of the sudden.

I tried "lying" by changing more than a few instances of Linux -> macOS but I haven't found it yet, argh...

[JasonLG1979]

Yes I see it too on Linux (and not on macOS). It's not even that we're presented a hash cash challenge, it just fails outright with a HTTP/400 when requesting the client token. The Spotify servers are really picky about the header values that you send, it must be that we're sending some they don't like all of the sudden.

I tried "lying" by changing more than a few instances of Linux -> macOS but I haven't found it yet, argh...

It's very strange that I have no problem with v0.4.2?

[roderickvd]

This concerns the HTTP client token in spclient, v0.4.2 doesn't have that at all.

[JasonLG1979]

This concerns the HTTP client token in spclient, v0.4.2 doesn't have that at all.

See I told you I know basically nothing about the network stuff,lol!!! Kinda on that note I'm wondering if we can get the user's display-name I saw it somewhere in the web API docs, can't remember where but it would be nice to add that to the Connected and Disconnected events. Currently what we call the "username" is really the user-id and that's not super useful for the event for display purposes. It would be nice to have the "pretty" name.

[JasonLG1979]

My idea for the events is to make it trivial for upstream to be able to display the user's display-name along with the client device's name and all the relevant metadata. I'm sure moode and such would like that. Last I checked they don't display anything when using librespot?

[JasonLG1979]

With all that info you could write a pretty basic Python script to push to the framebuffer on a Pi for example and not even need an event loop. It could just be driven purely by the events.

[roderickvd]

You may want to try the latest commit, it works on Linux and macOS here. If it doesn't for you, please let me know your access point so I can manually try to connect to that.

It sure looks like Spotify is changing things on their end. Linux is now no longer presented a hash cash challenge. It was some weeks ago... to make Linux get a client ID again we still have to use the keymaster ID.

In case any hash cash challenge is thrown at us, @SuisChan's excellent example over at https://github.com/SuisChan/ctk-example shows how it is done for Android. I have ported this code, but not tested it, so at this point consider it experimental.

I was mixing up the client token (which I was working on) and the Mercury 403 error for the "normal" token you posted above. Again, let me know which access point is troubling you and I can try some stuff. Basically this is trial and error swapping between the keymaster ID and real client ID, and having the device ID there, removed, or truncated to 16 characters.

At this point it's clear that Spotify isn't consistent cross-platform and we should take care to test stuff like this on the major OSs.

I have not had the time to look at your event code but let's keep the discussion with that PR.

[JasonLG1979]

Still no go.

...
[2022-08-26T00:07:41Z INFO  librespot_core::session] Connecting to AP "ap-guc3.spotify.com:4070"
...
[2022-08-26T00:07:42Z INFO  librespot_core::spclient] Resolved "guc3-spclient.spotify.com:443" as spclient access point
...
[2022-08-26T00:07:42Z ERROR librespot_core::mercury] error 403 for uri hm://keymaster/token/authenticated?scope=playlist-read&client_id=65b708073fc0480ea92a077233ca87bd&device_id=ce8d71004f9597141d4b5940bd1bb2dc52a35dae
[2022-08-26T00:07:42Z 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]] }) }
...

[roderickvd]

Totally weird. I just connected to that AP manually and no problems here. But off to bed now...

[JasonLG1979]

Totally weird. I just connected to that AP manually and no problems here. But off to bed now...

Yep, I don't know what to say?

[JasonLG1979]

I have 2 other librespot devices both running v0.4.2 one wired and one on wifi and they both work fine. I even build v0.4.2 on my desktop and it works fine so it's not a network issue as far as I can tell?

[roderickvd]

I don't know either. I tried both on Linux and macOS, both successful. Can you try v0.5.0 on those other devices, see if that matters or if it sticks to a certain OS?

[JasonLG1979]

Can you try v0.5.0 on those other devices, see if that matters or if it sticks to a certain OS?

I already did. It didn't matter as they are all Linux, my desktop runs Fedora, my server runs Debian and and my Pi Zero v2 runs RaspberryPiOS.

It must be some kind of geo location blocking thing? I'm looking for a free proxy that's compatible with librespot, as in is http(s)://Host:Port and not IP:Port. Librespot errors out if you try to use a IP:Port proxy.

[JasonLG1979]

I would consider not being able to use a IP:Port style proxy a bug or at least a missing feature if you already have http(s)://Host:Port support. I will look into that and see what I can do.

[kingosticks]

As a temporary workaround here, can you use an entry in /etc/hosts to do this?

[JasonLG1979]

As a temporary workaround here, can you use an entry in /etc/hosts to do this?

Tried that already also. No dice. I added this to my /etc/hosts:

104.199.65.124 ap-guc3.spotify.com
2600:1901:1:5ca:: guc3-spclient.spotify.com

Where 104.199.65.124 is the IP to ap-gew1.spotify.com and 2600:1901:1:5ca:: is the IP to gew1-spclient.spotify.com.

[JasonLG1979]

I even tried connecting to my phone via a hotshot so my IP was different.

[kingosticks]

Sorry, maybe I misunderstood what you were trying to do, but I meant you could add an entry for the free hostname-only proxy you are trying to use in order to avoid the geo-restiction.

[JasonLG1979]

Sorry, maybe I misunderstood what you were trying to do, but I meant you could add an entry for the free hostname-only proxy you are trying to use in order to avoid the geo-restiction.

I tried setting up a proxy via GNOME's network settings but none of them actually worked that I could find.

I have never really had to mess with proxies and I just googled setting a proxy in /etc/hosts and everything I read says that you can't redirect to specific ports in /etc/hosts so that's not very useful.

[kingosticks]

I was talking about a workaround for

Librespot errors out if you try to use a IP:Port proxy.

/etc/hosts

some.proxy.you.only.have.an.ip.for foo.com

Then use proxy http://foo.com:Port with librespot, which it should like, but you'll actually have a connection to some.proxy.you.only.have.an.ip.for.

Years ago when I tried random free proxies on the net, they never worked. Alternatively there are some free VPN services these days, that should Just Work.

[JasonLG1979]

Alternatively there are some free VPN services these days, that should Just Work.

The only free VPN's I can find are IPV4 only and *-spclient.spotify.com seems to be IPV6 only.

I even tried to power cycle my modem to get a different IP from my ISP which worked in the sense that I got a different IP, before my IP said I was in New York City, New York no I'm apparently now I'm in Hamilton Missouri. I ofc are in neither of those places,lol!!! But that was no good either.

[JasonLG1979]

Well as a workaround I just tried to use my Spotify creds and that worked without a hitch.

[JasonLG1979]

I feel kinda stupid because I didn't try that sooner :man_facepalming: but it still doesn't solve the problem of zeroconf auth not working.

[roderickvd]

Still don't have a clue what's going on. Maybe you can sprinkle some traces around the Mercury sending code, to see the difference in request we're making depending on whether you're using zeroconf or command-line authentication?

[SuisChan]

...spot_core::mercury] error 403 for uri hm://keymaster/token/authenticated?scope=playlist-read&client_id=65b708073fc0480...

Hey! Are you having trouble getting an access token via hm://keymaster... or something else?

Why not (as an experiment) try to take it from login5 endpoint? (since it returns noy only the login credentials but also the token, but don't know what scopes it has since no information provided).