Playing a http stream stops on socket connection close

[DsChAeK]

Hi,

I have a problem listening to a HTTP-stream with VLC. The HTTP-stream is created by a Java server application that encodes an audio-file and
immediately sends the accumulating encoded data to the http connection.
Now the encoding and the sending of the data finishes earlier (like 10 seconds) than the playing VLC reaches the end of the stream, and the server is
closing the connection because there is no data to send anymore. VLC must buffer the remaining data to play, because the connection is in blocked mode
and data is only sent when it is actually read.

The problem now is, that VLC stops playing immediately when the server connection is closed (main error: recv failed (10054)), instead of noticing that
there is no data available anymore and playing the remaining buffered data.

I think this is a problem of VLC, because I tried to play the stream with Winamp and Windows Media Player, and had no problems.
Nothing I tried worked out yet and I also found no setting for VLC to solve this, so any comments about this problem are welcome.

Thanks in advance.
DsChAeK

[VLC_help]

Have you tested nightly builds?
http://nightlies.videolan.org/

[DsChAeK]

Yes, I tested the latest version right now, and as soon as the connection is reset by peer, vlc is in an endless error loop (main error: Read error: Connection reset by peer) and stops playback.
I tried to solve the problem on the server side, but there is no way to get it 100% sync.

[VLC_help]

You might want to report this as a bug to Trac.

[secaro]

I have the same problem. If the connection drops the client will never restart the stream. Needs to be manually restarted. It just says "recv failed (10054)"

[DsChAeK]

https://trac.videolan.org/vlc/ticket/2330

No help from vlc side...:/
Nevertheless vlc could handle this error in a better way, like winamp/mpc.

[DsChAeK]

I solved the problem!

Use clientSocket.shutdownOutput() instead of streamOutput.close()

Use shutdownOutput(). This method has the same effect as close() in that a FIN is sent to indicate that this peer has finished sending, but it is still possible to read from the socket until such time as the remote peer sends a FIN and end-of-file is read from the stream. Then the socket can be closed with Socket.close()