[GH-ISSUE #902] Librespot crashes when seeking to a position that is not yet downloaded.

kerem commented

2026-02-27 19:30:41 +03:00

Owner

Originally created by @ghost on GitHub (Dec 9, 2021).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/902

Originally assigned to: @roderickvd on GitHub.

When librespot starts downloading and playing a track, when one seeks manually forward to a part that is not yet downloaded, librespot crashes. Here is the last lines of the --verbose log:

[2021-12-09T18:32:39Z TRACE librespot_connect::spirc] Sending status to server: [kPlayStatusPlay]
[2021-12-09T18:32:39Z DEBUG librespot_playback::player] command=Seek(98835)
[2021-12-09T18:32:40Z ERROR librespot_playback::player] PlayerInternal handle_command_seek: Lewton Decoder Error: Ogg decode problem
[2021-12-09T18:32:40Z TRACE librespot_connect::spirc] Sending status to server: [kPlayStatusPlay]
[2021-12-09T18:32:40Z TRACE librespot_connect::spirc] ==> kPlayStatusPlay
[2021-12-09T18:32:40Z TRACE librespot_connect::spirc] Sending status to server: [kPlayStatusPlay]
[2021-12-09T18:32:40Z TRACE librespot_connect::spirc] ==> kPlayStatusPlay
[2021-12-09T18:32:40Z ERROR librespot_playback::player] PlayerInternal poll: Lewton Decoder Error: Vorbis bitstream audio decode problem

Then the application crashed.

EDIT: This is running librespot 0.3.1 e66cc55 (Built on 2021-12-02, Build ID: b5V8XqQE, Profile: release).

Originally created by @ghost on GitHub (Dec 9, 2021). Original GitHub issue: https://github.com/librespot-org/librespot/issues/902 Originally assigned to: @roderickvd on GitHub. When librespot starts downloading and playing a track, when one seeks manually forward to a part that is not yet downloaded, librespot crashes. Here is the last lines of the ``--verbose`` log: ``` [2021-12-09T18:32:39Z TRACE librespot_connect::spirc] Sending status to server: [kPlayStatusPlay] [2021-12-09T18:32:39Z DEBUG librespot_playback::player] command=Seek(98835) [2021-12-09T18:32:40Z ERROR librespot_playback::player] PlayerInternal handle_command_seek: Lewton Decoder Error: Ogg decode problem [2021-12-09T18:32:40Z TRACE librespot_connect::spirc] Sending status to server: [kPlayStatusPlay] [2021-12-09T18:32:40Z TRACE librespot_connect::spirc] ==> kPlayStatusPlay [2021-12-09T18:32:40Z TRACE librespot_connect::spirc] Sending status to server: [kPlayStatusPlay] [2021-12-09T18:32:40Z TRACE librespot_connect::spirc] ==> kPlayStatusPlay [2021-12-09T18:32:40Z ERROR librespot_playback::player] PlayerInternal poll: Lewton Decoder Error: Vorbis bitstream audio decode problem ``` Then the application crashed. EDIT: This is running ``librespot 0.3.1 e66cc55 (Built on 2021-12-02, Build ID: b5V8XqQE, Profile: release)``.

kerem

2026-02-27 19:30:41 +03:00

closed this issue
added the
bug

audio
labels

kerem commented

2026-02-27 19:30:42 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (Dec 11, 2021):

I tried to reproduce this error by:

Making sure not to enable caching.
Skip though A BUNCH of random tracks and seeking to the middle of the track as soon as I could.

I can not reproduce.

The worst I can get is a Player::seek called from invalid state warning. And librespot recovers just fine from those.

Can the tracks in question be played otherwise? If not it could be that they're just not Vorbis? Either that or your connection is unstable and/or slow. I looked up those errors in Lewton and Ogg (the decoder libs) and they're not very helpful. It could be anything from it's not a vorbis to any number of I/O errors.

@JasonLG1979 commented on GitHub (Dec 11, 2021): I tried to reproduce this error by: 1. Making sure not to enable caching. 2. Skip though ***A BUNCH*** of random tracks and seeking to the middle of the track as soon as I could. I can not reproduce. The worst I can get is a `Player::seek called from invalid state` warning. And `librespot` recovers just fine from those. Can the tracks in question be played otherwise? If not it could be that they're just not Vorbis? Either that or your connection is unstable and/or slow. I looked up those errors in Lewton and Ogg (the decoder libs) and they're not very helpful. It could be anything from it's not a vorbis to any number of I/O errors.

kerem commented

2026-02-27 19:30:42 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (Dec 11, 2021):

After:

[2021-12-09T18:32:39Z DEBUG librespot_playback::player] command=Seek(98835)

You should have gotten something that looked like this if you haven't downloaded the file up to that point:

[2021-12-11T02:49:40Z DEBUG librespot_audio::fetch] Stream waiting for download of file position 11891636. Downloaded ranges: ([0, 249855]). Pending ranges: ([249856, 286719])
[2021-12-11T02:49:40Z DEBUG librespot_audio::fetch] Read at postion 11891636 completed. 27 bytes returned, 27 bytes were requested.

@JasonLG1979 commented on GitHub (Dec 11, 2021): After: ``` [2021-12-09T18:32:39Z DEBUG librespot_playback::player] command=Seek(98835) ``` You should have gotten something that looked like this if you haven't downloaded the file up to that point: ``` [2021-12-11T02:49:40Z DEBUG librespot_audio::fetch] Stream waiting for download of file position 11891636. Downloaded ranges: ([0, 249855]). Pending ranges: ([249856, 286719]) [2021-12-11T02:49:40Z DEBUG librespot_audio::fetch] Read at postion 11891636 completed. 27 bytes returned, 27 bytes were requested. ```

kerem commented

2026-02-27 19:30:42 +03:00

Author

Owner

@ghost commented on GitHub (Dec 11, 2021):

You are right, it is not easy to reproduce. It happens rarely it seems. If I figure out how to reproduce it every time, I will update this thread.

This is what happens when librespot does not crash and continues playing:

[2021-12-11T12:06:19Z DEBUG librespot_playback::player] command=Seek(659838)
[2021-12-11T12:06:19Z TRACE librespot_connect::spirc] Sending status to server: [kPlayStatusPlay]
[2021-12-11T12:06:19Z TRACE librespot_connect::spirc] ==> kPlayStatusPlay
[2021-12-11T12:06:19Z WARN  librespot_playback::audio_backend::alsa] Error writing from AlsaSink buffer to PCM, trying to recover, ALSA function 'snd_pcm_writei' failed with error 'EPIPE: Broken pipe'
ALSA lib pcm.c:8545:(snd_pcm_recover) underrun occurred

After this error, librespot does not crash and continues playing the track after it is downloaded properly.

@ghost commented on GitHub (Dec 11, 2021): You are right, it is not easy to reproduce. It happens rarely it seems. If I figure out how to reproduce it every time, I will update this thread. This is what happens when librespot does not crash and continues playing: ``` [2021-12-11T12:06:19Z DEBUG librespot_playback::player] command=Seek(659838) [2021-12-11T12:06:19Z TRACE librespot_connect::spirc] Sending status to server: [kPlayStatusPlay] [2021-12-11T12:06:19Z TRACE librespot_connect::spirc] ==> kPlayStatusPlay [2021-12-11T12:06:19Z WARN librespot_playback::audio_backend::alsa] Error writing from AlsaSink buffer to PCM, trying to recover, ALSA function 'snd_pcm_writei' failed with error 'EPIPE: Broken pipe' ALSA lib pcm.c:8545:(snd_pcm_recover) underrun occurred ``` After this error, librespot does not crash and continues playing the track after it is downloaded properly.

kerem commented

2026-02-27 19:30:42 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (Dec 11, 2021):

You are right, it is not easy to reproduce. It happens rarely it seems. If I figure out how to reproduce it every time, I will update this thread.

Can the tracks that crash librespot otherwise be played normally?

This is what happens when librespot does not crash and continues playing:
After this error, librespot does not crash and continues playing the track after it is downloaded properly.

The underruns are just the byproduct of trying to induce the error. Continually and rapidly changing tracks is opening and closing the ALSA device over and over again. That's just the device's way of saying "hold on a sec and let me catch my breath." They are otherwise unrelated to the decoder bug.

I'm inclined to say that this is either because the stream is not a vorbis stream or it's some bug in the decoder.

librespot only supports vorbis but Spotify also streams mp3 and aac depending on what type of content. Music is vorbis 99.9% of the time but occasionally it will try to serve up mp3 or aac in place of vorbis.

@JasonLG1979 commented on GitHub (Dec 11, 2021): > You are right, it is not easy to reproduce. It happens rarely it seems. If I figure out how to reproduce it every time, I will update this thread. Can the tracks that crash `librespot` otherwise be played normally? > This is what happens when librespot does not crash and continues playing: > After this error, librespot does not crash and continues playing the track after it is downloaded properly. The underruns are just the byproduct of trying to induce the error. Continually and rapidly changing tracks is opening and closing the ALSA device over and over again. That's just the device's way of saying "hold on a sec and let me catch my breath." They are otherwise unrelated to the decoder bug. I'm inclined to say that this is either because the stream is not a vorbis stream or it's some bug in the decoder. `librespot` only supports vorbis but Spotify also streams mp3 and aac depending on what type of content. Music is vorbis 99.9% of the time but occasionally it will try to serve up mp3 or aac in place of vorbis.

kerem commented

2026-02-27 19:30:42 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (Dec 11, 2021):

@roderickvd is in the process of figuring out the new API and the plan is to move to a decoder framework that can do mp3 aac and vorbis so I don't really want to do a deep dive into handling decoder errors only to have it all just be rewritten in a few weeks anyway. But in the future I would think that in the event of a fatal decoding error we should just skip to the next track instead of crashing or exiting completely.

@JasonLG1979 commented on GitHub (Dec 11, 2021): @roderickvd is in the process of figuring out the new API and the plan is to move to a decoder framework that can do mp3 aac and vorbis so I don't really want to do a deep dive into handling decoder errors only to have it all just be rewritten in a few weeks anyway. But in the future I would think that in the event of a fatal decoding error we should just skip to the next track instead of crashing or exiting completely.

kerem commented

2026-02-27 19:30:42 +03:00

Author

Owner

@ghost commented on GitHub (Dec 11, 2021):

Can the tracks that crash librespot otherwise be played normally?

Yes, it can! I tried and am sure.

@ghost commented on GitHub (Dec 11, 2021): > Can the tracks that crash `librespot` otherwise be played normally? Yes, it can! I tried and am sure.

kerem commented

2026-02-27 19:30:42 +03:00

Author

Owner

@ghost commented on GitHub (Dec 11, 2021):

we should just skip to the next track instead of crashing or exiting completely

I don't know why this isn't the case already. Even spotify client does that (some tracks are unplayable in certain countries, etc.)

@ghost commented on GitHub (Dec 11, 2021): > we should just skip to the next track instead of crashing or exiting completely I don't know why this isn't the case already. Even spotify client does that (some tracks are unplayable in certain countries, etc.)

kerem commented

2026-02-27 19:30:42 +03:00

Author

Owner

@roderickvd commented on GitHub (Dec 11, 2021):

@roderickvd is in the process of figuring out the new API and the plan is to move to a decoder framework that can do mp3 aac and vorbis so I don't really want to do a deep dive into handling decoder errors only to have it all just be rewritten in a few weeks anyway. But in the future I would think that in the event of a fatal decoding error we should just skip to the next track instead of crashing or exiting completely.

Yeah, we'll be pushing reporting decoding errors down to Symphonia.

But in the future I would think that in the event of a fatal decoding error we should just skip to the next track instead of crashing or exiting completely.

Please try #905.

@roderickvd commented on GitHub (Dec 11, 2021): > @roderickvd is in the process of figuring out the new API and the plan is to move to a decoder framework that can do mp3 aac and vorbis so I don't really want to do a deep dive into handling decoder errors only to have it all just be rewritten in a few weeks anyway. But in the future I would think that in the event of a fatal decoding error we should just skip to the next track instead of crashing or exiting completely. Yeah, we'll be pushing reporting decoding errors down to Symphonia. > But in the future I would think that in the event of a fatal decoding error we should just skip to the next track instead of crashing or exiting completely. Please try #905.

kerem commented

2026-02-27 19:30:42 +03:00

Author

Owner

@kingosticks commented on GitHub (Dec 11, 2021):

Pretty sure librespot handles regular track availability just fine. That's got nothing to do with decoding errors.

@kingosticks commented on GitHub (Dec 11, 2021): Pretty sure librespot handles regular track availability just fine. That's got nothing to do with decoding errors.

kerem commented

2026-02-27 19:30:42 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (Dec 11, 2021):

Pretty sure librespot handles regular track availability just fine. That's got nothing to do with decoding errors.

What they said.

Yes, it can! I tried and am sure.

Calm down. I was just cover the bases.

Like I said the error messages come from a upstream crate and aren't particularity descriptive or useful. It could be any number of a million and 1 different I/O errors.

@JasonLG1979 commented on GitHub (Dec 11, 2021): > Pretty sure librespot handles regular track availability just fine. That's got nothing to do with decoding errors. What they said. > Yes, it can! I tried and am sure. Calm down. I was just cover the bases. Like I said the error messages come from a upstream crate and aren't particularity descriptive or useful. It could be any number of a million and 1 different I/O errors.

kerem referenced this issue

2026-02-27 20:00:30 +03:00

[PR #449] [MERGED] Add blocking SinkActive|SinkInactive events #930

kerem referenced this issue

2026-02-27 20:00:30 +03:00

[PR #448] [CLOSED] Add SinkActive|SinkInactive events #932

Rows
Columns

[GH-ISSUE #902] Librespot crashes when seeking to a position that is not yet downloaded. #448