Randomly stops playing on Mac

[marijnbent]

Fastpotify version and how you installed it

Latest

Operating system

macOS

System details

latest

Spotify plan

Premium

What did you do, and what happened instead?

I went through the logs but didn't see anything, but it still randomly stops playing sometimes.

fastpotify.log

.

[crmne]

Need the logs to act on it.

[marijnbent]

I understand there's a most awful bug report, just maybe here to see if other people are experiencing it as well. Codex went through my logs and said there's nothing relevant in it.

[crmne]

You are not alone: I see it on Linux too, and I have not caught it in a log yet either, which is why 0.2.0 (out today) writes one by itself. When it next stops, before doing anything else, copy ~/Library/Application Support/me.paolino.fastpotify/fastpotify.log and paste the last 50 lines here. Two details help as much as the log: was the music playing on the Mac itself or on another device, and does it stop mid-song or between songs? If you can run it from Terminal as /Applications/Fastpotify.app/Contents/MacOS/fastpotify -v, the log says a lot more.

[marijnbent]

It was mid-song, and it was on the Mac itself.I'll update to the next version and then let you know when I see it again.

[crmne]

mise ~/.config/mise/config.toml tools: gh@2.98.0
mise ~/.config/mise/config.toml tools: gh@2.98.0
Thanks, mid-song on the Mac itself narrows it. That points at the local audio stream dropping rather than a Connect handover. 0.2.0 changed the audio sink and added reconnect logging, so the new log will say whether librespot's session ended or the audio device stalled. When it next stops on 0.2.0, paste the last 30 lines of ~/Library/Application Support/me.paolino.fastpotify/fastpotify.log. I will hold this open for that.

Update: the chain in the log @conscientiousness posted is librespot's session drop, tracked upstream in librespot-org/librespot#1419 with a fix waiting for review in librespot-org/librespot#1692. What Fastpotify can do on its side is on main now: after the reconnect it loads the same song at the position it was interrupted at, playing or paused as it was, so a drop turns into a pause of a few seconds instead of silence. The seconds before the drop is noticed are still librespot's to fix.

0.4.0-rc1 is out with the resume: https://github.com/crmne/fastpotify/releases/tag/v0.4.0-rc1. It covers the second case @conscientiousness caught: after the reconnect the engine loads the same song at the position it was at, so the device comes back playing instead of stopped. @bakzkndd, the same on Windows, please try the candidate.

[conscientiousness]

Reproduced on Fastpotify 0.3.0 on macOS 26.6.1 (25G76), during local playback through the built-in MacBook Pro Speakers. It stopped mid-song. There was no audio-device change and no CoreAudio stream/device error around the event.

The verbose log caught this causal chain (timestamps UTC):

[2026-08-29T13:50:21Z ERROR librespot_core::session] Connection to server closed.
[2026-08-29T13:50:21Z ERROR librespot_core::session] Broken pipe (os error 32)
[2026-08-29T13:50:22Z WARN  librespot_connect::spirc] unexpected shutdown
[2026-08-29T13:50:22Z WARN  librespot_core::dealer] Websocket connection failed: IO error: peer closed connection without sending TLS close_notify
[2026-08-29T13:50:23Z ERROR librespot_core::audio_key] Audio key response timeout
[2026-08-29T13:50:23Z WARN  librespot_playback::player] Unable to load key, continuing without decryption: Operation aborted { audio key response timeout }

Immediately afterward, Symphonia emitted about 1,840 invalid mpeg audio header / skipping junk warnings while scanning roughly 9.4 MB. It ended 25 seconds later with:

[2026-08-29T13:50:48Z ERROR librespot_playback::player] Unable to read audio file: Symphonia Decoder Error: end of stream
[2026-08-29T13:50:48Z INFO  fastpotify::backend] local playback session ended; reconnecting (1 of 6 in ten minutes)

Playback state was then stopped and the device list empty. This points to a transient session failure: after the Spotify connection drops, the audio-key request times out, librespot feeds encrypted bytes to the decoder, and playback ends at EOF rather than recovering.

This exactly matches upstream librespot #1419. A concrete distinction is available in librespot 0.8: timeout/channel/sequence audio-key failures map to ErrorKind::Aborted, while a server AesKeyError maps to ErrorKind::Unavailable. The aborted case could stop/retry the load instead of using AudioDecrypt::new(None, encrypted_file), preserving the unencrypted-file fallback while avoiding this decoder path.

[bakzkndd]

got the same issue ony windows btw, saw that the platform hasn't been mentioned yet so thought I'd tag in :)

[conscientiousness]

One concise follow-up from a second captured occurrence on macOS 26.6.1 / Fastpotify 0.3.0:

[2026-08-30T02:15:14Z ERROR librespot_core::session] Connection to server closed.
[2026-08-30T02:15:15Z WARN  librespot_connect::spirc] unexpected shutdown
[2026-08-30T02:15:15Z WARN  librespot_core::dealer] Websocket connection failed: IO error: peer closed connection without sending TLS close_notify
[2026-08-30T02:15:15Z INFO  fastpotify::backend] local playback session ended; reconnecting (1 of 6 in ten minutes)

Unlike the first occurrence, this one had no audio-key timeout, decoder error, CoreAudio error, output-device change, Wi-Fi link event, or Mac sleep/wake event. Fastpotify reappeared as a Connect device after reconnect, but its state was stopped and the device was active:false. Sending the play command manually resumed the same track successfully.

This suggests a second, downstream-visible part of the bug: even when reconnect itself succeeds cleanly, Fastpotify does not restore the active device/playback state automatically after the local session drops.