starred/librespot
1
0
Fork 0
mirror of https://github.com/librespot-org/librespot.git synced 2026-04-27 00:05:55 +03:00
Code Issues 95 Projects Releases 10 Packages Wiki Activity

[GH-ISSUE #88] librespot built with lewton support crashes after first song #78

New issue
Closed
opened 2026-02-27 19:28:42 +03:00 by kerem · 6 comments
kerem commented 2026-02-27 19:28:42 +03:00
Owner
Copy link

Originally created by @sashahilton00 on GitHub (Jan 29, 2018).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/88

Issue by awiouy
Tuesday Sep 05, 2017 at 19:35 GMT
Originally opened as https://github.com/plietar/librespot/issues/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"

Originally created by @sashahilton00 on GitHub (Jan 29, 2018). Original GitHub issue: https://github.com/librespot-org/librespot/issues/88 <a href="https://github.com/awiouy"><img src="https://avatars0.githubusercontent.com/u/9913019?v=4" align="left" width="96" height="96" hspace="10"></img></a> **Issue by [awiouy](https://github.com/awiouy)** _Tuesday Sep 05, 2017 at 19:35 GMT_ _Originally opened as https://github.com/plietar/librespot/issues/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"`
kerem 2026-02-27 19:28:42 +03:00
kerem commented 2026-02-27 19:28:43 +03:00
Author
Owner
Copy link

@sashahilton00 commented on GitHub (Jan 29, 2018):

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.

<!-- gh-comment-id:361277025 --> @sashahilton00 commented on GitHub (Jan 29, 2018): <a href="https://github.com/sstickel"><img src="https://avatars2.githubusercontent.com/u/6478954?v=4" align="left" width="48" height="48" hspace="10"></img></a> **Comment by [sstickel](https://github.com/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.
kerem commented 2026-02-27 19:28:43 +03:00
Author
Owner
Copy link

@awiouy commented on GitHub (Jan 29, 2018):

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

<!-- gh-comment-id:361299530 --> @awiouy commented on GitHub (Jan 29, 2018): This issue remains with current master, I therefore refrain from building `with-lewton`
kerem commented 2026-02-27 19:28:43 +03:00
Author
Owner
Copy link

@sashahilton00 commented on GitHub (Feb 1, 2018):

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]
<!-- gh-comment-id:362119864 --> @sashahilton00 commented on GitHub (Feb 1, 2018): 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] ```
kerem commented 2026-02-27 19:28:43 +03:00
Author
Owner
Copy link

@sashahilton00 commented on GitHub (Feb 1, 2018):

@awiouy The problem looks to be coming from github.com/librespot-org/librespot@932441db45/src/player.rs (L230)

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

<!-- gh-comment-id:362120624 --> @sashahilton00 commented on GitHub (Feb 1, 2018): @awiouy The problem looks to be coming from https://github.com/librespot-org/librespot/blob/932441db45775a55c2e97d60cb9b6a018c4c821d/src/player.rs#L230 Do we think this has something to do with the bad headers spotify seems to have in it's vorbis files?
kerem commented 2026-02-27 19:28:43 +03:00
Author
Owner
Copy link

@awiouy commented on GitHub (Feb 1, 2018):

Could it be related to https://github.com/RustAudio/lewton/issues/18

<!-- gh-comment-id:362194112 --> @awiouy commented on GitHub (Feb 1, 2018): Could it be related to https://github.com/RustAudio/lewton/issues/18
kerem commented 2026-02-27 19:28:43 +03:00
Author
Owner
Copy link

@ComlOnline commented on GitHub (Feb 5, 2018):

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

<!-- gh-comment-id:363209186 --> @ComlOnline commented on GitHub (Feb 5, 2018): 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
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
dev
v0.8.0
v0.7.1
v0.7.0
v0.6.0
v0.5.0
v0.4.2
v0.4.1
v0.4.0
v0.3.1
v0.3.0
v0.2.0
v0.1.6
v0.1.5
v0.1.3
v0.1.2
v0.1.1
v0.1.0
Labels
Clear labels   
A-Alsa

   
SpotifyAPI

   
Tokio 1.0

   
audio

   
bug

   
can't reproduce

   
compilation

   
dependencies

   
duplicate

   
enhancement

   
good first issue

   
help wanted

   
high priority

   
imported

   
imported

   
invalid

   
new api

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
reverse engineering

   
wiki

   
wontfix
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/librespot#78
No description provided.