Git Product home page Git Product logo

librespot's Introduction

Build Status Gitter chat Crates.io

Current maintainers are listed on GitHub.

librespot

librespot is an open source client library for Spotify. It enables applications to use Spotify's service to control and play music via various backends, and to act as a Spotify Connect receiver. It is an alternative to the official and now deprecated closed-source libspotify. Additionally, it will provide extra features which are not available in the official library.

Note: librespot only works with Spotify Premium. This will remain the case. We will not support any features to make librespot compatible with free accounts, such as limited skips and adverts.

Quick start

We're available on crates.io as the librespot package. Simply run cargo install librespot to install librespot on your system. Check the wiki for more info and possible usage options.

After installation, you can run librespot from the CLI using a command such as librespot -n "Librespot Speaker" -b 160 to create a speaker called Librespot Speaker serving 160 kbps audio.

This fork

As the origin by plietar is no longer actively maintained, this organisation and repository have been set up so that the project may be maintained and upgraded in the future.

Documentation

Documentation is currently a work in progress, contributions are welcome!

There is some brief documentation on how the protocol works in the docs folder.

COMPILING.md contains detailed instructions on setting up a development environment, and compiling librespot. More general usage and compilation information is available on the wiki. CONTRIBUTING.md also contains our contributing guidelines.

If you wish to learn more about how librespot works overall, the best way is to simply read the code, and ask any questions you have in our Gitter Room.

Issues & Discussions

We have recently started using Github discussions for general questions and feature requests, as they are a more natural medium for such cases, and allow for upvoting to prioritize feature development. Check them out here. Bugs and issues with the underlying library should still be reported as issues.

If you run into a bug when using librespot, please search the existing issues before opening a new one. Chances are, we've encountered it before, and have provided a resolution. If not, please open a new one, and where possible, include the backtrace librespot generates on crashing, along with anything we can use to reproduce the issue, e.g. the Spotify URI of the song that caused the crash.

Building

A quick walkthrough of the build process is outlined below, while a detailed compilation guide can be found here.

Additional Dependencies

We recently switched to using Rodio for audio playback by default, hence for macOS and Windows, you should just be able to clone and build librespot (with the command below). For Linux, you will need to run the additional commands below, depending on your distro.

On Debian/Ubuntu, the following command will install these dependencies:

sudo apt-get install build-essential libasound2-dev

On Fedora systems, the following command will install these dependencies:

sudo dnf install alsa-lib-devel make gcc

librespot currently offers the following selection of audio backends:

Rodio (default)
ALSA
GStreamer
PortAudio
PulseAudio
JACK
JACK over Rodio
SDL
Pipe
Subprocess

Please check the corresponding Compiling entry on the wiki for backend specific dependencies.

Once you've installed the dependencies and cloned this repository you can build librespot with the default backend using Cargo.

cargo build --release

Packages

librespot is also available via official package system on various operating systems such as Linux, FreeBSD, NetBSD. Repology offers a good overview.

Packaging status

Usage

A sample program implementing a headless Spotify Connect receiver is provided. Once you've built librespot, run it using :

target/release/librespot --name DEVICENAME

The above is a minimal example. Here is a more fully fledged one:

target/release/librespot -n "Librespot" -b 320 -c ./cache --enable-volume-normalisation --initial-volume 75 --device-type avr

The above command will create a receiver named Librespot, with bitrate set to 320 kbps, initial volume at 75%, with volume normalisation enabled, and the device displayed in the app as an Audio/Video Receiver. A folder named cache will be created/used in the current directory, and be used to cache audio data and credentials.

A full list of runtime options is available here.

Please Note: When using the cache feature, an authentication blob is stored for your account in the cache directory. For security purposes, we recommend that you set directory permissions on the cache directory to 700.

Contact

Come and hang out on gitter if you need help or want to offer some: https://gitter.im/librespot-org/spotify-connect-resources

Disclaimer

Using this code to connect to Spotify's API is probably forbidden by them. Use at your own risk.

License

Everything in this repository is licensed under the MIT license.

Related Projects

This is a non exhaustive list of projects that either use or have modified librespot. If you'd like to include yours, submit a PR.

  • librespot-golang - A golang port of librespot.
  • plugin.audio.spotify - A Kodi plugin for Spotify.
  • raspotify - A Spotify Connect client that mostly Just Works™
  • Spotifyd - A stripped down librespot UNIX daemon.
  • rpi-audio-receiver - easy Raspbian install scripts for Spotifyd, Bluetooth, Shairport and other audio receivers
  • Spotcontrol - A golang implementation of a Spotify Connect controller. No playback functionality.
  • librespot-java - A Java port of librespot.
  • ncspot - Cross-platform ncurses Spotify client.
  • ansible-role-librespot - Ansible role that will build, install and configure Librespot.
  • Spot - Gtk/Rust native Spotify client for the GNOME desktop.
  • Snapcast - synchronised multi-room audio player that uses librespot as its source for Spotify content

librespot's People

Contributors

allquixotic avatar ashthespy avatar awiouy avatar brain0 avatar comlonline avatar dependabot[bot] avatar dnlmlr avatar eladyn avatar georgehahn avatar henquist avatar herrernst avatar janderholm avatar jasonlg1979 avatar jlehtoranta avatar jnqnfe avatar joerg-krause avatar johannesd3 avatar kaymes avatar kingosticks avatar laurentlouf avatar lrbalt avatar newpavlov avatar plietar avatar roderickvd avatar romerod avatar sashahilton00 avatar simonteixidor avatar thekr1s avatar willstott101 avatar yubiuser avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

librespot's Issues

Spotify track symlinks not resolved

Issue by XDjackieXD
Wednesday Feb 08, 2017 at 22:10 GMT
Originally opened as plietar/librespot#153


Some songs in Spotify "symlink" to the actual song and therefore can't be played by librespot.
This does not happen when using spirc as the spotify client already resolves these links.
When supplying the URI directly, librespot panics.
One of those songs is spotify:track:4mu8svGkGaO2dgAcTlo0FK but there are many more.

Fixed volume

Issue by mattiash
Thursday Mar 09, 2017 at 18:13 GMT
Originally opened as plietar/librespot#161


Add a --fixed-volume setting that keeps volume at 100%. The volume used in the spotify connect communication is logged.

I am running librespot on a raspberry pi connected to an external amplifier with an API. I want the raspberry pi to always output sound at full volume and then I will adjust the volume on the external amplifier based on the logged volume from librespot.


mattiash included the following code: https://github.com/plietar/librespot/pull/161/commits

Output Metadata

Issue by balbuze
Sunday Feb 19, 2017 at 18:12 GMT
Originally opened as plietar/librespot#154


Hi!
Not a bug ! Thank you for your great work !
I wrote a plugin for volumio2 using spotify-connect-web and an other new one using librespot.
I managed multi users with 2 instances of librespot
I added some script to check cache size and when limit is reached, purge oldest files in the cache.
Now I would like to add metadata (track name and album art in volumio2. But I need some information on how to get this from librespot.
my repo https://github.com/balbuze/volumio-plugins/tree/master/plugins/music_service/volspotconnect2

Provide more/better event hooks

librespot does provide runtime parameters to trigger an external script on some events. I'd like to see this expanded to support native events in the library code. Plus more events than start/stop/change. Eg. a track skip, volume change etc. are not supported at this point.

Background: my main interest currently is Spotify on Squeezebox/Logitech Media Server (LMS). Integration with this environment isn't trivial, as audio data isn't fed to the player hardware, but would go through LMS, then over the network to the players. In order to keep the player UI up to date and in sync with the actual playback, I need to know about changes.

The users of this plugin run LMS on all kinds of platforms, from Windows, over Mac, to various NAS devices, Raspberry Pi, desktop Linux and even FreeBSD. Scripting these platforms in a generic and reliable way is difficult. I therefore forked librespot to add hooks in place of the above which would trigger http requests to LMS. While this works pretty well, it's a hack. I added code mostly to the player.rs code, but would be happy to get back to plain librespot code...

Add initial support for ALSA mixer

Issue by joerg-krause
Thursday Mar 09, 2017 at 09:35 GMT
Originally opened as plietar/librespot#160


The ALSA mixer module implements a simple linear volume control. Note, that a linear volume control is not ideal for human audio experience as our ears respond to sound on an exponential curve.

The mixer also works fine with the ALSA softvol plugin which offers an logarithmic attenuation curve.

TODO: Use logarithmic curve for hardware mixers.


joerg-krause included the following code: https://github.com/plietar/librespot/pull/160/commits

Can librespot be used to cast to other spotify-apps, chromecast etc?

Issue by kristoffernolgren
Friday Jun 09, 2017 at 12:41 GMT
Originally opened as plietar/librespot#196


I'm currently using home-assistants and trying to use the built in spotify-connect solution.

Spotifys connct is not working great for casting to initiate casting to new devices. You can basically just manipulate castings that are already up and running. I'm looking at the docs for librespot and can't find any way to start a casting or even play a song from command line. Is this possible? Are there any docs?

Panic on an `Err` value: InitialFileHeadersCorrupt

Issue by joerg-krause
Saturday Oct 08, 2016 at 08:53 GMT
Originally opened as plietar/librespot#121


Sometimes, librespot panics with:

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: InitialFileHeadersCorrupt', src/libcore/result.rs:799

This issue happens if a track is loaded in the Spotify Connect Client (so I can see the cover and the track artists and song title), but is not played locally (but was played before). Then I start librespot on my embedded Linux device, connect the client with librespot and after 3 or 4 seconds the panic happens.

Note, I am using Tremor as ogg decoder.

Crossfading

Issue by niklasdoerfler
Sunday Jun 26, 2016 at 10:53 GMT
Originally opened as plietar/librespot#87


Hey,

it would be nice, if you could implement the ability to set up some fading between two tracks (as the original client does). Is that possible?

Thanks!
Niklas

Building on Windows

Issue by NeoLegends
Sunday Apr 24, 2016 at 15:50 GMT
Originally opened as plietar/librespot#77


Even after a couple hours of trying, I still cannot get this library to build on Windows (Rust Nightly 1.10 64-bit GNU). So far I've got the following:

  • Build environment using MSYS2 + MinGW 64
  • Protobuf binaries compiled from sources
  • PortAudio binaries from Github Repo somewhere

Right now I'm having trouble building librespot-protocol, respectively linking against libz (can't find the .dll, linker option: -lz). Using the one from zlib.net doesn't work, because it's not 64-bit, and I'd prefer having a 64-bit executable in the end.

Has anybody tried building librespot on Windows recently? Any ideas on how to do this?

Main thread panicks when sound device unavailable

Issue by TonioRoffo
Friday Mar 17, 2017 at 07:55 GMT
Originally opened as plietar/librespot#165


Using:

./librespot -n SpotifyMain -b 320 --backend portaudio --device "NAD USB Audio 2.0: - (hw:2,0)"

commit eb49ff3 on Ubuntu 16.04

If the hardware is claimed by other software (or hardware not available) and spotify connect attempts to load a song, the main thread panicks & fails.

Suggestion is to make it fail gracefully and wait for the next command?

When started correctly and while paused, another program claims the soundcard:

INFO:librespot::player: Track "The Old Man Down The Road" loaded
INFO:librespot::player: Loading track "The Old Man Down The Road"
INFO:librespot::player: Track "The Old Man Down The Road" loaded
Expression 'ret' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1736
Expression 'AlsaOpen( &alsaApi->baseHostApiRep, params, streamDir, &self->pcm )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1904
Expression 'PaAlsaStreamComponent_Initialize( &self->playback, alsaApi, outParams, StreamDirection_Out, NULL != callback )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 2175
Expression 'PaAlsaStream_Initialize( stream, alsaHostApi, inputParameters, outputParameters, sampleRate, framesPerBuffer, callback, streamFlags, userData )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 2840
thread '' panicked at 'called Result::unwrap() on an Err value: Device unavailable', /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/result.rs:868
note: Run with RUST_BACKTRACE=1 for a backtrace.
thread 'main' panicked at 'called Result::unwrap() on an Err value: "SendError(..)"', /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/result.rs:868

on another occasion, starting librespot while device already claimed:

thread '' panicked at 'Could not find device', /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/option.rs:715
note: Run with RUST_BACKTRACE=1 for a backtrace.

Shuffle buttons don't work on some clients.

Issue by mfeif
Wednesday May 11, 2016 at 18:05 GMT
Originally opened as plietar/librespot#82


When using librespot, I've noticed that I can't engage shuffle mode (or if it was previously engaged, I can't disengage it). This happens on Android clients, but not on the client on my Mac.

From the console on the machine running librespot, I see this:

This works:

DEBUG:librespot::spirc: kMessageTypeShuffle "Matt\u{2019}s MBP" 1076ca47615d400613f2e0ba4aec7d48bf1e1fc1 9 0

These don't:

DEBUG:librespot::spirc: kMessageTypeShuffle "XT1053" e74c24f49d31184d2f2c53e504287b7b82836758 9 0
DEBUG:librespot::spirc: kMessageTypeShuffle "Nexus 7" 09edc29adab512c4fcbb7b3975af126d7cad45c8 4 0

By "works" I should say that there is no feedback in the client. And it doesn't seem to "work" in that turning on shuffle in the android client doesn't show the state change in the Mac client.

It may also happen with the repeat feature.

This reminds me of a situation with a previous build, where the status of the player couldn't keep track of the time... when launching a client, it would start the playback time at 0:00, no matter what the actual playing was. Perhaps it's related? Something about parsing a heartbeat/status chunk?

Thanks

Discovery mode interferes with system DNS configuration

Issue by kcning
Tuesday Apr 25, 2017 at 11:02 GMT
Originally opened as plietar/librespot#178


Hi, I can't launch librespot because of dns resolve failure. Below is the error msg.
update: backtrace with debug info.

> RUST_BACKTRACE=1 target/debug/librespot --name dummy -u $USERNAME
INFO:librespot: librespot d95c0b3 (2017-04-13). Built on 2017-04-25.
Password for $USERNAME: 
WARN:librespot::apresolve: Failed to resolve Access Point: HTTP error
WARN:librespot::apresolve: Using fallback "ap.spotify.com:80"
INFO:librespot::session: Connecting to AP "ap.spotify.com:80"
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Custom(Custom { kind: Other, error: StringError("failed to lookup address information: Name or service not known") }) }', src/libcore/result.rs:868
stack backtrace:
   1:     0x55abe90f4fcc - std::sys::imp::backtrace::tracing::imp::write::h0263459999f7f6d4
   2:     0x55abe90f9fde - std::panicking::default_hook::{{closure}}::hfb43d85657ad3a4c
   3:     0x55abe90f9bda - std::panicking::default_hook::h2f5648e30de6b0b9
   4:     0x55abe90fa47b - std::panicking::rust_panic_with_hook::h9f3930ca8cee8a65
   5:     0x55abe90fa314 - std::panicking::begin_panic::hbe2663b4713ef886
   6:     0x55abe90fa239 - std::panicking::begin_panic_fmt::h6073f869f9b775fa
   7:     0x55abe90fa1c7 - rust_begin_unwind
   8:     0x55abe9145bed - core::panicking::panic_fmt::hc8432e9fe5639d04
   9:     0x55abe86a1702 - core::result::unwrap_failed::h5fbb3a08baa7f504
                        at /build/rust/src/rustc-1.16.0-src/src/libcore/macros.rs:29
  10:     0x55abe8655eb5 - <core::result::Result<T, E>>::unwrap::h2768ec1d3ab2ca21
                        at /build/rust/src/rustc-1.16.0-src/src/libcore/result.rs:745
  11:     0x55abe87df099 - librespot::connection::connect::h5067261cf9d99380
                        at /home/kcning/aur/librespot-git/src/librespot/src/lib.rs:70
  12:     0x55abe87cc2f8 - librespot::session::Session::connect::{{closure}}::h0a07c03a72a48a09
                        at /home/kcning/aur/librespot-git/src/librespot/src/session.rs:97
  13:     0x55abe859ae5c - <futures::future::and_then::AndThen<A, B, F> as futures::future::Future>::poll::{{closure}}::{{closure}}::hdb3830a9aeeacd30
                        at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/future/and_then.rs:33
  14:     0x55abe86492bc - <core::result::Result<T, E>>::map::h19ed940fdfb2bc33
                        at /build/rust/src/rustc-1.16.0-src/src/libcore/result.rs:465
  15:     0x55abe859a0c2 - <futures::future::and_then::AndThen<A, B, F> as futures::future::Future>::poll::{{closure}}::hffdfe43ed78d0e72
                        at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/future/and_then.rs:32
  16:     0x55abe870281f - <futures::future::chain::Chain<A, B, C>>::poll::h85c018433a68c8ca
                        at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/future/chain.rs:38
  17:     0x55abe8598ffb - <futures::future::and_then::AndThen<A, B, F> as futures::future::Future>::poll::hbd89929e36d16ed7
                        at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/future/and_then.rs:31
  18:     0x55abe8706029 - <futures::future::chain::Chain<A, B, C>>::poll::hc116a2325d4863f3
                        at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/future/chain.rs:25
  19:     0x55abe859913b - <futures::future::and_then::AndThen<A, B, F> as futures::future::Future>::poll::he4e9dcadb2f662a4
                        at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/future/and_then.rs:31
  20:     0x55abe87831ef - <futures::future::map::Map<A, F> as futures::future::Future>::poll::h49ff34c4d0b2e7c6
                        at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/future/map.rs:29
  21:     0x55abe857f2c0 - <alloc::boxed::Box<F> as futures::future::Future>::poll::hc3476db098324739
                        at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/future/mod.rs:104
  22:     0x55abe85906a8 - <librespot::Main as futures::future::Future>::poll::h0ff13c6db242c9e7
                        at /home/kcning/aur/librespot-git/src/librespot/src/main.rs:248
  23:     0x55abe854f7cc - <futures::task_impl::Spawn<F>>::poll_future::{{closure}}::h22d943f66342f469
                        at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/task_impl/mod.rs:311
  24:     0x55abe854f9fe - <futures::task_impl::Spawn<T>>::enter::{{closure}}::h69e10c8bee91c828
                        at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/task_impl/mod.rs:398
  25:     0x55abe85838cf - futures::task_impl::set::{{closure}}::ha22710dc29c990a1
                        at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/task_impl/mod.rs:50
  26:     0x55abe85561b5 - <std::thread::local::LocalKey<T>>::with::hd4e87ccf21a65c1f
                        at /build/rust/src/rustc-1.16.0-src/src/libstd/thread/local.rs:253
  27:     0x55abe85837ba - futures::task_impl::set::ha5863bcee66741b8
                        at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/task_impl/mod.rs:47
  28:     0x55abe854f912 - <futures::task_impl::Spawn<T>>::enter::hf638d413c2acf206
                        at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/task_impl/mod.rs:398
  29:     0x55abe854f76a - <futures::task_impl::Spawn<F>>::poll_future::hfc0a8c7fd581b0eb
                        at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/task_impl/mod.rs:311
  30:     0x55abe853c87e - tokio_core::reactor::Core::run::{{closure}}::hb121544ca881591c
                        at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-core-0.1.4/src/reactor/mod.rs:231
  31:     0x55abe8549b74 - <scoped_tls::ScopedKey<T>>::set::h50d3deded1ff8c8c
                        at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped-tls-0.1.0/src/lib.rs:135
  32:     0x55abe853c4ff - tokio_core::reactor::Core::run::h66fd7a71a0f0f3e4
                        at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-core-0.1.4/src/reactor/mod.rs:230
  33:     0x55abe8591647 - librespot::main::h58bbb806c9a048c8
                        at /home/kcning/aur/librespot-git/src/librespot/src/main.rs:311
  34:     0x55abe91013fa - __rust_maybe_catch_panic
  35:     0x55abe90fabe6 - std::rt::lang_start::h1c5729a586411154
  36:     0x55abe85919b2 - main
  37:     0x7fb0d6837510 - __libc_start_main
  38:     0x55abe853c059 - _start
  39:                0x0 - <unknown>

I have dnscrypt and dnsmasq set up. dnsmasq binds to 127.0.0.1:53, which queries dnscrypt in case the address is not known. I have noticed that, when launching librespot,
I can't resolve any address (system-wide).

> RUST_BACKTRACE=1 librespot --name dummy                 
INFO:librespot: librespot d95c0b3 (2017-04-13). Built on 2017-04-25.
WARN:mdns::fsm: couldn't parse packet from V4(127.0.0.1:63410): packet has non-zero reserved bits

> dig www.google.com

It seems like all the dns resolves are intercepted by librespot. Is this normal? And is there a way to fix this?

ALSA: support selection of ALSA mixer - for (hardware-based) volume control

Issue by arigit
Thursday Jan 05, 2017 at 04:29 GMT
Originally opened as plietar/librespot#140


Some DAC cards support hardware-based volume control. Example: HiFiBerry DAC+ pro on Raspberry.
Using librespot (v20161230-7fd8503) from: https://github.com/herrernst/librespot/releases

On raspberry pi + OSMC (raspbian) + above mentioned DAC. Works very well out of the box.

Running the client with:

/home/osmc/librespot/librespot --name Raspberry --cache /tmp --bitrate 320 --backend alsa --device hw:0

I notice using alsamixer and librespot in verbose mode that changing that volume changes in the client causes some events in librespot,

DEBUG:librespot::spirc: kMessageTypeVolume ...
...

the audio volume does change, increase/decrease, however alsamixer doesn't show any actual mixer volume change at all in any of its mixers, which seems to indicate that the volume change is done by librespot itself as a "software volume change". Higher end DACs can control volume via hardware which is preferable. In the case of the HiFiBerry DAC pro, the Alsa mixer is called "Digital" (shows up as one of the mixers displayed by the "alsamixer" tool)

When using spotify-connect-web, running it as:

spotify-connect-web --key /home/your-user/your-key.key --name Raspberry --bitrate 320 --playback_device hw:0 --mixer Digital

...any volume change in the spotify client causes the alsamixer "Digital" mixer to reflect the change (value between 100 and 0), which indicates that the volume change is being done via hardware. Note that spotify-connect-web also supports "software-based volume control" if desired

Support for Spotify Radio/Dynamic Playlists (Context Support)

Issue by arigit
Friday May 12, 2017 at 16:48 GMT
Originally opened as plietar/librespot#184


Since forever I've noticed that when playing spotify Radio (launching it from an official spotify android client or from a linux client), librespot will play about ten songs and then it will restart from the first song, instead of continuing to pull new songs to play from the "dynamic playlist".

This indeed seems to be a librespot problem with dynamic playlists (that keep adding content forever). If one plays the media locally, then the client continues adding new content to the dynamic playlist and never repeats a song.

There is a long issue thread in spotify's support site, people complaining that their SpotifyConnect speakers will behave as described above. However, recently spotify people advised that this is not an issue with the Spotify Client, but an issue with very old firmware in the SpotifyConnect / speakers i.e. librespot.

Here's the thread.

https://community.spotify.com/t5/Ongoing-Issues/Radio-not-loading-more-songs-when-using-Spotify-Connect/idc-p/1673495#M42870

Hereby the request to have librespot support spotify's dynamic playlists including Radio

Metadata

Damn nice initiative 👍

One area we would need to look at is metadata, a lot of forks is due to the need to integrate this and we should put down some standard way to do it.

This includes two parts, what tags to use (ex Vorbis) and how to deliver it to the rest of the world as in encoding (json, xml, ...) and transport (stderr/stdout, pipe, tcp, ucp...)

This could/would also imply changes to the audio adapter API, ex to have metadata available for pulseaudio properties.

unwraps in network code

Issue by crepererum
Saturday Nov 12, 2016 at 17:32 GMT
Originally opened as plietar/librespot#127


The network-related code (e.g. in session.rs) uses unwrap, even in places where failure is kinda likely. For example:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: IoError(Error { repr: Os { code: 104, message: "Connection reset by peer" } })', /buil
dslave/rust-buildbot/slave/stable-dist-rustc-cross-host-linux/build/src/libcore/result.rs:799
stack backtrace:
   1:       0x557f3db8d3 - std::sys::backtrace::tracing::imp::write::hd28a1f8221c946e5
   2:       0x557f3dfd9b - std::panicking::default_hook::{{closure}}::hcb904beb56706ec8
   3:       0x557f3de75b - std::panicking::default_hook::hd59cb475a55dc643
   4:       0x557f3dedcf - std::panicking::rust_panic_with_hook::hea2bde53d708eb9a
   5:       ne557f3dec9b - std::panicking::begin_panic::hc4949303f890336e
   6:       0x557f3debeb - std::panicking::begin_panic_fmt::he756d57ad1c1864c
   7:       0x557f3deb8b - rust_begin_unwind
   8:       0x557f40825b - core::panicking::panic_fmt::ha615cb8b8c64841b
   9:       0x557f1a9123 - core::result::unwrap_failed::hf088160fd5523cfd
  10:       0x557f1f211b - librespot::session::Session::recv::h1029c0727cfdd2f5
  11:       0x557f1f1bb7 - librespot::session::Session::poll::h8d6b905a3d50b9e1
  12:       0x557f16f5db - librespot::main::ha3ae70879a6a6aa7
  13:       0x557f3e512f - __rust_maybe_catch_panic
  14:       0x557f3ddedb - std::rt::lang_start::hcb77440d8735d978
  15:       0x7fa1c4a363 - __libc_start_main
  2::       0x557f167363 - <unknown>

Connection resets are a normal thing, esp. in Wifi-environments. So the recv method should probably return a Result-type instead and the layer above (poll) should handle failed connection attempts, e.g. by reconnect/retry.

Implement some sort of State handler with some sort of RO-API

Issue by psych0d0g
Thursday Jan 14, 2016 at 14:41 GMT
Originally opened as plietar/librespot#37


Is there a way to notice when a device connects / disconnects?
and could we supply some kind of state file for tracking?
what i have in mind is another argument to enable that feature and if enabled create a file where librespot writes the current state (like the proc file system on linux just a single line which gets updated on state changes)
example content of that file:

Device connects:
"connected"

Device disconnects:
"noendpoint"

Device disconnects and no music playing or end of playlist:
"noendpointnotplaying"

Crash after 3-5 Songs

Issue by Zwackelmann
Tuesday Apr 25, 2017 at 06:19 GMT
Originally opened as plietar/librespot#177


I am aware of a similar recent post, but since the stack trace differs and the solution (uninstall pulseaudio) did not work for me, I opened a new issue.

I am using the latest version of the code, a fresh rust environment and I can reproduce the stack trace below when compiling on armv7 (PI3) or on my x86_64 laptop (without cross compilation).

Looking at the code, I think there might be an error in the task defined in session.rs:111 (Perhaps just some error handling missing?).

I am totally new to Rust, but I will inform you if I find a solution.

    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/librespot --name Baz --username xxx --password xxx --backend alsa --bitrate 320`
INFO:librespot: librespot d95c0b3 (2017-04-13). Built on 2017-04-23.
INFO:librespot::session: Connecting to AP "lon6-accesspoint-a3.ap.spotify.com:4070"
INFO:librespot::session: Authenticated as "xxx" !
INFO:librespot::audio_backend::alsa: Using alsa sink
INFO:librespot::player: Loading track "Civilization (Bongo, Bongo, Bongo) - Single Version"
ERROR:librespot::player: Vorbis error: InitialFileHeadersCorrupt
INFO:librespot::player: Track "Civilisation (Bongo Bongo Bongo)" loaded
INFO:librespot::player: Loading track "The Planets H125 (Op. 32) (1998 Digital Remaster): Mars, the Bringer of War"
INFO:librespot::player: Track "The Planets H125 (Op. 32) (1998 Digital Remaster): Mars, the Bringer of War" loaded
thread 'main' panicked at 'Box<Any>', src/session.rs:115
stack backtrace:
   1:     0x55836b2e59bc - std::sys::imp::backtrace::tracing::imp::write::hf33ae72d0baa11ed
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:42
   2:     0x55836b2ea95e - std::panicking::default_hook::{{closure}}::h59672b733cc6a455
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:351
   3:     0x55836b2ea564 - std::panicking::default_hook::h1670459d2f3f8843
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:367
   4:     0x55836b2eadfb - std::panicking::rust_panic_with_hook::hcf0ddb069e7beee7
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:555
   5:     0x55836a807936 - std::panicking::begin_panic::he003be6cd7878ac1
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:517
   6:     0x55836a9cf8d6 - librespot::session::Session::connect::{{closure}}::{{closure}}::h8b4b7850aecf78b0
                        at /home/simon/Projects/Private/librespot/src/session.rs:115
   7:     0x55836a85da30 - <core::result::Result<T, E>>::map_err::h0bdadb83f152a63a
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/result.rs:494
   8:     0x55836a9a0955 - <futures::future::map_err::MapErr<A, F> as futures::future::Future>::poll::hdb3b55c8ef164837
                        at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/future/map_err.rs:33
   9:     0x55836b0e4b61 - <alloc::boxed::Box<F> as futures::future::Future>::poll::h75a47098115c1923
                        at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/future/mod.rs:104
  10:     0x55836b0ce85c - <futures::task_impl::Spawn<F>>::poll_future::{{closure}}::h8a036d1d2a5f7064
                        at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/task_impl/mod.rs:311
  11:     0x55836b0cedae - <futures::task_impl::Spawn<T>>::enter::{{closure}}::hc65976fe9d0cdac7
                        at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/task_impl/mod.rs:398
  12:     0x55836b0e6fbf - futures::task_impl::set::{{closure}}::h41256dd0de71bb00
                        at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/task_impl/mod.rs:50
  13:     0x55836b0d0945 - <std::thread::local::LocalKey<T>>::with::h805abbd7c45c3cfa
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/thread/local.rs:253
  14:     0x55836b0e6e0a - futures::task_impl::set::h86b291b65eb41edd
                        at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/task_impl/mod.rs:47
  15:     0x55836b0cec4c - <futures::task_impl::Spawn<T>>::enter::had2f6d26abc9b196
                        at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/task_impl/mod.rs:398
  16:     0x55836b0ce7fa - <futures::task_impl::Spawn<F>>::poll_future::h00883d40f46cbdda
                        at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/task_impl/mod.rs:311
  17:     0x55836b0f6a26 - tokio_core::reactor::Core::dispatch_task::{{closure}}::h4e80f0206ea9aca3
                        at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-core-0.1.4/src/reactor/mod.rs:352
  18:     0x55836b0cad64 - <scoped_tls::ScopedKey<T>>::set::h2c7be2a32d85991d
                        at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped-tls-0.1.0/src/lib.rs:135
  19:     0x55836b0f6492 - tokio_core::reactor::Core::dispatch_task::h2e51e248e767b3ca
                        at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-core-0.1.4/src/reactor/mod.rs:352
  20:     0x55836b0f5925 - tokio_core::reactor::Core::dispatch::hb22d8e1dce03e744
                        at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-core-0.1.4/src/reactor/mod.rs:312
  21:     0x55836b0f5489 - tokio_core::reactor::Core::poll::h4e3548a5914d9a05
                        at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-core-0.1.4/src/reactor/mod.rs:300
  22:     0x55836a71896e - tokio_core::reactor::Core::run::h1e56d30c8c50c89b
                        at /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-core-0.1.4/src/reactor/mod.rs:237
  23:     0x55836a76db67 - librespot::main::h15ec5b194b348088
                        at /home/simon/Projects/Private/librespot/src/main.rs:311
  24:     0x55836b2f1dea - __rust_maybe_catch_panic
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libpanic_unwind/lib.rs:98
  25:     0x55836b2eb566 - std::rt::lang_start::hd7c880a37a646e81
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:436
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panic.rs:361
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/rt.rs:57
  26:     0x55836a76ded2 - main
  27:     0x7f21dd1592b0 - __libc_start_main
  28:     0x55836a718319 - _start
  29:                0x0 - <unknown>

Process finished with exit code 101```

Implement IPC for 3rd party applications.

Issue by sashahilton00
Tuesday Jan 19, 2016 at 00:01 GMT
Originally opened as plietar/librespot#41


As librespot is looking to replace the libspotify_embedded libraries, it needs to be useable by external programs. The external program needs to be able to access information such as the following:

  • Current Track Metadata
  • Queue Metadata
  • Playlist Metadata
  • Current Track seek position
  • Shuffle/Repeat enabled
  • Next Track
  • Is Device Connected
  • Current Volume

I'm sure there are many more that could be implemented over time, but above are the few which seem to be fairly crucial.

N.B. PCM data is not included in the list as this issue is essentially suggesting that librespot ought to have an IPC implementation for access to various metadata.

discovery: allow setting port explicitly

Issue by florolf
Monday Mar 27, 2017 at 19:13 GMT
Originally opened as plietar/librespot#169


Allow the user to specify the port used for the discovery service
manually, instead of it being chosen by the operating system.

This is useful when using an external mDNS responder, for example in a
setup where the clients and the librespot installation live in different
broadcast domains.


florolf included the following code: https://github.com/plietar/librespot/pull/169/commits

Last ~10 seconds of each track not played

Issue by jsopenrb
Tuesday Apr 18, 2017 at 16:59 GMT
Originally opened as plietar/librespot#175


Right before the end of each track, the controlling device is sending Load command which makes the player jump right to the next track without waiting for the current track to finish. This happens when controlling from both Android and Windows.

Panic with message "No space left on device"

Issue by joerg-krause
Friday Mar 17, 2017 at 09:51 GMT
Originally opened as plietar/librespot#166


When playling long tracks on my embedded device with about 36MB of free RAM, librespot panics with: thread 'main' panicked at 'called Result::unwrap()on anErr value: Error { repr: Os { code: 28, message: "No space left on device" } }'.

For example using this track (45:31). Is there a way not to load the whole song into RAM?

librespot and firewall ports

Issue by giannello
Tuesday Jul 05, 2016 at 17:17 GMT
Originally opened as plietar/librespot#89


My laptop/mobile phone and my raspberrypi are connected to separate subnets.
After starting librespot I can see that the entries are published via mdns

user@host:~$ avahi-browse --all --resolve
+ wlp3s0 IPv6 raspberrypi                                   _spotify-connect._tcp local
+ wlp3s0 IPv4 raspberrypi                                   _spotify-connect._tcp local
= wlp3s0 IPv4 raspberrypi                                   _spotify-connect._tcp local
   hostname = [raspberrypi.local]
   address = [XXX.XXX.XXX.XXX]
   port = [38143]
   txt = ["CPath=/" "VERSION=1.0"]

If I try to connect from my laptop to XXX.XXX.XXX.XXX:38143 I get a 404, and in the console where librespot is running I can see the message

DEBUG:librespot::authentication::discovery: Get "/" {}

When I start Spotify, I can't see the librespot device name in the list of available Spotify Connect devices.

The firewall rules allow hosts in the LAN to connect to every tcp/udp port of all the devices in the network with the raspberrypi, but not the other way around. Is there any communication happening from librespot to the spotify app that requires ports to be opened?

Limit cache size

Issue by giannello
Friday Jul 29, 2016 at 19:50 GMT
Originally opened as plietar/librespot#105


For people running librespot on hardware with limited resources, it would be nice to have an option to limit the cache size.

thread 'main' panicked at 'Box<Any>', src/session.rs:115

Issue by joerg-krause
Saturday Mar 04, 2017 at 09:05 GMT
Originally opened as plietar/librespot#156


Running the latest master works great so far! Yesterday, I set up a playlist in the Spotify App lo be played in a loop and selected the librespot client as audio sink. When I woke up today, the librespot client died:

DEBUG:librespot::audio_file: File 774f64e3c9690d01ecad1a35ed0bde12d978dfae complete
DEBUG:librespot::session: Session[0] strong=3 weak=6
DEBUG:librespot::player: command=Load(SpotifyId(u128 { high: 8492558088775026015, low: 11919394522851906758 }), true, 0)
DEBUG:librespot::session: drop Dispatch
thread 'main' panicked at 'Box<Any>', src/session.rs:115

Use pulseaudio native volume management

Issue by paradis
Tuesday Apr 19, 2016 at 18:44 GMT
Originally opened as plietar/librespot#75


Hello,

When using pulseaudio backend it would be nice to delegate volume management to pulse audio sink. Besides having a logarithmic scale natively, it would also allow to manage librespot volume in one place and avoid several volume alteration (librespot, pulseaudio sink, pulseaudio output).

However, it would be necessary to move volume management from the player to the audio_backend.

What do you think?

ALSA lib pcm.c:8382:(snd_pcm_set_params) Sample format not available for PLAYBACK: Invalid argument

Issue by archphile
Saturday Mar 11, 2017 at 09:44 GMT
Originally opened as plietar/librespot#162


Hi,

I built librespot with alsa backend on Archlinuxarm:

https://aur.archlinux.org/packages/librespot-alsa-git/

When I try to start librespot with the following command:

librespot --cache /var/cache/librespot --name Test --bitrate 320 --username xxxxxx --password xxxxxx

I get the following error:

ALSA lib pcm.c:8382:(snd_pcm_set_params) Sample format not available for PLAYBACK: Invalid argument
thread '' panicked at 'called Option::unwrap() on a None value', src/libcore/option.rs:323
note: Run with RUST_BACKTRACE=1 for a backtrace.

Any help is highly appreciated.

Many thanks,

Michael

Gapless playback

With all the new progress on the Librespot front, I'd thought i'd point this out once again.
It would still be nice to have gapless playback available.
I know it has been requiested before
plietar/librespot#18

But was there ever any progress on this?

Cheers, and happy listening!

Volume issues

Issue by moodeaudio
Monday Jan 30, 2017 at 01:16 GMT
Originally opened as plietar/librespot#150


Hi,

Testing with Spotify IOS app on iPhone 5 and librespot on Pi.

sudo ./librespot --name RP3spot --cache /tmp --bitrate 320 --backend alsa --device hw:0

What I experienced is as follows:

  1. Spotify IOS client set volume to 100% on first connect/play! iPhone local volume was only 30%. See attached image.
  2. Volume stepping used by Spotify IOS client is very corse, only 10 steps to full volume using the physical iPhone buttons.
  3. The slider volume control within the Spotify app behaves similarly in that it raises volume too much within the first half of the slider.
  4. No support for hardware volume yet in librespot (already covered in existing issue)

The very nice debug logging shows volume cmds being received but how to decode them to see what level the client is requesting?

DEBUG:librespot::spirc: kMessageTypeVolume "Tim's iPhone" 3496dcfbf06e2b19c74d6d5216389761aa9a4e94 4 0
DEBUG:librespot::spirc: kMessageTypeNotify "RP3spot" 8ced8e4318e14e95632409ed1898989ff295f075 10 1485738325625
DEBUG:librespot::spirc: kMessageTypeVolume "Tim's iPhone" 3496dcfbf06e2b19c74d6d5216389761aa9a4e94 5 0
DEBUG:librespot::spirc: kMessageTypeNotify "RP3spot" 8ced8e4318e14e95632409ed1898989ff295f075 11 1485738326177
DEBUG:librespot::spirc: kMessageTypeVolume "Tim's iPhone" 3496dcfbf06e2b19c74d6d5216389761aa9a4e94 6 0
DEBUG:librespot::spirc: kMessageTypeNotify "RP3spot" 8ced8e4318e14e95632409ed1898989ff295f075 12 1485738326424

spotify-connect1

Regards,
Tim

add gstreamer as audio backend

Issue by psych0d0g
Sunday Mar 13, 2016 at 22:14 GMT
Originally opened as plietar/librespot#60


https://github.com/arturoc/gstreamer1.0-rs

Since portaudio has some bugs on mipsel i would like to request the addition of gstreamer,

Pros:
LGPL lib.
X-Platform: Linux, Android, Windows, Max OS X, iOS, as well as most BSDs, commercial Unixes, Solaris, and Symbian
X-Architecture: x86, ARM, MIPS, SPARC and PowerPC, on 32-bit as well as 64-bit, and little endian or big endian
Complete debugging system for both core and plugin/app developers

List of applications gstreamer is used in:
https://gstreamer.freedesktop.org/apps/

And now: Open for discussion :)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.