(07-22-2022, 03:01 AM)TheOldPresbyope Wrote: As I read the librespot github repo issues log, there seem to be at least two different problems cropping up.

One is the inability sometimes to reach certain Spotify "AP" servers by their FQDN. This error prevents connection. It seems not to happen to all the users having problems but this is the reason some believe all one has to do is add some lines to the /etc/hosts file. 

The other problem has to do with a recurring issue with certain Spotify servers throwing "channel" errors. This error occurs after connection has been made and prevents playing the selected track.

It would seem these errors are affecting mostly European users. I have never seen them, which has made it impossible for me to gather my own diagnostic data.

However, anyone with a working knowledge of the Linux command line can gather their own diagnostic data.

First:

Using a host on the same LAN as your moOde player, visit the site https://apresolve.spotify.com in your favorite web browser to get the list of Spotify AP servers being offered in your region.

Here's the response I get using a Chromium browser on my Linux laptop connected to the Internet via an ISP located in Maryland/USA. (I prefer the way Firefox formats this JSON list but I couldn't easily copy the formatted output.)

Code:

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

All of these AP servers are resolvable and accessible from my location but apparently librespot will use only the first instance in the list.
 
Then:

• Disconnect any Spotify app which may be connected to the moOde player
  
• Turn off the Spotify renderer in the moOde player's Audio Config panel.
  
• Start the following on the moOde player's command line
  sudo librespot --name SpotifyTest -v > SpotifyTest.txt 2>&1
  
• Using your favorite Spotify App, connect to the resulting "SpotifyTest" device
  
• In the Spotify App, select and play a track or at least a portion of it
  
• Disconnect the Spotify App from the "SpotifyTest" device
  
• Kill the librespot process you started on the moOde player's command line (Hint: use ctrl-C).
  
• Still on the command line, review the content of the file SpotifyTest.txt left in the current directory.
  

Candidly, I don't know if and which various keys in the output are "secrets" but the output is voluminous so I'm not posting all of it. Here's the beginning of the output collected on one of my moOde players

Code:

[2022-07-22T02:13:33Z INFO  librespot] librespot 0.4.1 88e64bd (Built on 2022-07-07, Build ID: KpGv9iLt, Profile: release)
[2022-07-22T02:13:33Z TRACE librespot] Command line argument(s):
[2022-07-22T02:13:33Z TRACE librespot]         --name "SpotifyTest"
[2022-07-22T02:13:33Z TRACE librespot]         -v
[2022-07-22T02:13:33Z DEBUG librespot_discovery::server] Zeroconf server listening on 0.0.0.0:34759
[2022-07-22T02:13:49Z DEBUG librespot_discovery::server] POST "/" {}
[2022-07-22T02:13:49Z INFO  librespot_core::session] Connecting to AP "ap-guc3.spotify.com:4070"
[2022-07-22T02:13:50Z INFO  librespot_core::session] Authenticated as "<<user id redacted>>" !
...

As can be seen, librespot connected to the first AP server in the list I presented above. This is where the first known error would become apparent.

Later in the output, after I had told my Spotify App to play a specific track, there appears the snippet

Code:

[2022-07-22T02:13:50Z INFO  librespot_playback::player] Loading <24 Preludes, Op. 28: No. 15 in D-Flat Major "Raindrop"> with Spotify URI <spotify:tr
ack:<<track ID redacted>>>
[2022-07-22T02:13:50Z DEBUG librespot_audio::fetch] Downloading file <<file id redacted>>
[2022-07-22T02:13:50Z DEBUG librespot::component] new ChannelManager
...

 
and, of course, this is where the second known error ("Channel error...") would become apparent. Any other types of errors you observe should be reported to the librespot github repo issues log.

Note that the two known problems are due to Spotify's services. See the librespot github repo issues log to get a feel for how the librespot devs feel about them.

Regards,
Kent

(07-22-2022, 03:21 AM)Tim Curtis Wrote:

(07-22-2022, 03:01 AM)TheOldPresbyope Wrote: As I read the librespot github repo issues log, there seem to be at least two different problems cropping up.

...

You may want to post a link to this analysis in the librespot repo. It may be helpful for the dev's.

(07-26-2022, 06:52 PM)roderickvd Wrote: I will make some time and soon do a librespot point release to blacklist this broken access point. Are there more defunct APs that any of you have encountered? If so please add them to this issue: https://github.com/librespot-org/librespot/issues/972

Edit: fix is here: https://github.com/librespot-org/librespot/pull/1026
Please verify and I can do a release the coming few days.

(07-26-2022, 09:52 PM)Ja Tim Curtis Wrote:

(07-26-2022, 06:52 PM)roderickvd Wrote: I will make some time and soon do a librespot point release to blacklist this broken access point. Are there more defunct APs that any of you have encountered? If so please add them to this issue: https://github.com/librespot-org/librespot/issues/972

Edit: fix is here: https://github.com/librespot-org/librespot/pull/1026
Please verify and I can do a release the coming few days.

Many thanks :-)

After you release it will take our project a few weeks to build, test and publish a new librespot package. Are there recommended workarounds that users can try in the meantime? 

I've seen a couple but have not tried them myself.

1. Add --ap-port=[some random port] to librespot launch params.
2. Add 0.0.0.0 apresolve.spotify.com to the file /etc/hosts

(07-26-2022, 09:52 PM)Tim Curtis Wrote: 2. Add 0.0.0.0 apresolve.spotify.com to the file /etc/hosts