VLC does something really wrong, when HTTP source is gone.

[postscripter]

Hello!

I have a playlist, which contains two elements:

http://bookradio.hostingradio.ru:8069/fm
file:///home/me/scripts/lost.wav

And I also turned on the option "Repeat playlist".

My point of view is like this: when HTTP source is gone (I pulled off a cable) VLC should go on to the next item. But instead it stuck on the first item forever in "playing" state, until I manually click Next.

On Windows it's even worse. Just imagine, this guy will repeat the last 15 seconds until the source is back online!!! That's ridiculous!

VLC 2.2-3.0/Ubuntu+Xfce and VLC 2.1/Windows.

[postscripter]

So, the question is, how to make it failure-safe? I'd like it to switch to the next stream if the first one becomes unavailable.

[Rémi Denis-Courmont]

Unless you enabled HTTP continuous mode, VLC will switch to the next item when the connection fails or times out. Of course, that might take some time, depending on TCP/IP stack.

[postscripter]

Rémi Denis-Courmont

I saw the checkbox "HTTP: try to reconnect". It is disabled. And frankly, vlc seems not to pay any attention to it, I tried.

30 min - that's how much I have been waiting. Should be enough for any tcp stack.

[postscripter]

Oh, are you a developer? Could you check it, please? Just make a playlist out of those two and accidentally unplug the internet cable (for more than 30 seconds!)

[Rémi Denis-Courmont]

It sounds like the TCP connection is still valid - you can check with netstat or your OS equivalent.

[postscripter]

It sounds like the TCP connection is still valid

Indeed. Other software's connections became FIN_WAIT within a dozen of seconds or so after the disconnect, but VLC's one never closed. It's bloody immortal...(

Code: Select all

netstat -tvanpe Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name .... tcp 0 0 0.0.0.0:32400 0.0.0.0:* LISTEN 128 24432 2092/Plex Media Ser tcp 0 0 127.0.0.1:58452 127.0.0.1:48401 ESTABLISHED 1000 1892745 22444/sshd: sweetho tcp 0 0 192.168.1.10:45640 5.178.80.42:8069 ESTABLISHED 1000 22067 1762/vlc tcp 0 1 192.168.1.10:44340 82.94.168.60:443 FIN_WAIT1 0 0 2092/Plex Media Ser tcp 0 0 127.0.0.1:48401 127.0.0.1:58452 ESTABLISHED 1000 1891302 22755/x2goagent ....

[Rémi Denis-Courmont]

In other words, there is nothing wrong. It's just waiting for more data.

[postscripter]

It's just waiting for more data.

What for? The remote server will shut the connection down unilaterally very soon, and there won't be more data.

Others close their connections by timeout (see "plex media" in the table above). Why VLC is so different?

Isn't the option "tcp connection timeout" which by default = 5000 the one which should limit our waiting time?

[Rémi Denis-Courmont]

The TCP connection timeout is for establishment, not keeping open.

[postscripter]

From your answer I guess there's nothing for "keeping open"? To prevent the behaviour I described in the previous message? I mean, at the moment the Internet is restored, the connection is confidently dead. The player will stick forever (or may be for 2 hours, it depends on socket options & tcp defaults). Can not wrap my head around it, how come, there is no timeout?

[Rémi Denis-Courmont]

How would VLC distinguish working connection with no data from broken connection? The HTTP layer knows nothing of the expected bit rate. It's the TCP/IP stack's job to notify the player of breakage.