Resuming https audio stream after pause doesn't re connect.

added Component::Input: network streams label

Also I noticed this problem more often after longer pauses. i.e. pausing in the order of 10/15 minutes seems to work as expected, whereas resuming the next day after ~12h (and post suspend-to-ram) doesn't seem to work.

I'm also happy to help debugging and run any tests, HTH!

Another symptom I noticed: unfortunately my ISP cycles its NAT pool every four hours, and the end user effect is that TCP connections are left hanging, including VLC streams.

This is the socket status as reported by ss:

tcp   ESTAB      0      0                          192.168.1.104:50000     198.24.44.211:https 
  users:(("vlc",pid=262412,fd=14)) uid:1000 ino:1540176 sk:2002
  cgroup:/user.slice/user-1000.slice/session-2.scope <->
  ts sack cubic wscale:9,10 rto:532 rtt:202.628/44.042 ato:176
  mss:1328 pmtu:1500 rcvmss:1328 advmss:1448 cwnd:10 bytes_sent:667
  bytes_acked:668 bytes_received:79180429 segs_out:36383 segs_in:59926
  data_segs_out:4 data_segs_in:59921 send 524kbps lastsnd:4262676
  lastrcv:398272 lastack:398272 pacing_rate 1.05Mbps delivery_rate 100kbps
  delivered:5 app_limited busy:672ms rcv_rtt:196.248 rcv_space:102422
  rcv_ssthresh:614704 minrtt:190.885

The situation is certainly unfortunate with connections just left hanging, and I couldn't get TCP timeouts to kick in (i.e. the socket never changes state as far as I can tell).

VLC can't reconnect if it didn't get disconnected. It's hard to reproduce for testing, but AFAIK, VLC does reconnect automatically when HTTP or HTTPS fails.

Fair enough! I'll look for a way to get a reproducer locally. Do you have any pointers/suggestions on which/what debug logging to enable at runtime to understand better what VLC thinks of the situation? thank you!

VLC logs should show it. But if nothing happens then nothing happens, so I'm not clear what you're expecting here.

I'm looking generally for more information from VLC that might help debugging, though indeed I just experienced the disconnection again and from debug messages this is all I got:

pulse debug: changing sink 0: alsa_output.pci-0000_00_1f.3.analog-stereo (Built-in Audio Analog Stereo)
pulse debug: changing sink 0: alsa_output.pci-0000_00_1f.3.analog-stereo (Built-in Audio Analog Stereo)
pulse debug: underflow

Some more information in case it is useful: stream status is unchanged (i.e. the "pause" button is displayed in the UI, clicking it even multiple times doesn't do anything), stopping/restarting the stream though does resume as expected.

I'll be working to get a way to reproduce this behaviour and report back

The easiest reproducer on linux I found so far is to DROP packets from the stream source, i.e. the following:

# get the stream source ip/port
lsof -p $(pidof vlc) -a -i -n -w
# block via iptables, the following is for the stream I'm testing with at
# https://ice5.somafm.com/gsclassic-128-mp3
sudo iptables -I INPUT 1 -s 198.24.44.211 -p tcp --sport 443 -j DROP

# clean up by deleting the above rule
sudo iptables -D INPUT 1

hope that helps! thank you

Repezting myself here, but if VLC says nothing, it probably means nothing happens.

Did the socket go to timed-out state or vanish entirely and VLC not report anything?? That would seem odd.

The socket is reporting as established (for example from ss or lsof) even after the DROP rule is in place.

I have reproduced the issue while straceing vlc, the socket is on fd 14 and indeed still in status ESTABLISHED:

vlc     262412 filippo   14u     IPv4            1707398      0t0     TCP 192.168.1.104:59098->ice5.somafm.com:https (ESTABLISHED)

I'm attaching a trimmed version of the strace log at around the time I have installed the DROP rule, it seems to me that after this line the socket fd is never polled again:

371165 14:42:30.739397 poll([{fd=14<socket:[1707398]>, events=POLLIN}, {fd=15<anon_inode:[eventfd]>, events=POLLIN}], 2, -1 <unfinished ...>

I have the full strace available too, hope that helps!

vlc-drop.strace

If the poll never wakes up as the "unfinished" let it suppose, VLC has no way to know that something went wrong. It's still stuck inside the syscall.

VLC cannot reconnect if the OS never informs it that the connection died.

Thank you for taking a look, I agree on the network/input level VLC is stuck and can't tell things went sideways. On a user higher level though things certainly did go wrong: playing has stopped

VLC cannot be smarter than the operating system short of become one itself (which will hopefully never happen :)).

I too don't look forward to VLC becoming an OS :D. Regarding this issue (i.e. for whatever reason a network stream stops receiving data and playing stops) I get the impression it won't get fixed? If that's the case that's a bummer, though feel free to close the issue and thank you anyways

As I said, it's hard to test, but AFAIK, VLC does reconnect if it gets disconnected. If it doesn't get disconnected (which is what happens here), then it will wait until the user stops.

We could forcefully send a PING on resume from pause to force a health check of the connection, but that would only work on HTTP/2, and in all likelihood, exceed the user's patience.

Thank you for the explanation @Courmisch, it seems VLC is working as intended in this case (?) From an end user's point of view I must say I find the high-level behavior (the stream stops, I have to stop/play again) disappointing. At any rate, I get that there doesn't seem to be feedback from higher layers / playback that something has happened. IMHO good to close the issue

Resuming https audio stream after pause doesn't re connect.

Child items 0

Activity