disable-discovery doesn't disable discovery

[michaelherger]

Running librespot with the --disable-discovery parameter and credentials would still make it announce itself and show up in eg. the Spotify desktop app.

[janderholm]

Are you sure you have removed CACHEDIR/credentials.json? If it exists librespot will automatically log in and thus show up in your account (not others)

--disable-discovery is only used for disabling the mdns discovery feature for local unauthenticated clients.

[michaelherger]

Ok, that probably shows my limited understanding of what "discovery" is supposed to be. Is this only being used to announce itself to "unknown" control points? Eg. if authenticated, my librespot client would always show up in other clients or control points where I'm logged in with the same credentials?

I would actually like to hide this player from other Spotify apps. No way to do so?

[plietar]

Discovery means you don't need to provide credentials to librespot.
Devices on the same local network can select it and send credentials over.

Once authentication is over, whether or not discovery was enabled makes no difference.

I'm not sure why you're trying to hide the player ? How will you control it ?

[michaelherger]

Good point: I'm looking for a new implementation to play Spotify content on the Logitech Squeezebox. All available solutions are based on libspotify, which is supposed to disappear later this year. Squeezebox has a transcoding framework which allows us to stream "files" piped through some helper application. I've built a modified version of the librespot application which would take a track URI and pipe it into LMS' transcoding framework and out to the players.

As LMS/Squeezebox comes with its own play queue management, which allows to mix and match local content with tracks from music services (even different ones, if needed), I'm looking for a single track based approach. But if I run the librespot application, I want it to only play that one track. If I tell the Spotify application to control it, then LMS will not get the metadata and get confused overall.

I could imagine a solution where librespot would serve as a http server, streaming directly over http rather than through a series of piped tools. But as I'm all new to Rust, this is far out of my scope for now...

FWIW: my prototype implementation is working fine, including gapless playback. I've been able to compile for MacOS, Linux x86_64 and Pi. But it's an ugly hack. I don't even know how to gracefully quit the app once the track has fully played or been stopped...

[plietar]

librespot can be used as a library (even though it isn't documented properly). You'd probably want to make a different binary which depends on it.

The librespot binary uses the Spirc type to receive Spotify commands. You'll probably want to ignore it and use the Player type directly. It exposes a load/play/pause/seek API. The load function returns a future which completes when the track reached the end.

I'm very interested to see people using librespot as a library. This is how I originally imagined it, but the binary has been enough for most people's uses. I'm happy to help you out if you have other questions with using the library, but gitter is probably a better way. Feel free to ping me on there.

[kingosticks]

Using it as a library is exactly what we'd need for Mopidy if we were to swap over from the junk that is libspotify. If it could directly provide the audio data we can feed it gstreamer just like we do now. I did try to look at this but I have absolutely no experience with rust and to be honest I've not got the time or enthusiasm to invest in that. Are there plans to document the library? I did read a bit into exposing a rust library to python and that seemed quite straightforward.

…

On 28 Apr 2017 9:44 p.m., "Paul Liétar" ***@***.***> wrote: librespot can be used as a library (even though it isn't documented properly). You'd probably want to make a different binary which depends on it. The librespot binary uses the Spirc type to receive Spotify commands. You'll probably want to ignore it and use the Player <https://github.com/plietar/librespot/blob/master/src/player.rs> type directly. It exposes a load/play/pause/seek API. The load function returns a future which completes when the track reached the end. I'm very interested to see people using librespot as a library. This is how I originally imagined it, but the binary has been enough for most people's uses. I'm happy to help you out if you have other questions with using the library, but gitter <https://gitter.im/sashahilton00/spotify-connect-resources> is probably a better way. Feel free to ping me on there. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#179 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA5DqIxOI9CbRlP4u1e97n2jHI7Dym_Wks5r0k-QgaJpZM4NKZie> .

[plietar]

Are there plans to document the library?

Unfortunately I don't really have much time to dedicate to librespot at the moment, so not really. I'd like to though, and I'll happily merge any PR which goes in that direction.

If like @michaelherger you just want to feed a track id and get audio data out you can use the Player type and provide a custom Sink implementation to it. That's the core part of librespot.

The Spirc type adds support for play queue and spotify connect on top of that, but that probably interferes with mopidy's own play queue so you can ignore that.

The metadata part is definitely lacking compared to libspotify.

Again, ping me on gitter anytime if you have some questions

[plietar]

I've just pushed a simple example using the Player on its own
https://github.com/plietar/librespot/blob/294a7821d682d9f694d26feabc67048f343c7a56/examples/play.rs

[michaelherger]

@plietar - you rock! thanks a lot!