plietar/librespot

Open Source Spotify client library

librespot

librespot is an open source client library for Spotify. It enables applications to use Spotify's service, without using the official but closed-source libspotify. Additionally, it will provide extra features which are not available in the official library.

Note: librespot only works with Spotify Premium.

Unmaintained

Unfortunately I am unable to maintain librespot anymore. It should still work, but issues and Pull requests will be ignored. Feel free to fork it and continue development there. If a fork gains traction I will happily point to it from the README.

Building

Rust 1.17.0 or later is required to build librespot.

If you are building librespot on macOS, the homebrew provided rust may fail due to the way in which homebrew installs rust. In this case, uninstall the homebrew version of rust and use rustup, and librespot should then build.

It also requires a C, with portaudio.

On debian / ubuntu, the following command will install these dependencies :

sudo apt-get install build-essential portaudio19-dev

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

sudo dnf install portaudio-devel make gcc

On macOS, using homebrew :

brew install portaudio

Once you've cloned this repository you can build librespot using cargo.

cargo build --release

Usage

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

target/release/librespot --username USERNAME --cache CACHEDIR --name DEVICENAME

Discovery mode

librespot can be run in discovery mode, in which case no password is required at startup. For that, simply omit the --username argument.

Audio Backends

librespot supports various audio backends. Multiple backends can be enabled at compile time by enabling the corresponding cargo feature. By default, only PortAudio is enabled.

A specific backend can selected at runtime using the --backend switch.

cargo build --features portaudio-backend
target/release/librespot [...] --backend portaudio

The following backends are currently available :

• ALSA
• PortAudio
• PulseAudio

Cross-compiling

A cross compilation environment is provided as a docker image. Build the image from the root of the project with the following command :

$ docker build -t librespot-cross -f contrib/Dockerfile .

The resulting image can be used to build librespot for linux x86_64, armhf (compatible e. g. with Raspberry Pi 2 or 3, but not with Raspberry Pi 1 or Zero) and armel. The compiled binaries will be located in /tmp/librespot-build

docker run -v /tmp/librespot-build:/build librespot-cross

If only one architecture is desired, cargo can be invoked directly with the appropriate options :

docker run -v /tmp/librespot-build:/build librespot-cross cargo build --release --no-default-features --features alsa-backend
docker run -v /tmp/librespot-build:/build librespot-cross cargo build --release --target arm-unknown-linux-gnueabihf --no-default-features --features alsa-backend
docker run -v /tmp/librespot-build:/build librespot-cross cargo build --release --target arm-unknown-linux-gnueabi --no-default-features --features alsa-backend

Don't forget to set the with-tremor feature flag if your target device does not have floating-point capabilities.

Development

When developing librespot, it is preferable to use Rust nightly, and build it using the following :

cargo build --no-default-features --features "nightly portaudio-backend"

This produces better compilation error messages than with the default configuration.

Disclaimer

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

Contact

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

License

Everything in this repository is licensed under the MIT license.

librespot's Issues

Error: assertion "_dbus_check_is_valid_utf8 (*string_p)" failed in file ../../dbus/dbus-message.c

When running the Spotify Connect example target/debug/librespot --appkey spotify_appkey.key --cache tmp --name pi the following error appears

process 17124: arguments to dbus_message_iter_append_basic() were incorrect, assertion "_dbus_check_is_valid_utf8 (*string_p)" failed in file ../../dbus/dbus-message.c line 2676.
This is normally a bug in some application using the D-Bus library.
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: DNSError(NoMemory)', ../src/libcore/result.rs:746
note: Run with `RUST_BACKTRACE=1` for a backtrace.

The following errors are showing when I activate the backtrace

   1: 0x54f1a433 - sys::backtrace::tracing::imp::write::h12167fd87c4444bfCwu
   2: 0x54f1ce17 - panicking::default_handler::_$u7b$$u7b$closure$u7d$$u7d$::closure.43431
   3: 0x54f1c99b - panicking::default_handler::h9f8ceb45c392442dd5y
   4: 0x54f0aa6f - sys_common::unwind::begin_unwind_inner::hf5f65b9eced8cd83rlt
   5: 0x54f0afb3 - sys_common::unwind::begin_unwind_fmt::h8fbe76036c0b1b80xkt
   6: 0x54f199fb - rust_begin_unwind
   7: 0x54f24f4f - panicking::panic_fmt::hf5513279aa3d2ea26YL
   8: 0x54c3379f - result::unwrap_failed::h11053035362580410660
                at ../src/libcore/macros.rs:29
   9: 0x54c33597 - result::Result<T, E>::unwrap::h16659752087029109074
                at ../src/libcore/result.rs:687
  10: 0x54c15733 - discovery::DiscoveryManager::run::h86f7924c19979c7fL2b
                at src/discovery.rs:121
  11: 0x54b4442b - main::h4deaf41955222e3dXba
                at src/main.rs:96
  12: 0x54f1c56b - sys_common::unwind::try::try_fn::h13484918573325342335
  13: 0x54f19993 - __rust_try
  14: 0x54f19993 - __rust_try
...
  100: 0x54f19993 - __rust_try

I have compiled librespot on my Raspberry Pi 2 using the latest Rust nightly and the latest version of librespot

Option to select Vorbis quality

By default, the lowest quality seems to be used, see generated metadata.rs:

self.format.unwrap_or(AudioFile_Format::OGG_VORBIS_96)

Add possibility (command line switch?) to use 160 or 320.

Cache metadata and audio keys

Metadata and keys should be stored in cache as well, in something like an sqlite database.

OSX: rust-gmp links to gmp but library path is missing

plietar/rust-gmp links to libgmp, which is eg. available through homebrew (as gmp), but /usr/local/lib is not in the library paths.

Other packages add library paths using pkg-config which point directly into the Cellar, but gmp doesn't ship the required pkg-config files. A workaround is to add a .cargo/config file with eg:

[target.x86_64-apple-darwin.gmp]
rustc-link-search = ["/usr/local/Cellar/gmp/6.0.0a/lib"]

Crash on startup

Hey, as one is invited to experiment with it I did so today, with mixed results. But maybe that's due to the fact that I'm trying the crazy thing on a Raspberry Pi (I want a spotify connect target on a Pi).

It took me just two days to get a working rust on the Pi but finally I was able to build librespot. My startup looks like this:

target/release/librespot --appkey ../spotify_appkey.key --username 1127156859 --password ******** --cache .tmp --name playpi
Authenticated !
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.front
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround21
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround21
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround40
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround41
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround50
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround51
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround71
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.iec958
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.iec958
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.iec958
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.hdmi
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.hdmi
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.modem
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.modem
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
kMessageTypeHello playpi 61672252dc61a1a7a07debc7ed0d17944194ceee 1 1457222331920
kMessageTypeNotify eeehal fbffcd40ab9c48f2fbf091733a0f55a8e3b3866f 6 1457203530953
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: WireError("invalid value for enum: 10")', ../src/libcore/result.rs:746
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', ../src/libcore/result.rs:746
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', ../src/libcore/result.rs:746

Then the process terminates. I can see the playpi target in a Spotify client for a short time. Neither linux audio nor rust are any of my strong sides but if I can be of any assistance here I'll try to be helpfull.

The output opens a couple of questions:

1. are unknown PCMs a bad thing?
2. what is this server socket he is trying to connect to? Is that a bad thing?
3. what is this server request channel? is it a bad thing if it can not connect?
4. I figured what jack is, but apparently I'm unable to run it (yet). But is it needed anyway?

Add support for setting audio output device name

Currently, librespot uses the default audio output device offered by portaudio. How about adding a command line option which allows the user to use a different audio device, e.g.:

librespot [..] -d "dmix"

Compile fails (in dns-sd) with misleading error messages

I'm compiling librespot from the marcust fork (I want the pulse audio stuff) on x86_64 for arm-unknown-linux-gnueabihf. (shooting for rpi1)

$ rustc -V
rustc 1.8.0-beta.2 (2879d940a 2016-03-22)

My command is this:
RUST_BACKTRACE=1; cargo build --release --features "discovery pulseaudio-backend" --target arm-unknown-linux-gnueabihf --verbose

   Compiling dns-sd v0.1.3
     Running `/home/mjf/librespot/target/release/build/dns-sd-b5325db701df81ec/build-script-build`
Build failed, waiting for other jobs to finish...
failed to run custom build command for `dns-sd v0.1.3`
Process didn't exit successfully: `/home/mjf/librespot/target/release/build/dns-sd-b5325db701df81ec/build-script-build` (exit code: 101)
--- stderr
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: "Cross compilation detected. Use PKG_CONFIG_ALLOW_CROSS=1 to override"', ../src/libcore/result.rs:746
note: Run with `RUST_BACKTRACE=1` for a backtrace.

mjf@dude:~/librespot$ echo $RUST_BACKTRACE $PKG_CONFIG_ALLOW_CROSS
1 1

So both of those env vars are set, but that's as much output as I can gather.

Thanks!

Add playlist support

Constant underflows in Raspberry 2

I just compiled the most recent version to Raspberry Pi 2.

Streaming almost works. The connection is created and streaming starts, but then there are underflows every other second. Later the frequency of underflows is slower, but the still come. The CPU is > 90% idle and my network is fast enough. The underflows kill the music with stuttering and gaps.

When starting, librespot complains about missing jack server. Is that needed?

CPU pegged while "idle"

When the PlayerInternal isn't playing, the CPU is pegged. I believe this line is the culprit. Basically, when PlayerInternal is not playing audio, the Receiver<PlayerCommand> is being constantly polled. Could PlayerInternal be refactored so Receiver.recv() is called and therefore blocks when there is no commands to change state?

(I tried doing this myself, but I'm really new to Rust and the type system with the "ownership" concept appears rather challenging to learn! I would love to learn by example... 😄)

Some songs not playing through/are hanging (missing chunks?)

Some songs (I don't know if specific ones or if happens at random) get stuck playing beneath the end. From the output, I see that the first and last (why?) chunks are loaded first, and the track is marked loaded. Then other chunks are loaded. The last one is 58 (but 59 is missing!), then nothing happens, and when playback reaches the last ~20 seconds of the song, playback is stuck and no control is possible anymore. It happend to me with the track spotify:track:5ERPZNZfMPF5j0xgEnoQoV:

Chunk 0
Chunk 1
Chunk 2
Chunk 61
Chunk 3
Chunk 60
Chunk 4
Load Done
Chunk 5
Chunk 6
Chunk 7
Chunk 8
Chunk 9
Chunk 10
Chunk 11
Chunk 12
Chunk 13
Chunk 14
Chunk 15
Chunk 16
Chunk 17
Chunk 18
Chunk 19
Chunk 20
Chunk 21
Chunk 22
Chunk 23
Chunk 24
Chunk 25
Chunk 26
Chunk 27
Chunk 28
Chunk 29
Chunk 30
Chunk 31
Chunk 32
Chunk 33
Chunk 34
Chunk 35
Chunk 36
Chunk 37
Chunk 38
Chunk 39
Chunk 40
Chunk 41
Chunk 42
Chunk 43
Chunk 44
Chunk 45
Chunk 46
Chunk 47
Chunk 48
Chunk 49
Chunk 50
Chunk 51
Chunk 52
Chunk 53
Chunk 54
Chunk 55
Chunk 56
Chunk 57
Chunk 58
^C

(Chunk 60 and 61 are loaded at the beginning, 59 is missing)

If it matters, I build with latest Rust nightly (b4707ebca 2015-12-27) on Linux x64 with one maybe troublesome warning:

src/player.rs:219:9: 219:22 warning: unreachable statement, #[warn(unreachable_code)] on by default
src/player.rs:219         drop(stream);
                          ^~~~~~~~~~~~~

Thank you!

Add alsa as audio backend

The portaudio backend results in heavy CPU load on embedded Linux systems. There already exists a branch with a very basic alsa backend. As a first test showed that on an ARMv5 board the CPU load was reduced from about 80% with portaudio to about 25% with alsa I would really like to see the alsa backend as default or optional backend for any Linux system.

So, what has to be done?

add gstreamer as audio backend

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 :)

Problem with device discovery

I build librespot with discovery support both for my x64 Linux desktop as well as for an ARMv5 embedded device. Both instances run and I get the log message [("action", "getInfo")]. However, only the desktop is discovered by the Spotify app whereas the embedded device does not show up. I compared the packets with wireshark, but I cannot see any difference.

I finally traced the communication with tcpdump. Both logs dumps show in- and outgoing traffic. However, only the desktop device is listed in the Spotify app.

What I've noticed so far is that the HTTP response send by librespot differs: the embedded device has no date string and the "status" field in the JSON string is 100 instead of 101.

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

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"

Unable to Build

Hi,

I'm on an Ubuntu 14.10 x64 box. Building this project seems to fail. I'm afraid I'm a bit of a Rust noob but happy to dig if you're able to give me some pointers. This is the output I'm getting at the moment from sudo rust build --verbose...

➜  librespot git:(master) sudo cargo build --verbose
[sudo] password for bencevans: 
   Compiling rustc-serialize v0.3.18
     Running `rustc /home/bencevans/.cargo/registry/src/github.com-88ac128001ac3a9a/rustc-serialize-0.3.18/src/lib.rs --crate-name rustc_serialize --crate-type lib -g -C metadata=79a17eda1cd94e46 -C extra-filename=-79a17eda1cd94e46 --out-dir /home/bencevans/Code/librespot/target/debug/deps --emit=dep-info,link -L dependency=/home/bencevans/Code/librespot/target/debug/deps -L dependency=/home/bencevans/Code/librespot/target/debug/deps --cap-lints allow`
   Compiling gcc v0.3.24
     Running `rustc /home/bencevans/.cargo/registry/src/github.com-88ac128001ac3a9a/gcc-0.3.24/src/lib.rs --crate-name gcc --crate-type lib -g -C metadata=5002d5e6be584e6e -C extra-filename=-5002d5e6be584e6e --out-dir /home/bencevans/Code/librespot/target/debug/deps --emit=dep-info,link -L dependency=/home/bencevans/Code/librespot/target/debug/deps -L dependency=/home/bencevans/Code/librespot/target/debug/deps --cap-lints allow`
       Fresh ascii v0.5.4
   Compiling pkg-config v0.3.7
     Running `rustc /home/bencevans/.cargo/registry/src/github.com-88ac128001ac3a9a/pkg-config-0.3.7/src/lib.rs --crate-name pkg_config --crate-type lib -g -C metadata=2507e318f8e010c2 -C extra-filename=-2507e318f8e010c2 --out-dir /home/bencevans/Code/librespot/target/debug/deps --emit=dep-info,link -L dependency=/home/bencevans/Code/librespot/target/debug/deps -L dependency=/home/bencevans/Code/librespot/target/debug/deps --cap-lints allow`
       Fresh libc v0.1.12
   Compiling bit-vec v0.4.3
     Running `rustc /home/bencevans/.cargo/registry/src/github.com-88ac128001ac3a9a/bit-vec-0.4.3/src/lib.rs --crate-name bit_vec --crate-type lib -g -C metadata=4ae2314927a79fef -C extra-filename=-4ae2314927a79fef --out-dir /home/bencevans/Code/librespot/target/debug/deps --emit=dep-info,link -L dependency=/home/bencevans/Code/librespot/target/debug/deps -L dependency=/home/bencevans/Code/librespot/target/debug/deps --cap-lints allow`
       Fresh encoding_index_tests v0.1.4
       Fresh encoding-index-singlebyte v1.20141219.5
       Fresh encoding-index-japanese v1.20141219.5
       Fresh encoding-index-simpchinese v1.20141219.5
       Fresh encoding-index-korean v1.20141219.5
       Fresh getopts v0.2.14
       Fresh lazy_static v0.1.15
   Compiling protobuf_macros v0.1.2 (https://github.com/plietar/rust-protobuf-macros.git#37c6a34e)
     Running `rustc /home/bencevans/.cargo/git/checkouts/rust-protobuf-macros-0155ebac4efea846/master/src/lib.rs --crate-name protobuf_macros --crate-type dylib -C prefer-dynamic -g -C metadata=10fbf04e2f39f8e7 -C extra-filename=-10fbf04e2f39f8e7 --out-dir /home/bencevans/Code/librespot/target/debug/deps --emit=dep-info,link -L dependency=/home/bencevans/Code/librespot/target/debug/deps -L dependency=/home/bencevans/Code/librespot/target/debug/deps --cap-lints allow`
/home/bencevans/.cargo/git/checkouts/rust-protobuf-macros-0155ebac4efea846/master/src/lib.rs:1:1: 1:45 error: #[feature] may not be used on the stable release channel
/home/bencevans/.cargo/git/checkouts/rust-protobuf-macros-0155ebac4efea846/master/src/lib.rs:1 #![feature(plugin_registrar, rustc_private)]
                                                                                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/bencevans/.cargo/git/checkouts/rust-protobuf-macros-0155ebac4efea846/master/src/lib.rs:2:1: 2:28 error: #[feature] may not be used on the stable release channel
/home/bencevans/.cargo/git/checkouts/rust-protobuf-macros-0155ebac4efea846/master/src/lib.rs:2 #![feature(slice_patterns)]
                                                                                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to 2 previous errors
Build failed, waiting for other jobs to finish...
Could not compile `protobuf_macros`.

Caused by:
  Process didn't exit successfully: `rustc /home/bencevans/.cargo/git/checkouts/rust-protobuf-macros-0155ebac4efea846/master/src/lib.rs --crate-name protobuf_macros --crate-type dylib -C prefer-dynamic -g -C metadata=10fbf04e2f39f8e7 -C extra-filename=-10fbf04e2f39f8e7 --out-dir /home/bencevans/Code/librespot/target/debug/deps --emit=dep-info,link -L dependency=/home/bencevans/Code/librespot/target/debug/deps -L dependency=/home/bencevans/Code/librespot/target/debug/deps --cap-lints allow` (exit code: 101)

Crashes after some songs

So I managed to get librespot running in Raspberry Pi 2 by compiling it as release.
Unfortunately it is not stable. It works a while, but then crashes with the following.

This is taken from syslog. I made a systemd service, which is run with an ordinary user account, not as root. This happens always after some songs.

This is the command line:

/home/pi/librespot/target/release/librespot --appkey /home/pi/librespot/spotify_appkey.key --cache /home/pi/librespot/cache --name xxx --bitrate 320

From syslog:

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:330
note: Run with `RUST_BACKTRACE=1` for a backtrace.
kMessageTypePlay xxxxxxxx b527ab9df45660f863a92a5ca0f34be1284c3356 3 0
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', ../src/libcore/result.rs:746
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', ../src/libcore/result.rs:746

HiFiBerry / ALSA errors

Trying to use librespot with HiFiBerry, on OSMC; audio on HiFiBerry DAC works perfect on OSMC/Kodi

Using the latest binary package from here: https://github.com/herrernst/librespot/releases

When launching librespot, I authentication works but then I get a bunch of ALSA errors, can spotify clients are unable to see the Raspberry

./librespot --name Raspberry --bitrate 320 --username YOURUSERNAME --password YOURPASSOWORD --appkey /home/osmc/spotify-connect/spotify_appkey.key --cache /tmp
Authenticated !
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.front
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround21
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround21
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround40
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround41
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround50
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround51
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround71
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.iec958
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.iec958
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.iec958
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.hdmi
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.hdmi
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.modem
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.modem
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline
ALSA lib pcm_direct.c:896:(snd1_pcm_direct_initialize_slave) slave plugin does not support mmap interleaved or mmap noninterleaved access
ALSA lib pcm_dmix.c:1034:(snd_pcm_dmix_open) unable to initialize slave
kMessageTypeHello Raspberry b7870749a82019bec25fcc2db279951e62cdbd42 1 1457572877310

The output of aplay -l is:

aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sndrpihifiberry [snd_rpi_hifiberry_dacplus], device 0: HiFiBerry DAC+ Pro HiFi pcm512x-hifi-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0

Add support for Facebook based login

Building with stable rust

Since librespot was started rust has stabilized a lot of stuff. As a result where lots of unstable features were required before, only zero_one, iter_arith, and plugin are needed now.

The first two are trivial to work around.
The last one not so much. The two plugins used are json_macros, which could easily be avoided, and protobuf_macros which is used a lot and would be a pain to get rid, both in terms of work and readability.

syntex would be a potential solution to this.

Example client does not quit on authentication error

If I enter a wrong password...

Password:
Authentication failed
thread '' panicked at 'called Result::unwrap() on an Err value: Other', ../src/libcore\result.rs:688

the example client keeps running. It should either ask for the password again, or quit - it's useless in the failed state.

Shuffle buttons don't work on some clients.

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

Building on Windows

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?

Close stream on stop

I've noticed that the audio device keeps staying active even after playback is stopped for example by changing the "speaker" back to the playing Spotify app. I suspect this is because the stream stays open because drop(stream) is never reached.
I've tried refactoring stream to an optional mutable like decoder and set stream = None on stop in my branch at https://github.com/herrernst/librespot/tree/close-stream-on-stop.
Unfortunately, this most of the time leads to a segmentation fault, see lldb backtrace, gdb backtrace.
I am very new to Rust and also don't fully understand player.rs yet.
Thanks for your help! I will stop annoying you for now ;)

Implement IPC for 3rd party applications.

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.

move from portaudio to libao

More leightweight, support for nearly all audio subsystems, crossplatform and more recently developed library.

https://xiph.org/ao/

Doesn't start playing anymore

With the changes in 3ccb2e2, librespot doesn't start playing anymore (iOS just shows "connecting ...").

Crash on selecting device

1. started librespot as headless daemon
2. started spotify desktop client
3. selected libresprot device
4. librespot crashed:

librespot c0f9e40 (2016-03-26). Built on 2016-04-16.
Password: 
Connecting to AP sto3-accesspoint-a72.ap.spotify.com:443
Authenticated !
Using PulseAudioSink
kMessageTypeHello S4 69c195a662b9112a35f65e12d131a5b27SDDf2b 1 1460769391127
kMessageTypeHello rawvm a519a3b3c18e1b76819a38fsssD3dgf77db6e922071 1 0
kMessageTypeNotify S4 69c195a662b9112a35f65e12d131a5b27SDDf2b 2 1460769391127
kMessageTypeHello rawvm a519a3b3c18e1b76819a38fsssD3dgf77db6e922071 2 0
kMessageTypeNotify S4 69c195a662b9112a35f65e12d131a5b27SDDf2b 3 1460769391127
kMessageTypeHello rawvm a519a3b3c18e1b76819a38fsssD3dgf77db6e922071 3 0
kMessageTypeNotify S4 69c195a662b9112a35f65e12d131a5b27SDDf2b 4 1460769391127
kMessageTypeLoad rawvm a519a3b3c18e1b76819a38fsssD3dgf77db6e922071 1 0
thread '<unnamed>' panicked at 'index out of bounds: the len is 0 but the index is 0', src/libcollections/vec.rs:1134
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', src/libcore/result.rs:688
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', src/libcore/result.rs:688

1. today i have seen rust code the first time, no idea whats going on
2. if i start a song on the spotify desktop client and THEN select the librespot device, it works like expected.

Crossfading

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

Issues building with rust 1.7.0-nightly

I just installed rust nightly and can't get things to build correctly. I read somewhere that nightly has removed a LOT of deprecated things in the last 6 months, so I'm not sure if the README has the correct information regarding building or not.

I really know nothing about Rust, heh.

Thanks!

/Users/jmaddox/.cargo/registry/src/github.com-88ac128001ac3a9a/winapi-build-0.1.1/src/lib.rs:1:1: 1:1 error: can't find crate for `std` [E0463]
/Users/jmaddox/.cargo/registry/src/github.com-88ac128001ac3a9a/winapi-build-0.1.1/src/lib.rs:1 // Copyright © 2015, Peter Atashian
                                                                                               ^
error: aborting due to previous error
/Users/jmaddox/.cargo/registry/src/github.com-88ac128001ac3a9a/encoding_index_tests-0.1.4/index_tests.rs:1:1: 1:1 error: can't find crate for `std` [E0463]
/Users/jmaddox/.cargo/registry/src/github.com-88ac128001ac3a9a/encoding_index_tests-0.1.4/index_tests.rs:1 // This is a part of rust-encoding.
                                                                                                           ^
error: aborting due to previous error
Build failed, waiting for other jobs to finish...
/Users/jmaddox/.cargo/registry/src/github.com-88ac128001ac3a9a/pkg-config-0.3.6/src/lib.rs:1:1: 1:1 error: can't find crate for `std` [E0463]
/Users/jmaddox/.cargo/registry/src/github.com-88ac128001ac3a9a/pkg-config-0.3.6/src/lib.rs:1 //! A build dependency for Cargo libraries to find system artifacts through the
                                                                                             ^
error: aborting due to previous error
/Users/jmaddox/.cargo/registry/src/github.com-88ac128001ac3a9a/libc-0.2.4/src/lib.rs:1:1: 1:1 error: can't find crate for `std` [E0463]
/Users/jmaddox/.cargo/registry/src/github.com-88ac128001ac3a9a/libc-0.2.4/src/lib.rs:1 // Copyright 2012-2015 The Rust Project Developers. See the COPYRIGHT
                                                                                       ^
error: aborting due to previous error
/Users/jmaddox/.cargo/registry/src/github.com-88ac128001ac3a9a/gcc-0.3.21/src/lib.rs:1:1: 1:1 error: can't find crate for `std` [E0463]
/Users/jmaddox/.cargo/registry/src/github.com-88ac128001ac3a9a/gcc-0.3.21/src/lib.rs:1 //! A library for build scripts to compile custom C code
                                                                                       ^
error: aborting due to previous error
/Users/jmaddox/.cargo/registry/src/github.com-88ac128001ac3a9a/getopts-0.2.14/src/lib.rs:1:1: 1:1 error: can't find crate for `std` [E0463]
/Users/jmaddox/.cargo/registry/src/github.com-88ac128001ac3a9a/getopts-0.2.14/src/lib.rs:1 // Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT
                                                                                           ^
error: aborting due to previous error
/Users/jmaddox/.cargo/registry/src/github.com-88ac128001ac3a9a/rustc-serialize-0.3.16/src/lib.rs:1:1: 1:1 error: can't find crate for `std` [E0463]
/Users/jmaddox/.cargo/registry/src/github.com-88ac128001ac3a9a/rustc-serialize-0.3.16/src/lib.rs:1 // Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT
                                                                                                   ^
error: aborting due to previous error
/Users/jmaddox/.cargo/registry/src/github.com-88ac128001ac3a9a/winapi-0.2.5/src/lib.rs:1:1: 1:1 error: can't find crate for `std` [E0463]
/Users/jmaddox/.cargo/registry/src/github.com-88ac128001ac3a9a/winapi-0.2.5/src/lib.rs:1 // Copyright © 2015, Peter Atashian
                                                                                         ^
error: aborting due to previous error
Could not compile `winapi-build`.

To learn more, run the command again with --verbose.

Does not work on Rust nightlies >=2015-08-12

On 2015-08-12 a major pile of unstable deprecated functionality has been removed from Rust. That includes the std::sync::Future type which is used in librespot.

Volume control - default volume low (50%?)

librespot is working fine in my Raspberry now. Any spotify client cannot however control the volume of librespot. My alsa setting is now 100% volume, but the level is quite low and i think it is on the default spotify volume which may be 50%. For a high-end application 100% would be much better. Is there any way to control librespot volume or make the default 100%?

Use pulseaudio native volume management

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?

Add zeroconf based login

Specify ALSA device for librespot

Trying to use librespot on my main HTPC that has Kodi; I built a simple kodi addon that allows me to start and stop librespot. Having issues with audio output.

The following works in my baytrail system (running Fedora 23):

speaker-test -D hdmi:CARD=PCH,DEV=0 -c 2 -r 48000

(same as: hdmi:0,0) - my receiver is on HDMI, note that "hw:0,0" doesn't work.

For some reason ALSA defaults to analog output and tweaking /etc/asound.conf wouldn't help (I tried to change it to default to HDMA instead of analog but no luck at all with this; doesn't seem to be possible).

Is there a way for librespot to use "hdmi:0,0" instead of the ALSA default? I looked for configuration files for "portaudio", session variables/parameters &c, but couldn't find anything useful.

I also tried building the "ALSA" backend branch of librespot but no change. It has not command line switch for the audio device.

Canonical Name should be used to subscribe to spirc

Currently the username given as an argument is used to subscribe to the spirc connect.
In the case where that username is not the canonical one, this prevents Spotify Connect from working.
This happens for eg when upper case characters are used in the username. The canonical one is all lowercase.

The APWelcome message received after logging in contains the canonical username.

Reported by @JayRod12

Windows build errors

The build fails and I can't track it down, because it's the build executable that fails. I assume it is compiled by another build script, but no idea how to fix it:

failed to run custom build command for `librespot-protocol v0.1.0
librespot\target\debug\build\librespot-protocol-39e21a77f117cd01\build-script-build`
(exit code: 101)
--- stderr
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value:
IoError(Error { repr: Os { code: 2, message: "System can't find path specified." } })', 
../src/libcore\result.rs:688

When adding tracks they get added after the current playing track

Playing works like a charm, thanks for that. When adding tracks they get added after the currently playing track in stead of after the last item in the playlist.

Rewrite connection.rs to resolve the access point on launch

Currently librespot uses a Spotify server that is hardcoded from when plietar originally wrote the library. Whilst this can be changed manually before compiling, if this library is to be used in production, it should get the server from https://apresolve.spotify.com/ on launch and use that server

Add search support

fedora dependencies - correction to readme

The following is missing in the fedora dependencies list

sudo dnf install protobuf-devel

Run as daemon

First of all : fantastic project .-), works like a charme

Secondly my question is to run the binary as a daemon with a start/ stop script. My own try works with start|stop|restart librespot but its not running in background. could anybody help in this issue ?

#!/bin/sh

### BEGIN INIT INFO
# Provides:          librespot
# Short-Description: Spotify Client Daemon
# Description:       Start the Spotify Client Daemon service
#                    for network access to the local audio queue.
### END INIT INFO

. /lib/lsb/init-functions

PATH=/sbin:/bin:/usr/sbin:/usr/bin
NAME=librespot
DESC="Spotify Client Daemon"
DAEMON=/XXX/librespot/target/release/librespot

DAEMON_ARGS="--appkey  /root//spotify-connect-web-chroot/usr/src/app/spotify_appkey.key --username XXX --password XXX --bitrate 320 --name XXX --backend pulseaudio"
START_LIBRESPOT=true
PIDFILE=/var/run/librespot/pid
USER=mpd

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0


if [ ! -d "/var/run/librespot" ]; then
        mkdir /var/run/librespot
        if dpkg-statoverride --list --quiet /var/run/librespot > /dev/null; then
                #if dpkg-statoverride is used update it with permissions there
                dpkg-statoverride --force --quiet --update --add $( dpkg-statoverride --list --quiet /var/run/librespot ) 2> /dev/null
        else
                #use defaults
                chown mpd:audio /var/run/librespot
                chmod 755 /var/run/librespot
        fi
fi

#for i in $(ps aux| grep -v grep|grep '/steflaweb/librespot/target/release/librespot'|awk '{print $2}'); do echo $i; done

kill_librespot () {
        log_daemon_msg "Killing librespot "
        for i in $(ps aux| grep -v grep|grep "$DAEMON"|awk '{print $2}')
                do
                        log_daemon_msg "processes: " "$i"
                kill -9 $i
                done
        log_end_msg $?
}



librespot_start () {
    if [ "$START_LIBRESPOT" != "true" ]; then
        log_action_msg "Not starting LIBRESPOT: disabled by /etc/default/$NAME".
        exit 0
    fi

    log_daemon_msg "Starting $DESC" "$NAME"

    if [ -z "$PIDFILE" ]; then
        log_failure_msg \
            "Must have  pid_file set; cannot start daemon."
        exit 1
    fi

    PIDDIR=$(dirname "$PIDFILE")
    if [ ! -d "$PIDDIR" ]; then
        mkdir -m 0755 $PIDDIR
        chown mpd:audio $PIDDIR
    fi

    start-stop-daemon --start --quiet --oknodo --pidfile "$PIDFILE" \
        --chuid $USER --exec "$DAEMON" -- $DAEMON_ARGS
    log_end_msg $?
}

librespot_stop () {
    if [ "$START_LIBRESPOT" != "true" ]; then
        log_failure_msg "Not stopping LIBRESPOT: disabled by /etc/default/$NAME".
        exit 0
    fi
    if [ -z "$PIDFILE" ]; then
        log_failure_msg \
            "Must have pid_file set; cannot stop daemon."
        exit 1
    fi

    log_daemon_msg "Stopping $DESC" "$NAME"
    #start-stop-daemon --stop --quiet --oknodo --retry 5 --pidfile "$PIDFILE" \
    #    --exec $DAEMON
    kill_librespot
    log_end_msg $?
}

# note to self: don't call the non-standard args for this in
# {post,pre}{inst,rm} scripts since users are not forced to upgrade
# /etc/init.d/librespot when librespot is updated
case "$1" in
    start)
        librespot_start
        ;;
    stop)
        librespot_stop
        ;;
    restart|force-reload)
        librespot_stop
        librespot_start
        ;;
    force-start)
        librespot_start
        ;;
    force-restart)
        librespot_stop
        librespot_start
        ;;
    force-reload)
        librespot_stop
        librespot_start
        ;;
    *)
        echo "Usage: $0 {start|force-start|force-restart|stop|restart|force-reload}"
        exit 2
        ;;
esac

Pure rust mDNS/Zeroconf implementation

librespot currently depends on dns-sd for service registration. This makes build quite painful / impossible on windows and is currently optional for this reason.

A pure rust implementation of mDNS and Zeroconf would fix this by removing this dependency.

Support for Tremor

libvorbis is an ogg decoder library targeted for architectures with floating-point support. Tremor is an alternative decoder implementation that provides an integer-only implementation for soft-float devices.

The Tremor lib is not a drop-in replacement for libvorbis/libvorbisfile (the original libs have a source API that uses float arguments) but it is very similar.

As there does not exists any Rust bindings for Tremor this has to be implemented first.

Compilation fails on rust nightlies after 18.01.2016

thread '<main>' panicked at 'destination and source slices have different lengths', ../src/libcore/slice.rs:479
thread '<unnamed>' panicked at 'called Result::unwrap() on an Err value: AsyncError::Aborted', ../src/libcore/result.rs:688

probably this change:
rust-lang/rust@6a7bc47

Example client crashes on songs from offline playlist

I can play songs from my playlist with the example client just fine, but if the playlist is available offline, the following error occurs:

thread '

' panicked at 'assertion failed: (left == right) (left: 0, right: 16)', src\util\spotify_id.rs:45
thread '' panicked at 'called Result::unwrap() on an Err value:
IoError(Error { repr: Os { code: 10053, message: "Eine bestehende Verbindung wurde softwaregesteuert\r\ndurch den Hostcomputer abgebrochen." } })

(An established connection was aborted by the software in your host machine.)

Preload next track when approaching the end of the current one

Currently we don't start loading the next track until the current one has completed. This causes a short delay between tracks.

Instead the next track should start loading before that.

Is PulseAudio still supported?

I'm getting the following on an x64 Ubuntu box...

/librespot/target/release/librespot --username $SPOTIFY_USERNAME --password=$SPOTIFY_PASSWORD --name bxps --appkey /etc/spotify_appkey.key --backend pulseaudio
INFO:librespot::main_helper: librespot 4d277e5 (2016-05-09). Built on 2016-05-14.
INFO:librespot::session: Connecting to AP lon2-accesspoint-a11.ap.spotify.com:80
INFO:librespot::session: Authenticated !
INFO:librespot::audio_backend::pulseaudio: Using PulseAudioSink
thread '<unnamed>' panicked at 'assertion failed: s != null_mut()', /librespot/target/release/build/librespot-2b132d5c5ccf58d4/out/lib.rs:836
stack backtrace:
   1:     0x55be0d18e3f0 - sys::backtrace::tracing::imp::write::h3675b4f0ca767761Xcv
   2:     0x55be0d190f0b - panicking::default_handler::_$u7b$$u7b$closure$u7d$$u7d$::closure.44519
   3:     0x55be0d190b78 - panicking::default_handler::h18faf4fbd296d909lSz
   4:     0x55be0d17e52c - sys_common::unwind::begin_unwind_inner::hfb5d07d6e405c6bbg1t
   5:     0x55be0cfe6bbf - sys_common::unwind::begin_unwind::h26420181488358413
   6:     0x55be0d00a04f - audio_backend::pulseaudio::PulseAudioSink.Open::open::h2cbc051af1d4ad49zqb
   7:     0x55be0d094e75 - audio_backend::mk_sink::h17800774558512200665
   8:     0x55be0d09830e - sys_common::unwind::try::try_fn::h9450263594518283024
   9:     0x55be0d18d7eb - __rust_try
  10:     0x55be0d18aa4d - sys_common::unwind::inner_try::hadd81c754a64f07ciYt
  11:     0x55be0d098a7c - boxed::F.FnBox<A>::call_box::h1742280503296891314
  12:     0x55be0d18fa89 - sys::thread::Thread::new::thread_start::h9bc812305b5e01feFPy
  13:     0x7fa2e02536f9 - start_thread
  14:     0x7fa2dff89b5c - clone
  15:                0x0 - <unknown>
DEBUG:librespot::spirc: kMessageTypeHello "bxps" c943c8a7b50126464b7d5ef27d7149ea69880dd8 1 1463202448294
DEBUG:librespot::spirc: kMessageTypeNotify "bxps" 35211575f7204be478a6bdb4cae34bac2d1e5473 20 1463202135098
DEBUG:librespot::spirc: kMessageTypeNotify "DESKTOP-1VQ1KU8" 905c2c89d5a3603f9785575b7914888e23b1b5bf 16 1463202135098

Crash when playing a particular song

Hello,

A crash occurs when I try to play this song.

It's compiled on a Raspberry Pi 2 from master. Here is the backtrace (the program was still hanging, don't know if it is relevant).

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', ../src/libcore/result.rs:688
stack backtrace:
   1: 0x54d0e22f - sys::backtrace::tracing::imp::write::h915bdba0cf2b7eb2yju
   2: 0x54d10d7b - panicking::default_handler::_<closure>::closure.42462
   3: 0x54d107c3 - panicking::default_handler::h5649abd342504206ryy
   4: 0x54cfb61f - sys_common::unwind::begin_unwind_inner::h411a20ea9dff208d5bt
   5: 0x54cfc057 - sys_common::unwind::begin_unwind_fmt::h23d12c3e5d53eabcbbt
   6: 0x54d0d7d3 - rust_begin_unwind
   7: 0x54d18e6f - panicking::panic_fmt::h6a4d01d6dfe84597zYL
   8: 0x54c030c3 - player::Player::command::hb0a29a5db46ae0996Gc
   9: 0x54c4aa2f - spirc::SpircManager::run::h6a87ab8ff491ece0Ykd
  10: 0x54bc1d6f - sys_common::unwind::try::try_fn::h15239427894743543715
  11: 0x54d0d773 - __rust_try
  12: 0x54d0d773 - __rust_try

When using https://github.com/crsmoro/scplayer and libspotify_embedded_shared.so, another crash occur but locally it plays fine. So maybe it's a problem in spotify connect rather than in librespot; but it would be nice if librespot could recover from this error.

Since I'm not used to report rust bugs, please let me know if you need additional info or any help!

Thanks!

Building fails

First, I am very new to Rust and Cargo. I installed Rust nightly on my Arch Linux.

$ rustc --version
rustc 1.6.0-nightly (462ec0576 2015-12-09)
$ cargo --version
cargo 0.7.0-nightly (1af03be 2015-12-08)

Unfortunatly, trying to build with cargo build fails:

Compiling librespot-protocol v0.1.0 (file:///home/joerg/Development/git/librespot)
/home/joerg/.cargo/git/checkouts/rust-protobuf-macros-0155ebac4efea846/master/src/lib.rs:10:5: 10:28 error: unresolved import `rustc::plugin::Registry`. Could not find `plugin` in `rustc` [E0432]
/home/joerg/.cargo/git/checkouts/rust-protobuf-macros-0155ebac4efea846/master/src/lib.rs:10 use rustc::plugin::Registry;
                                                                                                ^~~~~~~~~~~~~~~~~~~~~~~
/home/joerg/.cargo/git/checkouts/rust-protobuf-macros-0155ebac4efea846/master/src/lib.rs:10:5: 10:28 help: run `rustc --explain E0432` to see a detailed explanation
error: aborting due to previous error

Any idea?