Spotify (cspot) crash when trying to play

[aprosvetova]

Hey all.

I built a basic squeezelite instance on TTGO T7 (ESP32-WROVER) + PCM5102: (clickable)

It works great, and the sound quality is fine. Bluetooth and AirPlay sources work without any trouble. However, the board crashes and reboots when I try to play music over Spotify Connect (it is discoverable).

I flashed the board with the web installer. Some version info that might be useful:

App version:      I2S-4MFlash.16.2.1306.master-v4
Compile time:     May 12 2023 19:24:21
ELF file SHA256:  40f7c3160c93b168...
ESP-IDF:          v4.3.2-dirty

Click to see the crash log

``` I Shim.cpp:315: Spotify client connected for Flamingo D Session.cpp:63: Connecting with AP D PlainConnection.cpp:101: Connected to spotify server I Session.cpp:39: Received APHello response D Session.cpp:44: Received shannon keys D Session.cpp:82: Authorization successful [00:11:50.997] cspot_cmd_handler:408 CSpot volume 0 I MercurySession.cpp:42: Received packet, command: 4 D TimeProvider.cpp:15: Time synced with spotify servers I MercurySession.cpp:42: Received packet, command: 2 D I MercurySession.cppMercurySession.cpp:42: :252: Received packet, command: 118Executing Mercury Request, type SUB I MercurySession.cpp:42: Received packet, command: 27 D MercurySession.cpp:153: Received country code NL I MercurySession.cpp:42: Received packet, command: 80 I MercurySession.cpp:42: Received packet, command: 31 I MercurySession.cpp:42: Received packet, command: 105 I MercurySession.cpp:42: Received packet, command: 181 I MercurySession.cpp:42: Received packet, command: 74 I MercurySession.cpp:42: Received packet, command: 179 D MercurySession.cpp:174: Received mercury packet I AccessKeyFetcher.cpp:68: Access token expired, fetching new one... D D MercurySession.cppMercurySession.cpp:252: Executing Mercury Request, type SEND:252: Executing Mercury Request, type GET D SpircHandler.cpp:59: Sent kMessageTypeHello! I MercurySession.cpp:42: Received packet, command: 178 D MercurySession.cpp:174: Received mercury packet Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled. Core 0 register dump: PC : 0x4015c556 PS : 0x00060f30 A0 : 0x8015162a A1 : 0x3fada4b0 A2 : 0x3fadaa50 A3 : 0x3fade158 A4 : 0x3faddfcc A5 : 0x00000000 A6 : 0x00000000 A7 : 0x3fadaa50 A8 : 0x8015c556 A9 : 0x3fada490 A10 : 0x00000000 A11 : 0x3f4493a8 A12 : 0x3facc2bf A13 : 0x00000000 A14 : 0xffffffff A15 : 0x3fada4d0 SAR : 0x00000019 EXCCAUSE: 0x0000001c EXCVADDR: 0x00000010 LBEG : 0x40093872 LEND : 0x4009387d LCOUNT : 0x00000000 Backtrace:0x4015c553:0x3fada4b0 0x40151627:0x3fada4f0 0x401533e2:0x3fada510 0x40106f38:0x3fada6d0 0x401053ba:0x3fada830 ```

Click to see my NVS dump

``` a2dp_ctmt: '1000' a2dp_ctrld: '500' a2dp_dev_name: Flamingo a2dp_sink_name: Echo-12X a2dp_spin: '0000' actrls_config: '' airplay_name: Flamingo 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: "[REDACTED]" ap_ssid: Flamingo autoexec: '1' autoexec1: 'squeezelite -o i2s -b 500:2000 -C 30 -d all=info ' bat_config: '' bt_name: Flamingo bt_sink_pin: '1234' bt_sink_volume: '127' bypass_wm: '0' cspot_config: '{"deviceName":"Flamingo","bitrate":160}' dac_config: model=I2S,bck=21,ws=27,do=22 dac_controlset: '' dhcp_tmout: '8' display_config: '' enable_airplay: Y enable_bt_sink: Y enable_cspot: Y equalizer: '0,0,0,0,0,0,0,0,0,0' eth_config: '' ethtmout: '8' gpio_exp_config: '' host_name: Flamingo i2c_config: '' jack_mutes_amp: n led_brightness: '' lms_ctrls_raw: n 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: https://github.com/sle118/squeezelite-esp32/releases rotary_config: '' set_GPIO: '' spdif_config: '' spi_config: '' stats: N target: '' telnet_block: '500' telnet_buffer: '40000' telnet_enable: D ```

Please let me know if I can provide you with anything else that could help.

[sle118]

couple of questions:

• Are you a Spotify paid subscriber? this is a prerequesite
• Does the crash happen on any track?
• Can you play at least one track, or none?
• If this happens on a specific track, please provide an example
• Are you using logitech media server? if so, I would recommend using it to play spotify track for now I'll assign the issue to @philippe44, who integrated cspot into our project, but I am not sure if he is available these days to work on our project.

[aprosvetova]

Thanks for your attention.

• Yep, I have Spotify Premium subscription. I have tried different accounts (all paid too).
• Yes, any track crashes the board
• I found something new during testing, see the explanation below. Basically, I was able to make it work partially
• I am thinking of setting up LMS, but this speaker is going to be a gift, and I want it to be as autonomous as possible

I have some more updates. I decoded the crash backtrace:

stack:
0:
  0x40152e57: std::function<void (cspot::MercurySession::Response&)>::operator()(cspot::MercurySession::Response&) const at xtensa-esp32-elf/include/c++/8.4.0/bits/std_function.h:687
0:
  0x40154c12: cspot::MercurySession::handlePacket() at /workspace/squeezelite-esp32/build/../components/spotify/cspot/src/MercurySession.cpp:179
0:
  0x401073a8: cspotPlayer::runTask() at /workspace/squeezelite-esp32/build/../components/spotify/Shim.cpp:351
0:
  0x4010582a: bell::Task::taskEntryFuncPSRAM(void*) at /workspace/squeezelite-esp32/build/../components/spotify/cspot/bell/main/utilities/include/BellTask.h:95

I also managed to make it work! It turns out that if I start the session from my phone (iOS), all is fine. If I start from the macOS Spotify client, it crashes. If I start from the Windows Spotify client, it works. If I start from another Windows machine (and another Spotify account), it crashes.

My iOS, macOS, and Windows Spotify clients have the same settings (crossfade, automix, streaming quality, etc). I don't know if those settings even affect Spotify Connect sessions.

It is perfectly reproducible with any track. As in, if it works on some device, a session can always be started from this device successfully.

I've also noticed that shuffle & repeat buttons don't work, but that seems to be a separate issue.

[aprosvetova]

Did some more tests after downgrading from 2.1306-16 to 2.1299-16. Initiating a Spotify Connect session from macOS still crashes the board. iOS still works. Shuffle and repeat buttons suddenly work!

But... Overall stability is worse, and the board randomly crashes, for example, when I try to skip tracks really fast. Going back to the most recent version for now.

[sle118]

@philippe44 has tried keeping up to speed with the upstream cspot repo, but it has been a moving target that sometimes required quite substantial refactoring of his shim. The environment (esp-idf) itself is full of potential race conditions from sockets amongst others so each iteration needs lots of tweaking.

If you are looking for a pure Spotify speaker, then you might consider installing @feelfreelinux's own Spotify centric player firmware. Or project was initially targeted mostly as a replacement to Logitech hardware with a goal of doing seamless multi room audio, so Spotify support came as an afterthought and wasn't there from the ground up.

Cspot has other challenges too around the spdif bitbanging we do, skipping at regular intervals, but this isn't an issue for your own requirement.

[philippe44]

But having said that you are the only one to report issues with this new version. I did not experience any crash personally (windows and iOS)

[aprosvetova]

Thanks, I'll try cspot out directly. Honestly, it would be perfect for this specific speaker to have AirPlay + Bluetooth + autonomous Spotify, but just Spotify would be ok for now.

Thank you and @philippe44 so much for the insane amount of effort you put into building such a massive project for such a small device. Very impressive.

[sle118]

Thank you and @philippe44 so much for the insane amount of effort you put into building such a massive project for such a small device. Very impressive.

This is the perfect example of scope creep 😉

[feelfreelinux]

Hi, thanks for reporting this! The issue is caused by recent changes in MacOS client - the authorization logic has changed a little bit. Currently it should only affect the MacOS client, and I'll try to port the code to the newer logic some time soon.

I'm also developing a firmware thats more centered around just cspot, bluetooth and other standalone services - let me know if you'd like to give it a try, although the MacOS authorization issue also exists there.

[aprosvetova]

@feelfreelinux Thanks for looking into that, I'm happy you determined the cause. It's weird, though, but another person managed to reproduce this with the Windows Spotify client. I will give it another try.

And yes, I would really love to try the firmware you mentioned! Please share the link :) I was only able to find the cspot repo in your profile.

[philippe44]

@feelfreelinux makes sense - I'm almost up to date with cspot/bell so I should be able to quickly use any update you'll make. It's a major work as you know to always follow and have a single set of sources, including makefiles but I hope it will bear some fruits

[philippe44]

Should be done now. @aprosvetova, can you confirm?

BTW, I just saw that @feelfreelinux has updated the AAC decoder, so it's a change that I'm unlikely to be able to follow hence it might be the last CSpot supported version of squeezelite-esp32

[feelfreelinux]

Should be done now. @aprosvetova, can you confirm?

BTW, I just saw that @feelfreelinux has updated the AAC decoder, so it's a change that I'm unlikely to be able to follow hence it might be the last CSpot supported version of squeezelite-esp32

The AAC decoder is not used by CSpot, so i compiling bell with BELL_CODEC_AAC=OFF should do the job. Libhelix lacked support for HEv2 with parametric stereo, hence the change to opencore decoder.

[aprosvetova]

Thanks, @feelfreelinux and @philippe44, for the fixes, I can initiate a session from any device! It works fine.

However, the repeat and shuffle buttons are still broken, and adding songs to the queue breaks everything. Should I file detailed issues here or in the cspot repo? Should I file repeat+shuffle and queue issues separately?

[feelfreelinux]

Thanks, @feelfreelinux and @philippe44, for the fixes, I can initiate a session from any device! It works fine.

However, the repeat and shuffle buttons are still broken, and adding songs to the queue breaks everything. Should I file detailed issues here or in the cspot repo? Should I file repeat+shuffle and queue issues separately?

Feel free to report in cspot repo :) If you prefer, you can also contact me on telegram with some feedback, I'd really appreciate it.

[philippe44]

The AAC decoder is not used by CSpot, so i compiling bell with BELL_CODEC_AAC=OFF should do the job. Libhelix lacked support for HEv2 with parametric stereo, hence the change to opencore decoder.

Yes of course you’re right. I just integrated the updated Bell, all good now but I’ve made a small PR as it seems that we have a catch 22 regarding idf 4 and 5.

BTW, what were the reasons behind moving to opencore-aac?

[feelfreelinux]

The AAC decoder is not used by CSpot, so i compiling bell with BELL_CODEC_AAC=OFF should do the job. Libhelix lacked support for HEv2 with parametric stereo, hence the change to opencore decoder.

Yes of course you’re right. I just integrated the updated Bell, all good now but I’ve made a small PR as it seems that we have a catch 22 regarding idf 4 and 5.

BTW, what were the reasons behind moving to opencore-aac?

Thanks! I'll try to make sure we don't divert too far from supporting idf 4 in bell.

I moved from libhelix, as I realised that it does not support HEv2 parametric stereo mode. A lot of webradios seem to make use of it, and while libhelix could decode it, it would not be able to reconstruct both channels, only providing me with a mono stream. For example, radio http://193.222.135.71/378 has this issue.