librespot built with lewton support crashes after first song

[sashahilton00]

Issue by awiouy
Tuesday Sep 05, 2017 at 19:35 GMT
Originally opened as plietar/librespot#248

---

librespot built with lewton support crashes after first song with the following messages:

thread '<unnamed>' panicked at ' error: OggError(NoCapturePatternFound)', /checkout/src/libcore/result.rs:860:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', /checkout/src/libcore/result.rs:860:4

Running with RUST_BACKTRACE=1 does not provide further information:

thread '<unnamed>' panicked at 'Vorbis error: OggError(NoCapturePatternFound)', /checkout/src/libcore/result.rs:860:4
stack backtrace:
   0: <unknown>

The above messages were issued while using ALSA backend.

librespot was built with Rust 1.20.0:
$CARGO_BUILD --no-default-features --features "alsa-backend pulseaudio-backend with-lewton"

[sashahilton00]

Comment by sstickel
Sunday Nov 12, 2017 at 12:01 GMT

---

Anybody found a solution to this? Made librespot pretty unusable for me, as after a few tracks librespots always panicks and dies.

[awiouy]

This issue remains with current master, I therefore refrain from building with-lewton

[sashahilton00]

Here's a full backtrace (run with export RUST_BACKTRACE=full):

thread '<unnamed>' panicked at 'Vorbis error: OggError(NoCapturePatternFound)', src/libcore/result.rs:906:4
stack backtrace:
   0:        0x106d62b73 - std::sys::imp::backtrace::tracing::imp::unwind_backtrace::h3421d74c3554d1d6
                               at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1:        0x106d5f4cc - std::sys_common::backtrace::_print::h81d2920454574615
                               at src/libstd/sys_common/backtrace.rs:68
   2:        0x106d66b71 - std::panicking::default_hook::{{closure}}::h046b82ccd70886b8
                               at src/libstd/sys_common/backtrace.rs:57
                               at src/libstd/panicking.rs:381
   3:        0x106d66876 - std::panicking::default_hook::h00ff9adc172e30f9
                               at src/libstd/panicking.rs:397
   4:        0x106d670b5 - std::panicking::begin_panic::hf76e4af07ba1dfa4
                               at src/libstd/panicking.rs:577
   5:        0x106d66f4e - std::panicking::begin_panic::hf76e4af07ba1dfa4
                               at src/libstd/panicking.rs:538
   6:        0x106d66e22 - std::panicking::try::do_call::h3cbb81c41447d36b
                               at src/libstd/panicking.rs:522
   7:        0x106d66d82 - std::panicking::try::do_call::h3cbb81c41447d36b
                               at src/libstd/panicking.rs:498
   8:        0x106d9f2f3 - <core::ops::range::Range<Idx> as core::fmt::Debug>::fmt::h7e1bfae6b8dbdbf2
                               at src/libcore/panicking.rs:71
   9:        0x1062b4bdd - core::result::unwrap_failed::hbe65d52cf173ad35
                               at /Users/travis/build/rust-lang/rust/src/libcore/macros.rs:23
  10:        0x1062af83d - <core::result::Result<T, E>>::expect::h70e37a3941dae0b2
                               at /Users/travis/build/rust-lang/rust/src/libcore/result.rs:799
  11:        0x1062a6ded - librespot::player::PlayerState::playing_to_paused::h71fcca76ec5f692b
                               at src/player.rs:230
  12:        0x1061674b2 - librespot::player::Player::new::{{closure}}::h65a1946639d1fb1e
                               at /Users/sashahilton/Documents/librespot/src/player.rs:66
  13:        0x10619bf81 - std::sys_common::backtrace::__rust_begin_short_backtrace::h0be8dc656e65d3c4
                               at /Users/travis/build/rust-lang/rust/src/libstd/sys_common/backtrace.rs:133
  14:        0x10615c868 - std::thread::Builder::spawn::{{closure}}::{{closure}}::hdc03551cfbaa331b
                               at /Users/travis/build/rust-lang/rust/src/libstd/thread/mod.rs:406
  15:        0x10619bc71 - <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once::h4b6768b0a02dfca6
                               at /Users/travis/build/rust-lang/rust/src/libstd/panic.rs:300
  16:        0x106164bc1 - std::panicking::try::do_call::hcfa55e02944d1224
                               at /Users/travis/build/rust-lang/rust/src/libstd/panicking.rs:480
  17:        0x106d7252e - panic_unwind::dwarf::eh::read_encoded_pointer::h3e27ca5c61a4336a
                               at src/libpanic_unwind/lib.rs:101
  18:        0x106164a9c - std::panicking::try::h601e7203e01262ee
                               at /Users/travis/build/rust-lang/rust/src/libstd/panicking.rs:459
  19:        0x10619c039 - std::panic::catch_unwind::h50b081a0b01fed10
                               at /Users/travis/build/rust-lang/rust/src/libstd/panic.rs:365
  20:        0x10615c6a2 - std::thread::Builder::spawn::{{closure}}::hda706cb4bc3ce64c
                               at /Users/travis/build/rust-lang/rust/src/libstd/thread/mod.rs:405
  21:        0x106163615 - <F as alloc::boxed::FnBox<A>>::call_box::hc5af7a547988440e
                               at /Users/travis/build/rust-lang/rust/src/liballoc/boxed.rs:762
  22:        0x106d65fbb - std::sys::imp::thread::Thread::new::thread_start::h8c15ceac1351d4e1
                               at /Users/travis/build/rust-lang/rust/src/liballoc/boxed.rs:772
                               at src/libstd/sys_common/thread.rs:24
                               at src/libstd/sys/unix/thread.rs:90
  23:     0x7fff9329c93a - _pthread_body
  24:     0x7fff9329c886 - _pthread_start
DEBUG:librespot::player: drop Player[0]

[sashahilton00]

@awiouy The problem looks to be coming from

librespot/src/player.rs

Line 230 in 932441d

Some(decoder.next_packet().expect("Vorbis error"))

Do we think this has something to do with the bad headers spotify seems to have in it's vorbis files?

[awiouy]

Could it be related to RustAudio/lewton#18

[ComlOnline]

Notes from gitter for easy reference.

Sasha Hilton @sashahilton00
Lewton is pure rust. Unfortunately it panics on the spotify files, most likely due to malformed headers, as we know that there is a section in the files which is bad/unknown. The solution in other players has been to skip it.
Here's how despotism handled it for example: https://sourceforge.net/p/despotify/code/HEAD/tree/java/trunk/src/main/java/se/despotify/client/player/SpotifyOggHeader.java#l106

XpLoDWilD @xplodwild Feb 01 14:46
just skip the 167 first bytes

Sasha Hilton @sashahilton00 Feb 01 14:49
Where'd you get 167 from?

XpLoDWilD @xplodwild Feb 01 14:53
that's the length of the header read by despotify
https://sourceforge.net/p/despotify/code/HEAD/tree/java/trunk/src/main/java/se/despotify/client/player/ChannelPlayer.java#l195
so the 167 first bytes are spotify's own header metadata, then the ogg/vorbis data begins