Bugzilla – Bug 7571
decoder underrun not waiting long enough/not configurable
Last modified: 2008-03-28 10:35:18 UTC
I'm often running into an annoying problem while listening to podcasts. For some reason (latency, who knows), the decoder gets an underrun, tells the server, which then goes to the next item on the playlist. I often only have the podcast as the only item on my playlist, so the result of this is that the podcast abruptly stops and then restarts at the beginning. It would be really nice if the decoder could be configured to wait for a while (perhaps stalling) before it gives up. I suspect that the buffer still has data that is being when the server tells it to play the next item. Is the underrun reported when it happens (even if there is still data in the buffer to play)?
by the way, here's some data from the log: [08-03-20 14:44:59.5946] Slim::Player::Source::decoderUnderrun (582) 00:04:20:16:00:eb: Decoder underrun while this mode: playout-play [08-03-20 14:44:59.5959] Slim::Player::Source::nextsong (1586) The next song is number 0, was 0 [08-03-20 14:44:59.5977] Slim::Player::Source::nextsong (1586) The next song is number 0, was 0 [08-03-20 14:44:59.5993] Slim::Player::Source::skipahead (903) **skipahead: opening next song
in addition, for this stream, the server KNOWS how long it is, so the firmware should be able to make a guess that there is more coming. [08-03-20 12:49:50.3495] Slim::Player::Client::streamingProgressBar (1069) Duration of stream set to 2642 seconds based on length of 42278435 and bitrate of 128000 [08-03-20 12:49:50.3505] Slim::Player::Squeezebox2::directHeaders (396) Got a stream type: mp3 bitrate: 128000 title: [08-03-20 12:49:50.3523] Slim::Player::Squeezebox2::directHeaders (455) Beginning direct stream! [08-03-20 12:49:50.3648] Slim::Player::Squeezebox::buffering (286) Buffering... 0 / 49152
Unfortunately there isn't much we can do as firmware only sends a decoder underrun event if several conditions are met, one being that the stream connection has been closed (indicating that the stream is done).
fair enough, if the remote end has closed the stream, but this seems to happen not too infrequently on streams from various sites (in mid podcast). Could you double check to make sure that there isn't some error in the coding? It seems strange that servers would doing this as often as it's happened. Thanks.