Defer Spotify Connect mirroring, and fix the discovery lifecycle

[magedhennawy]

Two things from #354 that belong together.

Mirroring: polls /me/player/currently-playing every 5s through raw requests.get, bypassing make_call, so it has no 429 handling at all. Given the API limits are now tight enough to 429 before a song downloads, this is worth deferring until the quota picture is clearer.

Discovery lifecycle: the service currently starts at app startup and runs indefinitely. It should start on pairing and be killed once pairing completes. Right now spotify_new_session also closes the shared session and deletes the shared credentials file, so a second "add account" click disconnects whoever is currently casting.

Related open question: #316 and #304 are users reporting the device never appears at all, both macOS. librespot advertises via gethostbyname(gethostname()), which on macOS usually gives 127.0.0.1 or raises, so the record points nowhere. _spotify_connect_interface() in #354 overrides that and may already fix both, except it only accepts 192.168.*, so a Mac on 10.x still gets nothing. Worth resolving alongside.

[moddroid94]

edit: commented the wrong issue at first lol.

I disabled mirroring and connect services from the fastapi lifetime hook, so they do not start anymore at launch.

we should define some lifecycle in a method for the connect service so it start at login and closes when done.

for the mirroring we could just implement the mirroring of listenbrainz scrobbles, this way we make the mirroring service-agnostic and universal, i'm not sure if the native integration shares the url or the track for the service, but there are plenty of scrobblers that does that i'm sure.

[moddroid94]

@magedhennawy this actually overlaps quite a bit in scope with the companion, i just figured that we technically do not need the discovery at all if we use the companion.

both do the same thing, one is meant to be running directly on the server, one locally on your pc.

the local companion starts a zeroconfig server and posts to a simple api endpoint "/accounts/spotify/companion/complete" that uses the payload to add the login, so we could technically drop the discovery completely and use only the companion.

This could even get away with all those bug with osx and interface grab as we can build a simple script that ask explicitly for the interface, also the interface entry in the config then becomes technically useless too.
wyt?

mirroring will be dropped for good for now, i'll take care of implementing the listenbrainz scrobbling feature.

related to #372

[magedhennawy]

@moddroid94 agreed, let's do it. dropping discovery and going companion only.

it's the right call. discovery only exists to advertise the server on the lan, and that's the exact thing that keeps breaking: docker advertises the container ip, macos gethostbyname(gethostname()) usually comes back 127.0.0.1, and the interface config entry only exists to paper over both. run the companion on the user's own machine and zeroconf is talking to a spotify client on the same host, so #316 and #304 stop existing rather than getting fixed.

two things going in alongside it, i'll pick both up:

transport. companion/run.py currently does args.server_url.rstrip("/") and posts the login blob to whatever that is, with no scheme check. that's tolerable as one of two ways in, not as the only way in. i'll add a guard that rejects non-https unless the host is loopback or rfc1918, with an explicit --allow-insecure to override it.

packaging. for docker and headless this is a straight upgrade. for someone on bare metal, "download and run this second script" is a step back from a button in the ui. i'll look at adding the companion to the existing release workflow so it ships as a binary alongside the app builds rather than as a script people have to set up themselves.

once discovery is actually gone, #372 can close with it. the interface config entry stops meaning anything at that point, so no need to finish that one.