Audio Breaks up when using Cspot for 5+ hours

[rickyfajar93]

Does anyone experiencing this issue? cspot bitrate 320Kbps

currently running : 2.1652-16#v4.3#I2S-4MFlash#master-v4.3 on ESP32-CAM with 16Mflash & 8M PSRAM

Thankyou.

[sle118]

There is a template for submitting issues. Please follow it as otherwise we spend too much time getting to the important details.

[rickyfajar93]

Terribly sorry for the inconvenience , here's the complete log

`<27>[0m[00:00:50.267] <27>[0;31mD <27>[0;94mSpircHandler.cpp<27>[0m:69: Received subscription response<\r><\n>
<27>[0m[00:00:50.285] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:252: Executing Mercury Request, type SEND<\r><\n>
[00:00:50.316] cspot_cmd_handler:429 CSpot volume 1024<\r><\n>
<27>[0m[00:00:50.702] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 178<\r><\n>
<27>[0m[00:00:50.705] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:174: Received mercury packet<\r><\n>
<27>[0m[00:00:50.958] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 181<\r><\n>
<27>[0m[00:00:50.961] <27>[0;31mD <27>[0;94mSpircHandler.cpp<27>[0m:69: Received subscription response<\r><\n>
<27>[0m[00:00:50.986] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:252: Executing Mercury Request, type SEND<\r><\n>
[00:00:51.020] cspot_cmd_handler:429 CSpot volume 2048<\r><\n>
<27>[0m[00:00:51.460] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 181<\r><\n>
<27>[0m[<27>[0m[00:0000::5100:.5100.463469] ] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 178<\r><\n>
<27>[0;31mD <27>[0;94mSpircHandler.cpp<27>[0m:69: Received subscription response<\r><\n>
<27>[0m[00:00:51.489] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:252: Executing Mercury Request, type SEND<\r><\n>
[00:00:51.508] cspot_cmd_handler:429 CSpot volume 4096<\r><\n>
<27>[0m[00:00:51.515] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:174: Received mercury packet<\r><\n>
<27>[0m[00:00:51.720] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 181<\r><\n>
<27>[0m[00:00:51.723] <27>[0;31mD <27>[0;94mSpircHandler.cpp<27>[0m:69: Received subscription response<\r><\n>
<27>[0m[00:00:51.740] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:252: Executing Mercury Request, type SEND<\r><\n>
[00:00:51.764] cspot_cmd_handler:429 CSpot volume 12288<\r><\n>
<27>[0m[00:00:52.001] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 178<\r><\n>
<27>[0m[00:00:52.003] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:174: Received mercury packet<\r><\n>
<27>[0m[00:00:52.251] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 178<\r><\n>
<27>[0m[00:00:52.<27>[0m254] [<27>[0;31mD 00:<27>[0;37mMercurySession.cpp<27>[0m00:174: :Received mercury packet<\r><\n>
52.255] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 181<\r><\n>
<27>[0m[00:00:52.269] <27>[0;31mD <27>[0;94mSpircHandler.cpp<27>[0m:69: Received subscription response<\r><\n>
<27>[0m[00:00:52.292] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:252: Executing Mercury Request, type SEND<\r><\n>
[00:00:52.314] cspot_cmd_handler:429 CSpot volume 19456<\r><\n>
<27>[0m[00:00:52.511] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 181<\r><\n>
<27>[0m[00:00:52.516] <27>[0;31mD <27>[0;94mSpircHandler.cpp<27>[0m:69: Received subscription response<\r><\n>
<27>[0m[00:00:52.524] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:252: Executing Mercury Request, type SEND<\r><\n>
[00:00:52.554] cspot_cmd_handler:429 CSpot volume 27648<\r><\n>
<27>[0m[00:00:52.744] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 178<\r><\n>
<27>[0m[00:00:52.746] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:174: Received mercury packet<\r><\n>
<27>[0m[00:00:52.969] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 178<\r><\n>
<27>[0m[00:00:52.971] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m<27>[0m:174: Received mercury packet[<\r><\n>
00:00:52.972] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 181<\r><\n>
<27>[0m[00:00:52.987] <27>[0;31mD <27>[0;94mSpircHandler.cpp<27>[0m:69: Received subscription response<\r><\n>
<27>[0m[00:00:53.010] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:252: Executing Mercury Request, type SEND<\r><\n>
[00:00:53.035] cspot_cmd_handler:429 CSpot volume 35839<\r><\n>
<27>[0m[00:00:53.236] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 181<\r><\n>
<27>[0m[00:00:53.239] <27>[0;31mD <27>[0;94mSpircHandler.cpp<27>[0m:69: Received subscription response<\r><\n>
<27>[0m[00:00:53.256] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:252: Executing Mercury Request, type SEND<\r><\n>
[00:00:53.280] cspot_cmd_handler:429 CSpot volume 39935<\r><\n>
<27>[0m[00:00:53.481] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 181<\r><\n>
<27>[0m<27>[0m[[00:00:00:00:53.53485.] <27>[0;34mI 485] <27>[0;37mMercurySession.cpp<27>[0m<27>[0;31mD :42: <27>[0m<27>[0;94mSpircHandler.cpp<27>[0mReceived packet, command: 178<\r><\n>
:69: Received subscription response<\r><\n>
<27>[0m[00:00:53.503] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:252: Executing Mercury Request, type SEND<\r><\n>
[00:00:53.540] cspot_cmd_handler:429 CSpot volume 44031<\r><\n>
<27>[0m[00:00:53.543] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:174: Received mercury packet<\r><\n>
<27>[0m[00:00:53.722] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 178<\r><\n>
<27>[0m[<27>[0m[00:00:53.725] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 181<\r><\n>
00:00:53.724] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:174: Received mercury packet<\r><\n>
<27>[0m[00:00:53.746] <27>[0;31mD <27>[0;94mSpircHandler.cpp<27>[0m:69: Received subscription response<\r><\n>
<27>[0m[00:00:53.754] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:252: Executing Mercury Request, type SEND<\r><\n>
[00:00:53.784] cspot_cmd_handler:429 CSpot volume 52223<\r><\n>
<27>[0m[00:00:53.972] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 178<\r><\n>
<27>[0m[00:00:53.975] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:174: Received mercury packet<\r><\n>
<27>[0m[00:00:54.258] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 178<\r><\n>
<27>[0m[00:00:54.<27>[0m261] [<27>[0;31mD 00:<27>[0;37mMercurySession.cpp<27>[0m00:174: :Received mercury packet54<\r><\n>
.262] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 181<\r><\n>
<27>[0m[00:00:54.280] <27>[0;31mD <27>[0;94mSpircHandler.cpp<27>[0m:69: Received subscription response<\r><\n>
<27>[0m[00:00:54.288] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:252: Executing Mercury Request, type SEND<\r><\n>
[00:00:54.325] cspot_cmd_handler:429 CSpot volume 60415<\r><\n>
<27>[0m[00:00:54.563] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 178<\r><\n>
<27>[0m[00:00:54.565] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:174: Received mercury packet<\r><\n>
<27>[0m[00:00:54.980] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 181<\r><\n>
<27>[0m[00:00:54.984] <27>[0;31mD <27>[0;94mSpircHandler.cpp<27>[0m:69: Received subscription response<\r><\n>
<27>[0m[00:00:55.018] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:252: Executing Mercury Request, type SEND<\r><\n>
[00:00:55.046] cspot_cmd_handler:429 CSpot volume 63487<\r><\n>
<27>[0m[00:00:55.271] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 178<\r><\n>
<27>[0m[00:00:55.274] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:174: Received mercury packet<\r><\n>
<27>[0m[00:02:32.187] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 4<\r><\n>
<27>[0m[00:02:32.190] <27>[0;31mD <27>[0;91mTimeProvider.cpp<27>[0m:15: Time synced with spotify servers<\r><\n>
<27>[0m[00:02:32.428] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 74<\r><\n>
<27>[0m[00:03:03.379] <27>[0;34mI <27>[0;90mTrackPlayer.cpp<27>[0m:224: <27>[0mEOF<\r><\n>
<27>[0m[00:03:03.385] <27>[0;34mI <27>[0;90mTrackPlayer.cpp<27>[0m:255: <27>[0mPlaying done<\r><\n>
<27>[0m[00:03:03.439] <27>[0;34mI <27>[0;90mTrackPlayer.cpp<27>[0m:171: <27>[0mGot track ID=c72bd38496b53c55cac7f2c88b57d47149c40a4d<\r><\n>
<27>[0m[00:03:03.443] <27>[0;34mI <27>[0;90mCDNAudioFile.cpp<27>[0m:43: <27>[0mOpening HTTP stream to https://audio-ak-spotify-com.akamaized.net/audio/c72bd38496b53c55cac7f2c88b57d47149c40a4d?__token__=exp=1701579612~hmac=3989bdbd11a4086d9f47a47e5471c8cdb155ed4fb69e7b6efd36f42a583d4dc9<\r><\n>
<27>[0m[00:03:05.822] <27>[0;34mI <27>[0;90mCDNAudioFile.cpp<27>[0m:70: <27>[0mHeader and footer bytes received<\r><\n>
<27>[0m[00:03:06.186] <27>[0;34mI <27>[0;90mTrackPlayer.cpp<27>[0m:206: <27>[0mPlaying<\r><\n>
<27>[0m[00:03:06.232] <27>[0;34mI <27>[0;95mShim.cpp<27>[0m:120: <27>[0mnew track started  => <\r><\n>
<27>[0m[00:03:06.245] <27>[0;34mI <27>[0;95mShim.cpp<27>[0m:262: <27>[0mnext track will play in 8695 ms<\r><\n>
[00:03:14.975] _output_frames:150 track start sample rate: 44100 replay_gain: 0<\r><\n>
<27>[0m[00:03:15.000] <27>[0;34mI <27>[0;95mShim.cpp<27>[0m:416: <27>[0mnext track's audio has reached DAC (offset 0)<\r><\n>
<27>[0m[00:03:15.016] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:252: Executing Mercury Request, type SEND<\r><\n>
<27>[0m[00:03:15.068] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:252: Executing Mercury Request, type SEND<\r><\n>
<27>[0m[00:03:15.081] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:252: Executing Mercury Request, type GET<\r><\n>
<27>[0m[00:03:15.284] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 178<\r><\n>
<27>[0m[00:03:15.288] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:174: Received mercury packet<\r><\n>
<27>[0m[00:03:15.525] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 178<\r><\n>
<27>[0m[00:03:15.528] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:174: Received mercury packet<\r><\n>
<27>[0m[00:03:15.542] <27>[0;34mI <27>[0;32mTrackQueue.cpp<27>[0m:158: <27>[0mTrack name: Waves & Wavs<\r><\n>
<27>[0m[00:03:15.545] <27>[0;34mI <27>[0;32mTrackQueue.cpp<27>[0m:159: <27>[0mTrack duration: 328000<\r><\n>
<27>[0m[00:03:15.557] <27>[0;31mD <27>[0;32mTrackQueue.cpp<27>[0m:162: trackInfo.restriction.size() = 1<\r><\n>
<27>[0m[00:03:15.560] <27>[0;31mD <27>[0;32mTrackQueue.cpp<27>[0m:212: File format: 2<\r><\n>
<27>[0m[00:03:15.706] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 178<\r><\n>
<27>[0m[00:03:15.708] <27>[0;31mD <27>[0;37mMercurySession.cpp<27>[0m:174: Received mercury packet<\r><\n>
<27>[0m[00:03:15.998] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 13<\r><\n>
<27>[0m[00:03:16.000] <27>[0;34mI <27>[0;32mTrackQueue.cpp<27>[0m:252: <27>[0mGot audio key<\r><\n>
<27>[0m[00:03:16.013] <27>[0;34mI <27>[0;32mTrackQueue.cpp<27>[0m:275: <27>[0mReceived access key, fetching CDN URL...<\r><\n>
<27>[0m[00:03:19.300] <27>[0;34mI <27>[0;32mTrackQueue.cpp<27>[0m:301: <27>[0mReceived CDN URL, https://audio-ak-spotify-com.akamaized.net/audio/62d1c36060aa2cf23d9284a1e37c2709455781e8?__token__=exp=1701579774~hmac=6a21e41f8807f7c3a5ff39965f2a8059d7358fd7f085fb626354a8ffc1525b7c<\r><\n>
<27>[0m[00:04:32.126] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 4<\r><\n>
<27>[0m[00:04:32.128] <27>[0;31mD <27>[0;91mTimeProvider.cpp<27>[0m:15: Time synced with spotify servers<\r><\n>
<27>[0m[00:04:32.373] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 74<\r><\n>
<27>[0;32mI (313048) httpd_handlers: serving / to peer 192.168.111.101 port 58600<27>[0m<\r><\n>
<27>[0;32mI (313518) httpd_handlers: serving /commands.json to peer 192.168.111.101 port 59624<27>[0m<\r><\n>
<27>[0;32mI (313718) httpd_handlers: serving /messages.json to peer 192.168.111.101 port 63720<27>[0m<\r><\n>
<27>[0;32mI (314978) network_wifi: Initiating wifi network scan<27>[0m<\r><\n>
<27>[0;32mI (316758) httpd_handlers: serving /messages.json to peer 192.168.111.101 port 1257<27>[0m<\r><\n>
<27>[0m[00:06:32.139] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 4<\r><\n>
<27>[0m[00:06:32.141] <27>[0;31mD <27>[0;91mTimeProvider.cpp<27>[0m:15: Time synced with spotify servers<\r><\n>
<27>[0m[00:06:32.385] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 74<\r><\n>
`

nvs config

`{
  "a2dp_ctmt": "1000",
  "a2dp_ctrld": "500",
  "a2dp_dev_name": "Juice",
  "a2dp_sink_name": "SMSL BT4.2",
  "a2dp_spin": "0000",
  "actrls_config": "",
  "airplay_name": "Juice",
  "airplay_port": "5000",
  "ap_channel": "1",
  "ap_ip_address": "192.168.4.1",
  "ap_ip_gateway": "192.168.4.1",
  "ap_ip_netmask": "255.255.255.0",
  "ap_pwd": "squeezelite",
  "ap_ssid": "Juice",
  "autoexec": "1",
  "autoexec1": "squeezelite  -o i2s  -s  -disable -b  500:2000 -C  30 -d  all=info ",
  "bat_config": "",
  "bt_name": "Juice",
  "bt_sink_pin": "1234",
  "bt_sink_volume": "127",
  "bypass_wm": "0",
  "cspot_config": "{\"deviceName\":\"Juice\",\"bitrate\":320,\"zeroConf\":1}",
  "dac_config": "model=I2S,bck=5,ws=25,do=26,mck=0,mute=4:1",
  "dac_controlset": "",
  "dhcp_tmout": "8",
  "display_config": "",
  "enable_airplay": "1",
  "enable_bt_sink": "1",
  "enable_cspot": "1",
  "equalizer": "",
  "eth_config": "",
  "ethtmout": "8",
  "gpio_exp_config": "",
  "host_name": "Juice",
  "i2c_config": "",
  "jack_mutes_amp": "n",
  "led_brightness": "",
  "led_vu_config": "",
  "lms_ctrls_raw": "n",
  "loudness": "0",
  "metadata_config": "",
  "model_config": "",
  "ota_erase_blk": "249856",
  "ota_prio": "6",
  "ota_stack": "10240",
  "pollmin": "15",
  "pollmx": "600",
  "rel_api": "https://api.github.com/repos/sle118/squeezelite-esp32/releases",
  "release_url": "CONFIG_SQUEEZELITE_ESP32_RELEASE_URL",
  "rotary_config": "",
  "set_GPIO": "",
  "sleep_config": "",
  "spdif_config": "",
  "spi_config": "",
  "stats": "n",
  "target": "",
  "telnet_block": "500",
  "telnet_buffer": "40000",
  "telnet_enable": ""
}
`

currently running : 2.1652-16#v4.3#I2S-4MFlash#master-v4.3 on ESP32-CAM with 16Mflash & 8M PSRAM , PCM5102A DAC with MCLK (mck=0) in nvs

after a few day , i observe that audio breaks up and sometimes totally stopped , it can happen immediately or in between 3 - 5 hours of non-stop spotify playlists.

[rickyfajar93]

Update : after leaving it on for a while without playing anything , it keeps receiving `<27>[0m[01:36:32.588] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 4<\r><\n>

<27>[0m[01:36:32.590] <27>[0;31mD <27>[0;91mTimeProvider.cpp<27>[0m:15: Time synced with spotify servers<\r><\n> <27>[0m[01:36:32.834] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 74<\r><\n> <27>[0m[01:38:32.601] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 4<\r><\n> <27>[0m[01:38:32.603] <27>[0;31mD <27>[0;91mTimeProvider.cpp<27>[0m:15: Time synced with spotify servers<\r><\n> <27>[0m[01:38:32.847] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 74<\r><\n> <27>[0m[01:40:32.615] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 4<\r><\n> <27>[0m[01:40:32.617] <27>[0;31mD <27>[0;91mTimeProvider.cpp<27>[0m:15: Time synced with spotify servers<\r><\n> <27>[0m[01:40:32.902] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:42: <27>[0mReceived packet, command: 74<\r><\n> ` edit : suspiciusly , this packet command 4 and 74 also shows up when the audio breaks (i think it's like buffering)

[rickyfajar93]

after investigating the uart further I think i found the problem

`<27>[0m[02:00:23.088] <27>[0;31mD <27>[0;94mSession.cpp<27>[0m:67: Connecting with AP <\r><\n>

<27>[0m[02:00:23.330] <27>[0;31mD <27>[0;35mPlainConnection.cpp<27>[0m:101: Connected to spotify server<\r><\n> <27>[0m[02:00:23.576] <27>[0;34mI <27>[0;94mSession.cpp<27>[0m:43: <27>[0mReceived APHello response<\r><\n> <27>[0m[02:00:23.609] <27>[0;31mD <27>[0;94mSession.cpp<27>[0m:48: Received shannon keys<\r><\n> <27>[0m[02:00:23.840] <27>[0;31mD <27>[0;94mSession.cpp<27>[0m:87: Authorization successful<\r><\n> <27>[0m[02:00:23.843] <27>[0;34mI <27>[0;37mMercurySession.cpp<27>[0m:75: <27>[0mReconnection successful<\r><\n> ` there's a problem with ap-gew4 that happened before , and i think it might happen again this time [https://community.spotify.com/t5/App-Features/ap-gew4-spotify-com-not-functioning/td-p/5408508](url) [https://community.spotify.com/t5/Other-Podcasts-Partners-etc/No-music-when-using-Spotty-in-Denmark/td-p/5349988](url) are there any implementable workaround to blacklist certain ap-gew4 url or redirect it from the web interface? or perhaps this is implementable? > There are a few workarounds, trying to find the posts but can't right now The solution is to manually assign an ip address to aap-gew4.spotify.com but I cannot find the address Edit, it's 104.199.65.124 , hopefully your router allows manual assignment i found it here : [https://community.spotify.com/t5/App-Features/ap-gew4-spotify-com-not-functioning/td-p/5408508](url)

[sle118]

This would be something in the realm of @feelfreelinux as this is cspot related.

[feelfreelinux]

Hi! Thanks for the thourough investigation. CSpot supports overriding an AP address, but I am not sure if its exposed in squeezelite's interface. A nicer option would be to detect broken APs, but I don't think there's an easy way to detect when Spotify's ap is broken - asides from recreating the entire connection, when we suspect that some playback failure was caused by ap

[bungh0l10]

Hi,sorry for interrupting. Would it be an option (instead of manual override) to primarily use the fallback ap from http://apresolve.spotify.com/? instead of ap-gew4 or have the possibility on user side to do so?

cheers

[rickyfajar93]

Hi! Thanks for the thourough investigation. CSpot supports overriding an AP address, but I am not sure if its exposed in squeezelite's interface. A nicer option would be to detect broken APs, but I don't think there's an easy way to detect when Spotify's ap is broken - asides from recreating the entire connection, when we suspect that some playback failure was caused by ap

Oh , i see , that is what the override AP option in euphonium is used for 😂

Thank You for the information , i'm having a headache trying to figure out what is happening with spotify playback with euphonium , and the same problem happens to squeezelite too.

[sle118]

Same problem because cspot runs on both 🙂

I am not sure if our shim exposes this option. @philippe44 would know as he integrated cspot

[rickyfajar93]

Same problem because cspot runs on both 🙂

I am not sure if our shim exposes this option. @philippe44 would know as he integrated cspot

I know , I'm just trying to 'sanity check' myself 😂 because i'm still having a few problems with euphonium.

[feelfreelinux]

Hi,sorry for interrupting. Would it be an option (instead of manual override) to primarily use the fallback ap from http://apresolve.spotify.com/? instead of ap-gew4 or have the possibility on user side to do so?

cheers

Initially, I was kind of against blacklisting aps, as the situation with which currently works seems to change over time, and is also very dependent on the region. However, from what I see mostly ap-gew4 seems problematic, so maybe it is not as bad of a solution :) I think @rickyfajar93 had success with AP override in euphonium, but it's not exactly a very clear fix

[rickyfajar93]

Hi,sorry for interrupting. Would it be an option (instead of manual override) to primarily use the fallback ap from http://apresolve.spotify.com/? instead of ap-gew4 or have the possibility on user side to do so?

cheers

Initially, I was kind of against blacklisting aps, as the situation with which currently works seems to change over time, and is also very dependent on the region. However, from what I see mostly ap-gew4 seems problematic, so maybe it is not as bad of a solution :) I think @rickyfajar93 had success with AP override in euphonium, but it's not exactly a very clear fix

After doing the override , it seems that occasionally after a few reboots , it comes back to ap-gew4 And there are times when the problem gets worse (1 song and then audio breaks up at the end and totally stops)

Since cspot gets the ap- list from ap resolve , is it possible to implement a drop down list where the user can select the ap- they prefer?

[philippe44]

Hi! Thanks for the thourough investigation. CSpot supports overriding an AP address, but I am not sure if its exposed in squeezelite's interface. A nicer option would be to detect broken APs, but I don't think there's an easy way to detect when Spotify's ap is broken - asides from recreating the entire connection, when we suspect that some playback failure was caused by ap

Couldn't we have a fault rating for the current AP and when a track fails we increase that rate so that we use that ap with a lower priority. In other words, we select from ap-list the ap's that we don't know yet or that don't have a high fault rating (or do round-robin on the ones with same rate, IDK the exact mechanism of ap-list, I would have to look at the code again, I kind of forgot that part). The fault rating may have a "forgiveness factor" with time. The rating can also be exponential so that bad actors really get punished and spend more time in the penalty box 😄

[rickyfajar93]

UPDATE : i found [https://apresolve.spotify.com/?type=dealer&type=spclient]()

Can this be used as an alternative? @sle118 @feelfreelinux @philippe44

Edit : Another interesting case [https://community.spotify.com/t5/Other-Podcasts-Partners-etc/Problem-with-spotify-web-connection/td-p/1539824]()

UPDATE2 : i use spotify connect with my phone and the problem continues , but when i move to PC and use the web browser it only occasionally stutters & breaks. The weird thing is i see abnormal traffic on my network (continuous 2-3Mbps just opening spotify in firefox with cspot still connected & playing(still on ap-gew4 which i cannot totally override now)) , and after several songs (mostly 5-6 song) spotify connect always stops and disconnected.

I'll investigate the traffic between cspot and spotify as soon as possible and update here.

[rickyfajar93]

after doing observation for 6 hours (yesterday) + 4 hours this morning between Cspot & Spotify with the following setup: my laptop (for wireshark) , 1st phone (for spotify connect) , Cspot (UART monitor with idf.py monitor) , connected to my other phone as an access point (2nd phone)

Stutter still happens around 3+ hours

from the wireshark side , there's nothing to indicate that there's problem between the phone and cspot

from the idf.py monitor side (captured when it stutter the worst) : D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2717700, (internal) 20979 D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2719224, (internal) 21215 D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2704544, (internal) 21215 D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2717700, (internal) 20983 D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2717700, (internal) 21087 D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2715996, (internal) 21095 D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2717700, (internal) 21071 D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2704544, (internal) 21199 D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2704544, (internal) 21207 I [cspot] MercurySession.cpp:42: Received packet, command: 4 D [cspot] TimeProvider.cpp:15: Time synced with spotify servers I [cspot] MercurySession.cpp:42: Received packet, command: 74 D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2704544, (internal) 21203 I [cspot] TrackPlayer.cpp:218: EOF I [cspot] TrackPlayer.cpp:249: Playing done I [cspot] TrackPlayer.cpp:167: Got track ID=65b2fa55344243adc39a813eef1a656fed56e52a I [cspot] CDNAudioFile.cpp:43: Opening HTTP stream to https://audio-ak-spotify-com.akamaized.net/audio/65b2fa55344243adc39a813eef1a656fed56e52a?__token__=exp=1702005868~hmac=xxxxxxxxxxxxxxxxxxxxxxxxfxxxxxxxxxxxxfbedf5f0c52cac7066fa15 D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2760604, (internal) 25295 I [cspot] CDNAudioFile.cpp:70: Header and footer bytes received I [cspot] TrackPlayer.cpp:200: Playing D [core] Core.cpp:174: EventBus message received D [cspot] MercurySession.cpp:251: Executing Mercury Request, type SEND D [core] Core.cpp:174: EventBus message received D [cspot] MercurySession.cpp:251: Executing Mercury Request, type GET I [cspot] MercurySession.cpp:42: Received packet, command: 178 D [cspot] MercurySession.cpp:174: Received mercury packet I [cspot] TrackQueue.cpp:158: Track name: Faith I [cspot] TrackQueue.cpp:159: Track duration: 146480 D [cspot] TrackQueue.cpp:161: trackInfo.restriction.size() = 1 D [cspot] TrackQueue.cpp:212: File format: 2 D [cspot] TrackQueue.cpp:212: File format: 1 I [cspot] MercurySession.cpp:42: Received packet, command: 178 D [cspot] MercurySession.cpp:174: Received mercury packet I [cspot] MercurySession.cpp:42: Received packet, command: 13 I [cspot] TrackQueue.cpp:252: Got audio key I [cspot] TrackQueue.cpp:275: Received access key, fetching CDN URL... I [cspot] TrackQueue.cpp:301: Received CDN URL, https://audio-ak-spotify-com.akamaized.net/audio/975ed9ce439c3cfa45bf6d4b1330e1f446a865d9?__token__=exp=1702006557~hmac=xxxxxxxxxxxxxxxxxxxxxxxx7688bf1573c3f512884e297c55b D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2709508, (internal) 21095 D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2709508, (internal) 21091

STUTTER STARTS HERE

D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2694828, (internal) 21191 D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2694828, (internal) 21199 D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2707980, (internal) 21103 D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2707980, (internal) 21091

WORST STUTTER STARTS HERE

D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2707980, (internal) 21099 D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2707980, (internal) 21099 D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2694828, (internal) 21199 D [core] MemoryMonitorTask.cpp:43: Free memory: (psram) 2707980, (internal) 20967

this network activity is also captured when it stutter the worst:

[philippe44]

Not that it is the issue, but you are crazy low on internal ram... 32 bits version and spdif?

[philippe44]

Does it happen if you use cspot natively on any platform?

[rickyfajar93]

Does it happen if you use cspot natively on any platform?

I tried on squeezelite & euphonium (dev branch) and got the same result

But i haven't tried the cli version

[rickyfajar93]

Not that it is the issue, but you are crazy low on internal ram... 32 bits version and spdif?

Pardon me , unfortunately for this data i used euphonium (because of the AP redirection), but i got the same behaviour when using squeezelite

I'll do another capture & monitor session with squeezelite if needed.

[philippe44]

Does it happen if you use cspot natively on any platform?

I tried on squeezelite & euphonium (dev branch) and got the same result

But i haven't tried the cli version

No I mean capot on windows or Linux, the cli version

[rickyfajar93]

Does it happen if you use cspot natively on any platform?

I tried on squeezelite & euphonium (dev branch) and got the same result

But i haven't tried the cli version

No I mean capot on windows or Linux, the cli version

No , i haven't tried the cli version (either in windows / linux)

[philippe44]

Does it happen if you use cspot natively on any platform?

I tried on squeezelite & euphonium (dev branch) and got the same result

But i haven't tried the cli version

No I mean capot on windows or Linux, the cli version

No , i haven't tried the cli version (either in windows / linux)

• [ ] I think that it would tell us a lot about the cause of stuttering. In addition, investigating on these platforms is much easier.

[rickyfajar93]

Does it happen if you use cspot natively on any platform?

I tried on squeezelite & euphonium (dev branch) and got the same result But i haven't tried the cli version

No I mean capot on windows or Linux, the cli version

No , i haven't tried the cli version (either in windows / linux)

• [ ] I think that it would tell us a lot about the cause of stuttering. In addition, investigating on these platforms is much easier.

After doing more experiments starting from the weekend until today , i found that :

1. i'm still having some issues with euphonium (likely because i used version 1 of esp32)

2. observing apresolve.spotify.com , i found out that each time i refresh , the 4th data and the rest always changes so i decided to build squeezelite and change ApResolve.cpp:35 to -> cJSON_GetArrayItem(cJSON_GetObjectItem(json, "ap_list"), 3)->valuestring); //originally 0 with this modification i can compare different ap with just a reboot. And after spending the whole weekend , doing comparison & stream test that ap-gew4 have some occasional stuttering every 2-3 hours during the day while others don't. another thing that i found out is when i let it stream overnight, ap-gew4 would stop playing in the morning when i wake up , but other ap's don't (needs more data) since i only observe it for 1 night and change to other ap's

could i suggest ApResolve.cpp:35 to -> cJSON_GetArrayItem(cJSON_GetObjectItem(json, "ap_list"), 3)->valuestring); so it "randomize" the AP used by cspot?

with this observation i think it temporarily solve the problem.

[philippe44]

I understand where you want to go, but how is that randomizing? If this is an array of ap's, then we should really randomizingthe index we use.

[rickyfajar93]

I understand where you want to go, but how is that randomizing? If this is an array of ap's, then we should really randomizingthe index we use.

I think i should say , it's been randomized by spotify (the fourth data in the array) so we should just use it.

[philippe44]

understood - is this documented (kind of) or just an observation?

[rickyfajar93]

understood - is this documented (kind of) or just an observation?

I haven't checked the documentation thoroughly but from what i read a few months ago in the spotify developer forum , the reason apresolve has 6 or sometimes more aplist is when 1 or more ap is unavailable , the system using it can fallback to the next index.

I don't know yet the reason behind the fourth data being rolled / randomized.

So, Currently , it's just a observation.

[bungh0l10]

Maybe @mherger could chime in, as he is aware of the gew4 flaws from back in the days and could share insightful opinions/thoughts based on his LMS integration as it might be beneficial to others.

[mherger]

My spotty/librespot implementation isn't trying to be smart about this. It's simply ignoring "ap-gew4.spotify.com" and "ap-gue1.spotify.com"... I'm way behind current librespot development, though. It looks as if they had changed (removed) that simplistic workaround.