librespot-org / librespot Goto Github PK
View Code? Open in Web Editor NEWOpen Source Spotify client library
License: MIT License
Open Source Spotify client library
License: MIT License
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
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.
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:
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.
Issue by Elronnd
Friday Mar 24, 2017 at 03:44 GMT
Originally opened as plietar/librespot#167
I get thread 'main' panicked at 'Authentication failed', /home/elronnd/librespot/target/debug/build/librespot-dfbb8235c1536a0f/out/lib.rs:365
when I try to run it. I'm running with
RUST_BACKTRACE=1 ./librespot -n "name" -u username -p password
Issue by sdomotica
Tuesday Mar 14, 2017 at 20:45 GMT
Originally opened as plietar/librespot#164
I tried this version on my RPI3 Jessie https://github.com/herrernst/librespot/releases and after 5 skip songs librespot stop working.
Bye
Sandro
Good day,
can you help me compile it? I get an error: Could not compile syntex_syntax.
Issue by plietar
Wednesday Dec 30, 2015 at 12:03 GMT
Originally opened as plietar/librespot#19
Metadata and keys should be stored in cache as well, in something like an sqlite database.
Issue by mattiash
Tuesday Mar 14, 2017 at 19:56 GMT
Originally opened as plietar/librespot#163
Add a new mixer that always outputs sound at 100% volume. To print the current volume that spotify requests, set RUST_LOG=librespot::mixer::fixedmixer=debug
This PR can be applied instead of PR #161 .
mattiash included the following code: https://github.com/plietar/librespot/pull/163/commits
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.
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 'calledOption::unwrap()
on aNone
value', src/libcore/option.rs:323
note: Run withRUST_BACKTRACE=1
for a backtrace.
Any help is highly appreciated.
Many thanks,
Michael
Issue by plietar
Wednesday Dec 30, 2015 at 12:03 GMT
Originally opened as plietar/librespot#20
Issue by jsarcand
Thursday Nov 17, 2016 at 15:15 GMT
Originally opened as plietar/librespot#128
Hey there! It seems like the volume control is modulating the sound amplitude of the songs in software instead of modifying the values of the sound card through ALSA. Any thoughts on that? Thanks for that amazing piece of software!! ๐
Issue by plietar
Thursday Oct 27, 2016 at 12:29 GMT
Originally opened as plietar/librespot#125
librespot doesn't have any way of authenticating Spotify's server, and will happily send the username and password to a MITM proxy. I don't know what the official client does about it.
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.
Issue by plietar
Wednesday Dec 30, 2015 at 12:03 GMT
Originally opened as plietar/librespot#21
Issue by ipha
Saturday Jan 14, 2017 at 21:26 GMT
Originally opened as plietar/librespot#146
I've implemented the open() and close() functions so that the sink will be closed when notin use.
This is my first time working with rust, so I'm not 100% sure I'm handling the pointers correctly.
ipha included the following code: https://github.com/plietar/librespot/pull/146/commits
I think volume normalisation also should be added to this repo.
I've been using
https://github.com/herrernst/librespot/tree/volume-normalization/src
for a couple of weeks now, and it's working quite well
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 an
Err 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?
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.
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:
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?
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 :)
Issue by tatoosh
Thursday May 25, 2017 at 07:08 GMT
Originally opened as plietar/librespot#188
It would be nice to start a Playlist by parsing the Spotify ID by Argument.
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
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...
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
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:
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
Regards,
Tim
Issue by sashahilton00
Sunday Jun 11, 2017 at 23:52 GMT
Originally opened as plietar/librespot#197
Stumbled across the Qualcomm Shannon Cipher reference implementation whilst rewriting the authentication part of librespot, added a link to a copy of it in my repo.
sashahilton00 included the following code: https://github.com/plietar/librespot/pull/197/commits
Issue by plietar
Wednesday Dec 30, 2015 at 12:01 GMT
Originally opened as plietar/librespot#18
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.
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.
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
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.
Hereby the request to have librespot support spotify's dynamic playlists including Radio
Issue by wezzynl
Thursday Feb 11, 2016 at 20:45 GMT
Originally opened as plietar/librespot#45
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.
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
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 'calledResult::unwrap()
on anErr
value: Device unavailable', /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/result.rs:868
note: Run withRUST_BACKTRACE=1
for a backtrace.
thread 'main' panicked at 'calledResult::unwrap()
on anErr
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 withRUST_BACKTRACE=1
for a backtrace.
I have a fork of plietar/librespot which I've modified. Now I'd like to base it off librespot-org/librespot. Anybody knows how I would do this? I would like to be able to post pull requests here (if there ever was one :-))
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"
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```
As has been discussed elsewhere. This is to continue discussion on the topic.
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
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
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?
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!
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?
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.
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?
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
Issue by WhyNotHugo
Tuesday Jun 13, 2017 at 18:15 GMT
Originally opened as plietar/librespot#198
Include a systemd.services file to run as a user
Also document both this and the pre-existing service file and how they should be used.
WhyNotHugo included the following code: https://github.com/plietar/librespot/pull/198/commits
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?
Good to see you guys keep this project alive!
Basically copy/paste from plietar's repo issue #82
Think the issue is escaping needing to be done here:
https://github.com/ComlOnline/librespot/blob/master/src/main.rs#L155
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.