[GH-ISSUE #681] Librespot: thread '' panicked at 'attempted to zero-initialize type vorbisfile_sys::ov_callbacks, which is invalid' #389

Closed
opened 2026-02-27 19:30:21 +03:00 by kerem · 5 comments
Owner

Originally created by @heitbaum on GitHub (Mar 26, 2021).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/681

With LE10 - librespot was failing due to an error in vorbis-rs

https://github.com/LibreELEC/LibreELEC.tv/issues/5038

the fix was identified in https://github.com/tomaka/vorbis-rs/issues/19 and https://github.com/RustAudio/lewton/issues/89

we are adding a patch to LE10 to have librespot working via PR https://github.com/LibreELEC/LibreELEC.tv/pull/5166 and specifically the following patch to the librespot 0.1.6 source https://github.com/LibreELEC/LibreELEC.tv/pull/5166/commits/04c7591233348c9d845a36fd9696e325e09f8b44

would be great if you could have this or similar included in the mainline librespot.

Originally created by @heitbaum on GitHub (Mar 26, 2021). Original GitHub issue: https://github.com/librespot-org/librespot/issues/681 With LE10 - librespot was failing due to an error in vorbis-rs https://github.com/LibreELEC/LibreELEC.tv/issues/5038 the fix was identified in https://github.com/tomaka/vorbis-rs/issues/19 and https://github.com/RustAudio/lewton/issues/89 we are adding a patch to LE10 to have librespot working via PR https://github.com/LibreELEC/LibreELEC.tv/pull/5166 and specifically the following patch to the librespot 0.1.6 source https://github.com/LibreELEC/LibreELEC.tv/pull/5166/commits/04c7591233348c9d845a36fd9696e325e09f8b44 would be great if you could have this or similar included in the mainline librespot.
kerem 2026-02-27 19:30:21 +03:00
Author
Owner

@Johannesd3 commented on GitHub (Apr 19, 2021):

Seems as if vorbis-rs isn't maintained anymore by @tomaka. Should librespot create its own fork? Maybe we can share some code with librespot-tremor, as it is essentially the same.

<!-- gh-comment-id:822449198 --> @Johannesd3 commented on GitHub (Apr 19, 2021): Seems as if vorbis-rs isn't maintained anymore by @tomaka. Should librespot create its own fork? Maybe we can share some code with [librespot-tremor](https://github.com/librespot-org/librespot-tremor), as it is essentially the same.
Author
Owner

@roderickvd commented on GitHub (Apr 19, 2021):

While forking seems a fine idea if we want to keep libvorbis support around, is that indeed what we want to do? What does it add over lewton, that's fast enough even on a RPi Zero? Even for tremor I'm not sure which hardware without hard float support is actually a target for librespot.

<!-- gh-comment-id:822469959 --> @roderickvd commented on GitHub (Apr 19, 2021): While forking seems a fine idea if we want to keep `libvorbis` support around, is that indeed what we want to do? What does it add over `lewton`, that's fast enough even on a RPi Zero? Even for `tremor` I'm not sure which hardware without hard float support is actually a target for `librespot`.
Author
Owner

@roderickvd commented on GitHub (May 18, 2021):

@heitbaum removing support for libvorbis and tremor is under serious consideration. As far as I know, LibreELEC is the only thing downstream that compiles with --features with-vorbis. Any arguments against moving to lewton 100%?

I just checked and compiling with-vorbis only saves 167 kB. Likewise the slight boost in performance will be neglible. At the same time, the bindings are unmaintained and only pass integer samples instead of the floats they were originally in, causing quantization error and lower sound quality. Finally, there is no Rust-unsafe code in lewton. So there's a lot to say about moving to lewton and nothing of significance for keeping libvorbis as I can see.

Thanks in advance for your feedback, I'll be submitting a PR to remove libvorbis and tremor soon.

<!-- gh-comment-id:842890395 --> @roderickvd commented on GitHub (May 18, 2021): @heitbaum removing support for `libvorbis` and `tremor` is under serious consideration. As far as I know, `LibreELEC` is the only thing downstream that compiles with `--features with-vorbis`. Any arguments against moving to `lewton` 100%? I just checked and compiling `with-vorbis` only saves 167 kB. Likewise the slight boost in performance will be neglible. At the same time, the bindings are unmaintained and only pass integer samples instead of the floats they were originally in, causing quantization error and lower sound quality. Finally, there is no Rust-unsafe code in `lewton`. So there's a lot to say about moving to `lewton` and nothing of significance for keeping `libvorbis` as I can see. Thanks in advance for your feedback, I'll be submitting a PR to remove `libvorbis` and `tremor` soon.
Author
Owner

@heitbaum commented on GitHub (Nov 20, 2021):

I have just raised the PR for LIbreELEC for 0.3.1 - just asked our forum for someone to test. All updated with your vorbis cleanups 👍 https://github.com/LibreELEC/LibreELEC.tv/pull/5891 and https://github.com/LibreELEC/LibreELEC.tv/pull/5892

<!-- gh-comment-id:974662407 --> @heitbaum commented on GitHub (Nov 20, 2021): I have just raised the PR for LIbreELEC for 0.3.1 - just asked our forum for someone to test. All updated with your vorbis cleanups 👍 https://github.com/LibreELEC/LibreELEC.tv/pull/5891 and https://github.com/LibreELEC/LibreELEC.tv/pull/5892
Author
Owner

@roderickvd commented on GitHub (Nov 20, 2021):

Great stuff @heitbaum!

<!-- gh-comment-id:974697140 --> @roderickvd commented on GitHub (Nov 20, 2021): Great stuff @heitbaum!
Sign in to join this conversation.
No milestone
No project
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#389
No description provided.