From 80759ec50e2eef41fda5a6817354260a0e36f077 Mon Sep 17 00:00:00 2001
From: rope <fredrik@nordhammer.it>
Date: Sun, 16 Aug 2026 13:05:03 +0100
Subject: [PATCH] Revert spotify-player daemon: it kills the visualiser

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 home-manager/fred.nix | 39 +++++++--------------------------------
 1 file changed, 7 insertions(+), 32 deletions(-)

diff --git a/home-manager/fred.nix b/home-manager/fred.nix
index 8bd715c..7220787 100644
--- a/home-manager/fred.nix
+++ b/home-manager/fred.nix
@@ -133,14 +133,12 @@ in
       # of the wheel is a dozen requests and a 429. Use PipeWire for volume
       # instead — same sink, instant, free.
       enable_mouse_scroll_volume = false;
-      # The librespot device is only usable once Spotify's backend has accepted
-      # it, which takes ~20s from process start — that is the wait before you can
-      # play anything, and it is server-side, so there is nothing local to speed
-      # up. Instead, pay it once at login: the daemon below holds the device for
-      # the whole session, and DaemonOnly keeps the TUI from registering a second
-      # one, so opening the TUI is instant and plays straight onto the daemon's
-      # device.
-      enable_streaming = "DaemonOnly";
+      # Streaming stays on in the TUI (the default). A `spotify_player --daemon`
+      # holding the device, with enable_streaming = "DaemonOnly" here, does move
+      # the ~20s device registration to login — but the visualiser above is fed
+      # only by the in-process librespot player (state/mod.rs vis_bands, written
+      # solely from streaming.rs), so a TUI that isn't the player can never draw
+      # it. Visualiser and daemon are mutually exclusive; the visualiser wins.
     };
     # Rectangle gauges only ever use `playback_progress_bar`: ratatui paints the
     # filled part in its fg and the rest in its bg, and `_unfilled` is ignored
@@ -216,34 +214,11 @@ in
     ];
   };
 
-  # Holds the librespot Spotify Connect device for the whole session, so the
-  # ~20s the Spotify backend takes to accept a new device is paid once at login
-  # instead of on every launch. Also means the MPRIS card in quickshell keeps
-  # working with no terminal open. Type=forking because the daemonize crate
-  # double-forks and the parent exits; it writes no pidfile, so systemd guesses.
-  systemd.user.services.spotify-player-daemon = lib.mkIf isDesktop {
-    Unit = {
-      Description = "spotify-player daemon (holds the Spotify Connect device)";
-      After = [ "graphical-session.target" "pipewire.service" ];
-      PartOf = [ "graphical-session.target" ];
-    };
-    Service = {
-      Type = "forking";
-      ExecStart = "${config.programs.spotify-player.package}/bin/spotify_player --daemon";
-      Restart = "on-failure";
-      RestartSec = 10;
-    };
-    Install.WantedBy = [ "graphical-session.target" ];
-  };
-
   # Upstream ships no .desktop file (TUI only), so the launcher can't find it.
-  # enable_media_control=false: media-control is not gated on `is_daemon`, so
-  # without this both the daemon and the TUI export org.mpris.MediaPlayer2 and
-  # quickshell would show two cards for one player. The daemon owns MPRIS.
   xdg.desktopEntries.spotify-player = lib.mkIf isDesktop {
     name = "Spotify Player";
     genericName = "Music Player";
-    exec = "ghostty --title=spotify-player -e spotify_player -o enable_media_control=false";
+    exec = "ghostty --title=spotify-player -e spotify_player";
     icon = "spotify";
     terminal = false;
     categories = [ "Audio" "Music" "Player" "AudioVideo" ];