Open kcning opened 7 years ago
librespot uses mDNS for zeroconf authentication by default. This may interfere with unusual DNS setups.
Can you run librespot with --disable-discovery
?
With this option it doesn't interfere with the DNS setups, but I could't login either. This is the backtrace with librespot built with debug info. I guess the dns issue is solved. I can close this thread and open a new one if you prefer that. It's possibly related to #167
> RUST_BACKTRACE=1 target/debug/librespot --disable-discovery --name $DEVNAME --cache /var/cache/librespot -v -u $USERNAME
INFO:librespot: librespot d95c0b3 (2017-04-13). Built on 2017-04-25.
Password for $USERNAME:
INFO:librespot::session: Connecting to AP "gew1-accesspoint-a-tl61.ap.spotify.com:4070"
thread 'main' panicked at 'Authentication failed', /home/kcning/aur/librespot-git/src/librespot/target/debug/build/librespot-978c8c724a8d5e28/out/lib.rs:365
stack backtrace:
1: 0x560a11cb1fcc - std::sys::imp::backtrace::tracing::imp::write::h0263459999f7f6d4
2: 0x560a11cb6fde - std::panicking::default_hook::{{closure}}::hfb43d85657ad3a4c
3: 0x560a11cb6bda - std::panicking::default_hook::h2f5648e30de6b0b9
4: 0x560a11cb747b - std::panicking::rust_panic_with_hook::h9f3930ca8cee8a65
5: 0x560a111c2693 - std::panicking::begin_panic::hde61f6fe38d54e70
at /build/rust/src/rustc-1.16.0-src/src/libstd/panicking.rs:517
6: 0x560a1139cc1a - librespot::connection::authenticate::{{closure}}::hd6a2940cb52790ae
at /home/kcning/aur/librespot-git/src/librespot/src/lib.rs:70
7: 0x560a1115761d - <futures::future::and_then::AndThen<A, B, F> as futures::future::Future>::poll::{{closure}}::{{closure}}::h479b989cda8c9f98
at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/future/and_then.rs:33
8: 0x560a1120fda6 - <core::result::Result<T, E>>::map::hf2b0b0cacc60bb58
at /build/rust/src/rustc-1.16.0-src/src/libcore/result.rs:465
9: 0x560a11156514 - <futures::future::and_then::AndThen<A, B, F> as futures::future::Future>::poll::{{closure}}::h3b2ac7974848acad
at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/future/and_then.rs:32
10: 0x560a112b9888 - <futures::future::chain::Chain<A, B, C>>::poll::h0e8c7375b787f232
at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/future/chain.rs:38
11: 0x560a11155efb - <futures::future::and_then::AndThen<A, B, F> as futures::future::Future>::poll::h724442b22cb14f2f
at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/future/and_then.rs:31
12: 0x560a112de080 - <alloc::boxed::Box<F> as futures::future::Future>::poll::h3a4fda7d4de739e0
at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/future/mod.rs:104
13: 0x560a112c304c - <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:31
14: 0x560a1115613b - <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
15: 0x560a113401ef - <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
16: 0x560a1113c2c0 - <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
17: 0x560a1114d6a8 - <librespot::Main as futures::future::Future>::poll::h0ff13c6db242c9e7
at /home/kcning/aur/librespot-git/src/librespot/src/main.rs:248
18: 0x560a1110c7cc - <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
19: 0x560a1110c9fe - <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
20: 0x560a111408cf - 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
21: 0x560a111131b5 - <std::thread::local::LocalKey<T>>::with::hd4e87ccf21a65c1f
at /build/rust/src/rustc-1.16.0-src/src/libstd/thread/local.rs:253
22: 0x560a111407ba - futures::task_impl::set::ha5863bcee66741b8
at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.10/src/task_impl/mod.rs:47
23: 0x560a1110c912 - <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
24: 0x560a1110c76a - <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
25: 0x560a110f987e - 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
26: 0x560a11106b74 - <scoped_tls::ScopedKey<T>>::set::h50d3deded1ff8c8c
at /home/kcning/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped-tls-0.1.0/src/lib.rs:135
27: 0x560a110f94ff - 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
28: 0x560a1114e647 - librespot::main::h58bbb806c9a048c8
at /home/kcning/aur/librespot-git/src/librespot/src/main.rs:311
29: 0x560a11cbe3fa - __rust_maybe_catch_panic
30: 0x560a11cb7be6 - std::rt::lang_start::h1c5729a586411154
31: 0x560a1114e9b2 - main
32: 0x7f1234d42510 - __libc_start_main
33: 0x560a110f9059 - _start
34: 0x0 - <unknown>
No, I'd prefer keeping this issue open. librespot shouldn't interfere with the system's DNS configuration, so this is still a bug. Moving to #167 for the authentication failure issue.
This looks a bit like the issue I'm experiencing: https://github.com/shanemeagher/service.librespot/issues/3
Doesn't resolve as well, no custom DNS setup btw, just libreelec out of the box and Openwrt on the router (gets results from provider DNS and Google as backup).
I use avahi daemon (zerconf) for several services. Whenever I want to use librespot I have to stop that daemon, which runs on port 5353, first. Does librespot has its own zeroconf functionality which interferes with avahi?
@dowhiletrue yes, librespot has mdns / zeroconf built-in. Pull Request #246 allows librespot to be built to use an existing avahi install which should avoid this conflict.
Until this is merged, setting disallow-other-stacks=no
in avahi-daemon.conf, should allow both to co-exist.
Hi, I can't launch librespot because of dns resolve failure. Below is the error msg. update: backtrace with debug info.
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).
It seems like all the dns resolves are intercepted by librespot. Is this normal? And is there a way to fix this?