Project

General

Profile

Bug #357

Cannot resume after pause when server closes connection

Added by Bogdan Bezpartochnyy over 10 years ago. Updated over 10 years ago.

Status:
Rejected
Priority:
Minor
Assignee:
-
Category:
-
Target version:
Start date:
October 07, 2013
Due date:
% Done:

0%

Estimated time:
Affects version:

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 over 10 years ago

Link to the MP3 file, please?

#2 Updated by Bogdan Bezpartochnyy over 10 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 over 10 years ago

Unless the problem is reproducible on a public HTTP server, you are on your own here.

#4 Updated by Bogdan Bezpartochnyy over 10 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 over 10 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 over 10 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 over 10 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 over 10 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 over 10 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 over 10 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 over 10 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 over 10 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 over 10 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 over 10 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 over 10 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 over 10 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 over 10 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 over 10 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

Also available in: Atom PDF