crmne/fastpotify

0.5.0 includes a first-open command that works on macOS 26 and 27, but the release is still not notarized. Could you try 0.5.0 using the current download-page instructions and confirm whether it opens normally?

`-r` doesn't work on macOS 27 beta:

```
% xattr -dr com.apple.quarantine /Applications/Fastpotify.app
option -r not recognized
```

Yes, a notarized release probably also avoids

Sounds good, and yea might aswell do it the proper way once ur at it.

Fair enough. The poll costs next to nothing, but immediacy is a real feature, so I will look at the callbacks (IMMNotificationClient on Windows, a CoreAudio property listener on macOS) for a later version; if their contract is clean they are the better way. Linux needs neither, PipeWire and PulseAudio move the stream themselves.

Part of this exists since 0.2.0: at start the app asks GitHub for the latest release and, when it is newer than the one running, shows a notice with the version and a link to the release page. Pre-releases are left out, which is why 0.3.0 does not mention 0.4.0-rc1, and if you never saw the notice you were on the latest release. Replacing the install from inside the app is a bigger piece; the split you describe between self-contained installs and package managers is the right shape for it. Leaving this open as that request.

> Two things in that log. The crash is librespot: when its PulseAudio sink loses the connection ("Connection terminated") it calls exit(1) and takes the whole app down. On Linux that sink is the default output. The connection dying is the other thing: the Flatpak is a community package, not built here, and a sandbox without the PulseAudio socket looks exactly like this (the log also shows it cannot reach X11 for the clipboard). Could you run `flatpak info --show-permissions rocks.fastpotify.Fastpotify` and check for `--socket=pulseaudio`? If it is missing, `flatpak override --user --socket=pulseaudio rocks.fastpotify.Fastpotify` should fix it, and the package needs the same. Two other things to try: Settings, Audio output, "ALSA (rodio)", which reports an output failure instead of exiting, or the release binary or AUR package.

pulseaudio does show in the sockets.
this is the full output:

> [Context]
shared=ipc;network;
sockets=fallback-x11;pulseaudio;wayland;x11;
devices=dri;
filesy...

The problem is only with the flatpak package, regular binary install works fine

Same issue on Fedora KDE, Flatpak 0.3.0. Dug into it with strace — might help narrow this down.

The connect() to the PulseAudio socket actually **succeeds**:
```
connect(57, {sa_family=AF_UNIX, sun_path="/run/flatpak/pulse/native"}, 110) = 0
```
but no PulseAudio protocol bytes are ever written to that fd before it gets closed:
```
connect(57, ".../pulse/native") = 0
close(57)
```
So this isn't an actual connection refusal at the socket/sandbox level — the client gives up before completing the protocol handshake, and the app reports that as "Connection Refused" itself. Same result with `audio_backend: "rodio"` (ALSA→pulse plugin), so it's not backend-specific.

Ruled out on the system side: sandbox has `sockets=pulseaudio` permission, `PULSE_SERVER`/`PULSE_CLIENTCONFIG` env vars are set correctly inside the sandboxed process, and `pactl info` run from inside the same sandbox connects and completes the handshake fine — so PulseAudio/PipeWire itself and the Flatpak permissions are not t...

can't add label to the issue. it should be `enhancement`

Got the exact same behaviour on Fedora 44 Workstation (Gnome) with the FlatPark package.

There are ways to receive callbacks for audio device changes on windows linux and mac, polling every 2 seconds is wasteful.

mise ~/.config/mise/config.toml tools: gh@2.98.0
mise ~/.config/mise/config.toml tools: gh@2.98.0
Two things in that log. The crash is librespot: when its PulseAudio sink loses the connection ("Connection terminated") it calls exit(1) and takes the whole app down. On Linux that sink is the default output. The connection dying is the other thing: the Flatpak is a community package, not built here, and a sandbox without the PulseAudio socket looks exactly like this (the log also shows it cannot reach X11 for the clipboard). Could you run `flatpak info --show-permissions rocks.fastpotify.Fastpotify` and check for `--socket=pulseaudio`? If it is missing, `flatpak override --user --socket=pulseaudio rocks.fastpotify.Fastpotify` should fix it, and the package needs the same. Two other things to try: Settings, Audio output, "ALSA (rodio)", which reports an output failure instead of exiting, or the release binary or AUR package.

Update, with the strace and the permissions posted below: the sa...

Released in 0.4.0-rc5 (https://github.com/crmne/fastpotify/releases/tag/v0.4.0-rc5): while playing on this computer, Fastpotify checks every couple of seconds which device the system calls its default and moves playback there when it changes, on Windows and macOS. Linux already gets this from PipeWire and PulseAudio. It applies while no specific device is set in the settings. I could only exercise the Linux side here, so if you can try it on Windows I would like to hear how it behaves.

Thanks, that is a precise report. The docs and the Homebrew cask now say `xattr -dr`, which clears the flag from the files inside the bundle as well; that is what macOS 26 trips over. The real fix is a notarized build. The release workflow already signs and notarizes when the Apple credentials are there, and I am putting those in place, so this stays open until a notarized release is out.