MPD icon indicating copy to clipboard operation
MPD copied to clipboard

Playing a stream, pausing, and replaying later causes the buffered content to be played and then stops

Open Linkandzelda opened this issue 6 years ago • 8 comments

It's a bit hard to describe this, because I've only been using MPD for about a week. I often notice when pausing a stream and coming back to it later, it will play where it left off for about 10-20 seconds and then the stream will just stop playing and I have to press play again. At this point the stream is re-evaluated and the current content is played.

Is this a bug, intended behaviour? If I do seek 0 and then play again, it will ignore the old content and play the current content.

I have this in my config:

audio_buffer_size "8192"
buffer_before_play "25%"

Linkandzelda avatar Jul 25 '18 11:07 Linkandzelda

First a warning: do not mess with the buffer settings! Remove them.

The behavior you're seeing is hard to classify. MPD does not bother to check whether a http:// song is a stream or just a file stored remotely. If you pause MPD, it will simply pause the transfer and will later continue playing from there, just like it would with a regular file. The problem is that by the time you resume playback, the streaming server has decided to close the connection. MPD will then play what has already been received, stop this song and play the next one in the queue. From MPD's point of view, that's normal and reasonable behavior, and MPD rather finds it rude that the server closed the connection, which on the other hand may be reasonable from the server's point of view.

So when you press "pause" and later resume, what do you expect to happen?

MaxKellermann avatar Jul 25 '18 11:07 MaxKellermann

Thanks for the insight. I'm on OSX, and there is a bit of an issue with crackling and skipping. That's the reason I increased the buffer size, as it resolved my issue completely in that regard.

As for what I expect, I'm coming from iTunes. It works the same way except that when the connect is closed to the server (presumably because of the same thing, it looks if its a remote file or stream as the same), then it will reconnect to the stream if it stopped. So in iTunes I get half the same situation: paused stream will resume at the old content until it runs out and the difference is it will try once more to re-connect and that results in playing the current stream content.

From an expected user experience point of view I personally believe that if I press play on any paused remote stream, that an attempt to reconnect should be performed at least once right after. I don't know enough about the internals of MPD but I would assume that it knows if it's still got a connection to the remote file/stream, which would allow for a check to be reconnect be performed if the connection no longer exists. If content is a remote file and not a stream then the end is the end, and it will stop. If its a stream it will carry on playing like normal, and if the stream is offline then I assume that would also be the "end" and the stream should be stopped.

Linkandzelda avatar Jul 25 '18 11:07 Linkandzelda

I just ran into an analogous issue, with similar requested behavior. I'm streaming static files over http, and if I pause for a while, mpd stops receiving, and the remote server closes the connection. What I'd like mpd to do, if faced with a pause on curl-storage (maybe less reasonable for curl-input), is to close the connection to the remote server, then reopen it later with a Range: header to resume where it left off.

jwise avatar Aug 17 '18 19:08 jwise

What is the status of this bug/feature request? Has it been added to 0.21?

madduck avatar Apr 13 '20 10:04 madduck

So when you press "pause" and later resume, what do you expect to happen?

For playback to continue from whatever offset it was at.

This can be done over HTTP in a way that handles both ephemeral streams and static files, with https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Range -- streams won't match any old etag (they likely never had one in the first place), and thus would resume playing whatever is currently live.

tv42 avatar Apr 20 '22 22:04 tv42

Seeing this as well, I'd be perfectly happy if it dropped the buffer and started playing live. Pause doesn't really make sense for most of the streams I listen to.

dpgeekzero avatar Jul 22 '22 14:07 dpgeekzero

o when you press "pause" and later resume, what do you expect to happen?

This issue is messing up my streams. I expect that streams can be dropped or dropped after some seconds of pause. And a new connection is made.

Bram-diederik avatar Aug 26 '22 11:08 Bram-diederik

Hello,

when you press "pause" and later resume, what do you expect to happen?

The stream resumes where it was. If the connection is dropped, then the buffer is consumed and then it reconnects to get live data.

Current behavior is similar but it switches to next song in playlist after consuming the buffer. It would be great if this behavior was changed, or if it could be modified by a setting!

Thank you for your time!

Best, ~Nico

NicolasCARPi avatar Dec 15 '22 13:12 NicolasCARPi