[GH-ISSUE #456] [Documentation] macOS sonoma (14.4.1) daemon NOT working with notify feature. #258

Open
opened 2026-03-02 23:46:00 +03:00 by kerem · 7 comments
Owner

Originally created by @ed9w2in6 on GitHub (May 28, 2024).
Original GitHub issue: https://github.com/aome510/spotify-player/issues/456

Describe the bug
After recently updating my laptop to macOS sonoma (14.4.1), the integrated daemon failed to start.
Running spotify --daemon doesn't show any error, but it seems to have failed silently (undetected), since no process are found running with ps.

To Reproduce

  • In macOS sonoma (14.4.1), run spotify --daemon.
  • After ~1s run ps auxww | grep spotify | grep -v grep and observe the lack of daemon process.

Expected behaviour
Daemon should start, that is, a process should be running at background.

Additional context
spotifyd seems to have no issue.

Log and backtrace
backtrace: none
logs:

2024-05-28T12:25:40.088166Z  INFO spotify_player: Starting the application as a daemon...
2024-05-28T12:25:40.090464Z  INFO spotify_player::state::data: Loading Playlists data from /Users/<name>/.cache/spotify-player/Playlists_cache.json...
2024-05-28T12:25:40.096249Z  INFO spotify_player::state::data: Successfully loaded Playlists data!
2024-05-28T12:25:40.096358Z  INFO spotify_player::state::data: Loading FollowedArtists data from /Users/<name>/.cache/spotify-player/FollowedArtists_cache.json...
2024-05-28T12:25:40.112057Z  INFO spotify_player::state::data: Successfully loaded FollowedArtists data!
2024-05-28T12:25:40.112139Z  INFO spotify_player::state::data: Loading SavedAlbums data from /Users/<name>/.cache/spotify-player/SavedAlbums_cache.json...
2024-05-28T12:25:40.131579Z  INFO spotify_player::state::data: Successfully loaded SavedAlbums data!
2024-05-28T12:25:40.131644Z  INFO spotify_player::state::data: Loading SavedTracks data from /Users/<name>/.cache/spotify-player/SavedTracks_cache.json...
2024-05-28T12:25:40.816104Z  INFO spotify_player::state::data: Successfully loaded SavedTracks data!
2024-05-28T12:25:41.040200Z  INFO spotify_player::auth: Successfully used the cached credentials to create a new session!
2024-05-28T12:25:41.052512Z  INFO spotify_player::token: Getting new authentication token...
2024-05-28T12:25:41.084966Z  INFO spotify_player::token: Got new token: Token { access_token: "<removed>", expires_in: TimeDelta { secs: 3600, nanos: 0 }, expires_at: Some(2024-05-28T13:25:41.084957Z), refresh_token: None, scopes: {} }
2024-05-28T12:25:41.085125Z  INFO spotify_player::streaming: Application's connect configurations: ConnectConfig { name: "spotify_player --daemon", device_type: Computer, initial_volume: Some(45219), has_volume_ctrl: true, autoplay: false }
2024-05-28T12:25:41.086614Z  INFO spotify_player::streaming: Initializing a new integrated player with device_id=83e36023-7ef5-4a97-8d3e-81eb4f80a9e3
2024-05-28T12:25:41.086731Z  INFO spotify_player::streaming: Starting an integrated Spotify player using librespot's spirc protocol
2024-05-28T12:25:41.188153Z  INFO spotify_player: No playback found on startup, trying to connect to an available device...
2024-05-28T12:25:41.188422Z  INFO spotify_player: Starting a client socket at 127.0.0.1:13579

Environment

  • OS: macOS 14.4.1 (23E224)
  • Application version: 0.18.2
  • Application features: daemon,rodio-backend,streaming,lyric-finder,image,notify
Originally created by @ed9w2in6 on GitHub (May 28, 2024). Original GitHub issue: https://github.com/aome510/spotify-player/issues/456 **Describe the bug** After recently updating my laptop to macOS sonoma (14.4.1), the integrated daemon failed to start. Running `spotify --daemon` doesn't show any error, but it seems to have failed silently (undetected), since no process are found running with `ps`. **To Reproduce** + In macOS sonoma (14.4.1), run `spotify --daemon`. + After ~1s run `ps auxww | grep spotify | grep -v grep` and observe the lack of daemon process. **Expected behaviour** Daemon should start, that is, a process should be running at background. **Additional context** `spotifyd` seems to have no issue. **Log and backtrace** backtrace: none logs: ``` 2024-05-28T12:25:40.088166Z INFO spotify_player: Starting the application as a daemon... 2024-05-28T12:25:40.090464Z INFO spotify_player::state::data: Loading Playlists data from /Users/<name>/.cache/spotify-player/Playlists_cache.json... 2024-05-28T12:25:40.096249Z INFO spotify_player::state::data: Successfully loaded Playlists data! 2024-05-28T12:25:40.096358Z INFO spotify_player::state::data: Loading FollowedArtists data from /Users/<name>/.cache/spotify-player/FollowedArtists_cache.json... 2024-05-28T12:25:40.112057Z INFO spotify_player::state::data: Successfully loaded FollowedArtists data! 2024-05-28T12:25:40.112139Z INFO spotify_player::state::data: Loading SavedAlbums data from /Users/<name>/.cache/spotify-player/SavedAlbums_cache.json... 2024-05-28T12:25:40.131579Z INFO spotify_player::state::data: Successfully loaded SavedAlbums data! 2024-05-28T12:25:40.131644Z INFO spotify_player::state::data: Loading SavedTracks data from /Users/<name>/.cache/spotify-player/SavedTracks_cache.json... 2024-05-28T12:25:40.816104Z INFO spotify_player::state::data: Successfully loaded SavedTracks data! 2024-05-28T12:25:41.040200Z INFO spotify_player::auth: Successfully used the cached credentials to create a new session! 2024-05-28T12:25:41.052512Z INFO spotify_player::token: Getting new authentication token... 2024-05-28T12:25:41.084966Z INFO spotify_player::token: Got new token: Token { access_token: "<removed>", expires_in: TimeDelta { secs: 3600, nanos: 0 }, expires_at: Some(2024-05-28T13:25:41.084957Z), refresh_token: None, scopes: {} } 2024-05-28T12:25:41.085125Z INFO spotify_player::streaming: Application's connect configurations: ConnectConfig { name: "spotify_player --daemon", device_type: Computer, initial_volume: Some(45219), has_volume_ctrl: true, autoplay: false } 2024-05-28T12:25:41.086614Z INFO spotify_player::streaming: Initializing a new integrated player with device_id=83e36023-7ef5-4a97-8d3e-81eb4f80a9e3 2024-05-28T12:25:41.086731Z INFO spotify_player::streaming: Starting an integrated Spotify player using librespot's spirc protocol 2024-05-28T12:25:41.188153Z INFO spotify_player: No playback found on startup, trying to connect to an available device... 2024-05-28T12:25:41.188422Z INFO spotify_player: Starting a client socket at 127.0.0.1:13579 ``` **Environment** - OS: macOS 14.4.1 (23E224) - Application version: 0.18.2 - Application features: `daemon,rodio-backend,streaming,lyric-finder,image,notify`
Author
Owner

@ed9w2in6 commented on GitHub (May 28, 2024):

One work around is to not use the deamon feature, other features seems to work properly.

<!-- gh-comment-id:2135123301 --> @ed9w2in6 commented on GitHub (May 28, 2024): One work around is to not use the deamon feature, other features seems to work properly.
Author
Owner

@aome510 commented on GitHub (May 31, 2024):

@ed9w2in6 I found out it was because of notify feature. If disabled, daemon will work. MacOS has some OS-level restriction that doesn't allow you to do specific things with forked process. Previously, it didn't work with media-control feature. Now with new OS update, I will not be surprised if it doesn't work with notify feature.

<!-- gh-comment-id:2141159051 --> @aome510 commented on GitHub (May 31, 2024): @ed9w2in6 I found out it was because of `notify` feature. If disabled, daemon will work. MacOS has some OS-level restriction that doesn't allow you to do specific things with forked process. Previously, it didn't work with `media-control` feature. Now with new OS update, I will not be surprised if it doesn't work with `notify` feature.
Author
Owner

@ed9w2in6 commented on GitHub (Jun 3, 2024):

@aome510 Thank you for your investigation.
I had recompiled without the notify feature and the daemon does work again.

macOS have changed a bit on permission control for deamon-like processes. There is a new settings panel under System Settings > General > Login Items > Allow in the Background. I had also tried writing a custom LaunchAgent xml manifest file under ~/Library/LaunchAgents/, which is the orthodox way to register daemons in macOS, which does make it show up under then new settings panel. However I cannot manage to make it work as expected.

As a workaround I believe one can use the player_event_hook_command with some notifying software to achieve the same functionality:

<!-- gh-comment-id:2144271333 --> @ed9w2in6 commented on GitHub (Jun 3, 2024): @aome510 Thank you for your investigation. I had recompiled without the `notify` feature and the daemon does work again. macOS have changed a bit on permission control for deamon-like processes. There is a new settings panel under `System Settings > General > Login Items > Allow in the Background`. I had also tried writing a custom `LaunchAgent` xml manifest file under `~/Library/LaunchAgents/`, which is the orthodox way to register daemons in macOS, which does make it show up under then new settings panel. However I cannot manage to make it work as expected. As a workaround I believe one can use the `player_event_hook_command` with some notifying software to achieve the same functionality: + https://github.com/julienXX/terminal-notifier + https://github.com/vjeantet/alerter
Author
Owner

@ed9w2in6 commented on GitHub (Jun 3, 2024):

I believe this issue can be closed after modifying the README file to document this issue for newer version of macOS.

<!-- gh-comment-id:2144272231 --> @ed9w2in6 commented on GitHub (Jun 3, 2024): I believe this issue can be closed after modifying the README file to document this issue for newer version of macOS.
Author
Owner

@ed9w2in6 commented on GitHub (Jun 5, 2024):

Turns out the workaround worked better than I thought:

image

The shell scripting part is arguably quite trivial by interfacing with spotify_player get .... The user is free to include more or less content as they wish, and are free to choose using any tool to send notification. Latency is not important in this context anyway.

Perhaps now with the player_event_hook_command the notify feature is not needed after all?

I can share my script anyone wishes to use it.

<!-- gh-comment-id:2149387295 --> @ed9w2in6 commented on GitHub (Jun 5, 2024): Turns out the workaround worked better than I thought: <img width="358" alt="image" src="https://github.com/aome510/spotify-player/assets/22890124/dc520f2e-fbeb-44ca-a77b-53eb263d1110"> The shell scripting part is arguably quite trivial by interfacing with `spotify_player get ...`. The user is free to include more or less content as they wish, and are free to choose using any tool to send notification. Latency is not important in this context anyway. Perhaps now with the `player_event_hook_command` the `notify` feature is not needed after all? I can share my script anyone wishes to use it.
Author
Owner

@burakkarasu commented on GitHub (Feb 21, 2025):

I'm on Sonoma 14.5 and notifications work just fine but they do have the finder icon on them.
@ed9w2in6 Upon seeing your workaround, I was immediately filled with envy. Please do share your script if you can. Also, is this with terminal-notifier or alerter?

<!-- gh-comment-id:2675395044 --> @burakkarasu commented on GitHub (Feb 21, 2025): I'm on Sonoma 14.5 and notifications work just fine but they do have the finder icon on them. @ed9w2in6 Upon seeing your workaround, I was immediately filled with envy. Please do share your script if you can. Also, is this with terminal-notifier or alerter?
Author
Owner

@deauthe commented on GitHub (Oct 13, 2025):

@ed9w2in6 would really appreciate the script. Do I need to do some changes in the source code?

<!-- gh-comment-id:3397184702 --> @deauthe commented on GitHub (Oct 13, 2025): @ed9w2in6 would really appreciate the script. Do I need to do some changes in the source code?
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/spotify-player#258
No description provided.