Audacious - OLD, PLEASE USE GITHUB DISCUSSIONS/ISSUES

Link to the MP3 file, please?

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

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

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.

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.

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

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.

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"?

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.
[...]

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?

Good question. ;) I have no answer yet and don't know what error condition neon has run into.

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.

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

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.

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.

Are there any serious drawbacks of establishing a new TCP connection every time a user resumes playing just like during seeking?

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.