Is your feature request related to a problem? Please describe.
The CLI is a remote control for an existing Spotify device. After #465 it can activate a listed idle device, but when no Spotify client is open anywhere there is still nothing to make sound: spotatui playback --toggle on a machine with no running player has no target. The CLI process itself cannot host native streaming because it is one-shot; the audio pipeline and the Connect device would die the moment the command exits. Building a librespot session per shell invocation is also the short-lived connect/disconnect pattern that produced the ghost Connect devices of #297, and it would add a session handshake of a second or two to every command.
Today the answer is "keep the TUI running in a terminal somewhere", which works but should not be a requirement for shell-driven playback.
Describe the solution you'd like
A spotatui daemon subcommand: one persistent headless process that owns a StreamingPlayer as a long-lived Spotify Connect device (in the spirit of spotifyd), while the CLI stays a thin remote that reaches it through the existing saved-device path. Rough scope:
- single-instance locking so a second daemon (or a TUI with native streaming) does not fight over the persisted Connect
device_id
- shared auth and cache with the TUI, with a defined handoff when the TUI starts while the daemon runs (or mutual exclusion)
- clean shutdown (
spotatui daemon --stop or signal handling) so no ghost device is left behind
- an autostart story per platform (systemd unit, Windows service or startup task, launchd)
Describe alternatives you've considered
Additional context
A long-lived headless core process overlaps heavily with the frontend-neutral substrate work already underway (driver extraction, lib/bin split). The daemon and any future non-terminal frontend want the same thing: a core that owns playback and state without a terminal attached. Designing the daemon as a consumer of that substrate, rather than a CLI bolt-on, keeps one core instead of two.
Is your feature request related to a problem? Please describe.
The CLI is a remote control for an existing Spotify device. After #465 it can activate a listed idle device, but when no Spotify client is open anywhere there is still nothing to make sound:
spotatui playback --toggleon a machine with no running player has no target. The CLI process itself cannot host native streaming because it is one-shot; the audio pipeline and the Connect device would die the moment the command exits. Building a librespot session per shell invocation is also the short-lived connect/disconnect pattern that produced the ghost Connect devices of #297, and it would add a session handshake of a second or two to every command.Today the answer is "keep the TUI running in a terminal somewhere", which works but should not be a requirement for shell-driven playback.
Describe the solution you'd like
A
spotatui daemonsubcommand: one persistent headless process that owns aStreamingPlayeras a long-lived Spotify Connect device (in the spirit of spotifyd), while the CLI stays a thin remote that reaches it through the existing saved-device path. Rough scope:device_idspotatui daemon --stopor signal handling) so no ghost device is left behindDescribe alternatives you've considered
Additional context
A long-lived headless core process overlaps heavily with the frontend-neutral substrate work already underway (driver extraction, lib/bin split). The daemon and any future non-terminal frontend want the same thing: a core that owns playback and state without a terminal attached. Designing the daemon as a consumer of that substrate, rather than a CLI bolt-on, keeps one core instead of two.