add zeroconf auth for spotify

[shiftybitshiftr]

As described in librespot-org/librespot#1308 (comment), Spotify has deprecated basic authentication for apps via username/password. Specifically, as of version 3.203.235 of the Spotify eSDK, the SpConnectionLoginPassword API has been removed.

This PR adds support for Spotify's zeroconf authentication via librespot, and updates the ReadMe with instructions.

Resolves #54.

[shiftybitshiftr]

I tested this PR by building from source on my Windows box and running the binary on the same host my Spotify client was running. It works!

If we want to retain auth to Spotify between bot restarts, then we need to save the encrypted blob to disk (e.g. https://github.com/codetheweb/aoede/pull/55/files#diff-b072d44757027067e88a4e0972075dd9bcf9bcc9fb44dc1c28b9b84f8e7b1e03R252). Although, to reauth all you need to do is select the device in the Spotify app, so saving the blob isn't really necessary.

Still needs to be tested from Docker.

[shiftybitshiftr]

I've now successfully tested via Docker running on a ProxMox Alpine LXC within the same network segment as my Windows box running the Spotify client. I needed to add --net=host / network_mode: host to get the mDNS broadcast to propagate correctly, I've gone ahead and added that to the ReadMe.

I've captured logs after setting RUST_LOG=debug, for posterity: aeode-local.log

[Giggitybyte]

I built this from source and I can get the bot to join, but the audio is extremely slow and choppy. Also I can't seem to get the bot to show up in the devices list when it running on a server outside of the local network.

Anyway I can help debug?

[codetheweb]

thank you! the playback is also choppy for me, although maybe it's just a temporary issue with my wifi

[codetheweb]

could we save this to a new separate file?

[shiftybitshiftr]

thank you! the playback is also choppy for me, although maybe it's just a temporary issue with my wifi

I'm able to repro the choppy playback over the network. I'm puzzled as to why - I didn't modify the audio processing and my network is running over 2.5 gig lines. Will spend some time debugging later this week

[Saikron]

Something about the audio I noticed that might be relevant is that it sounds more like the audio is being played at a slow speed and multiple times overlapping. So I think the issue might actually have something to do with performance inside the container and not network, potentially due to the stream getting played multiple times simultaneously.

[seijinmark]

While running this branch on my machine (Docker on Windows), I noticed that even though the user and password have been removed, they are still required in the environment. Without these variables, the container doesn't initialize properly.

[NotVeryAnonymous]

Something about the audio I noticed that might be relevant is that it sounds more like the audio is being played at a slow speed and multiple times overlapping. So I think the issue might actually have something to do with performance inside the container and not network, potentially due to the stream getting played multiple times simultaneously.

That is exactly how I'd describe it, I gave it it a shot myself and encountered this, so despite the credentials change of this PR working, the audio itself is completely unusable in the current state.