Open vv9k opened 3 years ago
Yes it's mentioned in the roadmap, but it's a lot of work. Definitely wanted, though.
Should've read the road map properly I guess :) But at least now there is an issue to track that. I might dive into the code base later and see if I'm able to come up with something at least partially working.
The most complete Connect impl now is probably librespot-java
, and we should probably take a look how things are done over there.
From my initial findings I thought it might be enough to use the transfer method provided by aspotify player, but that's just very shallow research. If it allows to use the player to later control the changed device than it wouldn't be too much work.
There's a little guide on the spotify website. Seems like psst would need some refactoring to integrate this properly.
One idea that came to my mind was having a spotify connect "device" running in the background. Then the UI just sends all commands as an API request – and the background device handles whatever it gets from the spotify API. So when the user selects a different device, the UI sends the same commands to a different device. Does that make sense?
rust version too https://github.com/librespot-org/librespot/
@jpochyla commented on Feb 2, 2021, 4:10 AM PST: The most complete Connect impl now is probably
librespot-java
, and we should probably take a look how things are done over there.
librespot dev here - couple of things:
librespot-java is the most feature-complete open source connect client atm. librespot does do connect, but some of the protocols/messages used are not the latest.
If you do opt to add this, the connect functionality is basically an event system - I'd recommend having this functionality as separate from the core of psst as possible, and running in a separate thread, as it doesn't really fit into a library in the traditional sense, with Spotify pushing a range of events depending on what other devices are doing.
librespot dev here - couple of things:
* If you do opt to add this, the connect functionality is basically an event system - I'd recommend having this functionality as separate from the core of psst as possible, and running in a separate thread, as it doesn't really fit into a library in the traditional sense, with Spotify pushing a range of events depending on what other devices are doing.
Just to clarify: Were you referring here only to the "sink" role or is this relevant also when using it as a remote for other devices?
Could make sense to focus only on the latter in psst - people who want to Connect the local device can run spotifyd separately.
Looks like that should simplify things a lot by just needing to send the proper Web API requests?
spot#427 for adding the same functionality in Spot should be relevant.
@3nprob, for me, the most usefull Spotify Connect use-cases would be:
@jpochyla just curious, is there some reason why spotifyd (which can be run alongside psst just fine) doesn't solve this for you already? (It's still a useful feature, don't get me wrong!)
We're coming from the opposite perspective (love the clean UI in psst and want to use it as a remote for other Connect devices)
Spotify has this Connect feature that allows one to play audio on other devices logged into the same account and control the playback remotely. I would love to see this feature beeing part of psst as I often like to use my pc to control playback on my phone that is connected to some speakers by cable or is just out of reach.