Bug #357
Cannot resume after pause when server closes connection
0%
Description
Steps to reproduce:
1. Add network MP3 file to the playlist (using HTTP; the HTTP server supports Range)
2. Start playing
3. Pause and wait several seconds
4. Resume
The file keeps playing a few seconds and then the player abruptly switches to a next item in the playlist.
Expected behavior: the MP3 file continues playing.
I'm using the latest Git version on Arch Linux.
History
#1 Updated by John Lindgren almost 11 years ago
Link to the MP3 file, please?
#2 Updated by Bogdan Bezpartochnyy almost 11 years ago
I think I found the source of the problem. I've discovered that the issue is not specific to MP3s, but also affects any other format, and probably the bug is in Neon plugin.
The network resource I'm accessing is located on my home LAN, so it is impossible to access from the outside. All I can do is to provide HTTP headers:
$ curl -I "http://192.168.0.100/store/1.flac"
HTTP/1.1 200 OK
Date: Tue, 08 Oct 2013 23:50:43 GMT
Accept-Ranges: bytes
Content-Type: audio/flac
Last-Modified: Mon, 07 Oct 2013 08:45:09 GMT
Content-Length: 13903586
Connection: close
$ curl H Range:bytes=16 -I "http://192.168.0.100/store/1.flac"
HTTP/1.1 206 Partial Content
Date: Tue, 08 Oct 2013 23:53:13 GMT
Accept-Ranges: bytes
Content-Type: audio/flac
Content-Range: bytes 16-13903585/13903586
Last-Modified: Mon, 07 Oct 2013 08:45:09 GMT
Content-Length: 13903570
Connection: close
#3 Updated by John Lindgren almost 11 years ago
Unless the problem is reproducible on a public HTTP server, you are on your own here.
#4 Updated by Bogdan Bezpartochnyy almost 11 years ago
I think this is due to "Connection: close". Can't find any public server with such setup. I'll reconfigure my local server, but the problem in the player still exists.
#5 Updated by John Lindgren almost 11 years ago
Bogdan Bezpartochnyy wrote:
... but the problem in the player still exists.
Until you give me a way to reproduce this on a public HTTP server, I have no way of knowing what that "problem" is.
#6 Updated by Michael Schwendt almost 11 years ago
Obvious questions: Is it reproducible with 3.4.1 or is it specific to a snapshot from git? What does "audacious -V" print when you reproduce it? How long is "several seconds"?
I cannot reproduce it with 3.4.1.
Not so obvious question: Is it also reproducible with the following URL?
http://mschwendt.fedorapeople.org/tmp/blackhol.xmp.ogg
#7 Updated by Bogdan Bezpartochnyy almost 11 years ago
Yes, I can reproduce it with the above file. Although I waited about 10 minutes after pause, and after resume it kept playing for about 20-30 seconds.
#8 Updated by Michael Schwendt almost 11 years ago
You haven't shown the output from "audacious -V" for that yet.
How do you know when you need to wait "about 10 minutes" instead of only "several seconds"?
#9 Updated by Michael Schwendt almost 11 years ago
No easy to reproduce, but I could reproduce it with Audacious 3.4.1 and above URL after some random tries. "audacious -V" output:
[...pause...]
[...wait two minutes...]
main.c:540 [do_autosave]: Saving configuration.
[...resume playback...]
[...short time (30 seconds?) later...]
neon: <0x7f05d00010c0> Error while reading from the network
neon: <0x7f05d00010c0> Error while reading from the network. Terminating reader thread
neon: <0x7f05d00010c0> No request to read from, seek gone wrong?
[...next track started...]
probe.c:164 [file_find_decoder]: Probing file:///home/…xxx.ogg.
[...]
#10 Updated by John Lindgren almost 11 years ago
Is there a reason to believe that this "Error while reading from the network" is due to a bug and not just an actual network error?
#11 Updated by Michael Schwendt almost 11 years ago
Good question. ;) I have no answer yet and don't know what error condition neon has run into.
#12 Updated by Bogdan Bezpartochnyy almost 11 years ago
I've investigated the issue a bit. It seems that the error doesn't occur if after resume quickly move the playing position slider to another location.
Using Wireshark I have traced the TCP communication between the player and the server, and obviously server closes TCP connection after some time of inactivity (I guess the time depends on server's configuration). But if I move the playing position slider right after resume the player reestablishes the connection from scratch (sending SYN) and it won't fail.
#13 Updated by Michael Schwendt almost 11 years ago
It seems that the error doesn't occur if after resume quickly
move the playing position slider to another location.
Yes, because a seek pretty much restarts as you can see here:
https://github.com/audacious-media-player/audacious-plugins/blob/master/src/neon/neon.c#L1101
#14 Updated by John Lindgren almost 11 years ago
So the only problem here is that the server is closing the connection? If so, I don't think that's something we can really fix (or should bother to work around) on the Audacious side.
#15 Updated by John Lindgren almost 11 years ago
Another thought: if you want to pause for a long time and force a new TCP connection when you resume, you can just stop the song and restart from the same position by double-clicking the playlist tab or pressing CTRL-SHIFT-ENTER.
#16 Updated by Bogdan Bezpartochnyy almost 11 years ago
Are there any serious drawbacks of establishing a new TCP connection every time a user resumes playing just like during seeking?
#17 Updated by John Lindgren almost 11 years ago
Yes. Pause is not supposed to close and reopen any file handles, internet connections, audio devices, etc. If you don't care about performance and want to reset everything that might fail while paused, use stop instead.
#18 Updated by John Lindgren almost 11 years ago
- Subject changed from Playing MP3 files over the network issue to Cannot resume after pause when server closes connection
- Status changed from New to Rejected