http timeouts

[revel8n]

Tried both registering a new VideoLAN Gitlab account and linking my existing Gitlab account in order to reply to/create an Issue, but was unsuccessful.

i believe i am running into the same problem mentioned in this issue: https://code.videolan.org/videolan/vlc/-/issues/27661

This happens in the standalone VLC player and when attempting to play media with the libraries.

Did a quick look through the code flow, and wanted to verify if what i am seeing is correct.

The problem i am seeing relates to the different paths taken between HTTP and HTTPS connections when opening a stream i believe.

HTTPS connections eventually call vlc_tls_ClientSessionCreate which does indeed attempt to retrieve the ipv4-timeout setting in order to timeout.

HTTP connections eventually call vlc_tls_Write instead though, which does not retrieve the timeout setting and thus ends up waiting indefinitely.

The last http debug log message below echoes the "outgoing request:" present in vlc_h1_stream_open right before it calls vlc_tls_Write.

Am i understanding the connection flow properly, or could there be something else going on that is causing this behavior?

Any information you could provide would be greatly appreciated.

Thanks in advance.

[revel8n]

HTTPS:
https://code.videolan.org/videolan/vlc/ ... mgr.c#L184
https://code.videolan.org/videolan/vlc/ ... nmgr.c#L69
https://code.videolan.org/videolan/vlc/ ... tls.c#L247
https://code.videolan.org/videolan/vlc/ ... tls.c#L166
https://code.videolan.org/videolan/vlc/ ... tls.c#L193

[revel8n]

HTTP:
https://code.videolan.org/videolan/vlc/ ... mgr.c#L253
https://code.videolan.org/videolan/vlc/ ... onn.c#L405
https://code.videolan.org/videolan/vlc/ ... onn.c#L157
https://code.videolan.org/videolan/vlc/ ... eam.c#L129

[revel8n]

Log:

playlist debug: found valid M3U playlist
main debug: using stream_filter module "playlist"
main debug: stream filter added to 000002c0d7805bb0
main debug: looking for stream_filter module matching "any": 24 candidates
main debug: no stream_filter modules matched
main debug: looking for stream_directory module matching "any": 1 candidates
main debug: no stream_directory modules matched
main debug: attachment of directory-extractor failed for https://iptv-org.github.io/iptv/categories/sports.m3u
main debug: looking for stream_filter module matching "record": 24 candidates
main debug: using stream_filter module "record"
main debug: creating demux: access='https' demux='any' location='iptv-org.github.io/iptv/categories/sports.m3u' file='\\iptv-org.github.io\iptv\categories\sports.m3u'
main debug: looking for demux module matching "m3u": 55 candidates
es debug: cannot peek
es debug: cannot peek
es debug: cannot peek
es debug: cannot peek
es debug: cannot peek
mod debug: MOD validation failed (ext=m3u)
main debug: using demux module "directory"
main debug: looking for meta reader module matching "any": 2 candidates
lua debug: Trying Lua scripts in C:\Users\...\AppData\Roaming\vlc\lua\meta\reader
lua debug: Trying Lua scripts in C:\programs\x64\VideoLAN\VLC\lua\meta\reader
lua debug: Trying Lua playlist script C:\programs\x64\VideoLAN\VLC\lua\meta\reader\filename.luac
main debug: no meta reader modules matched
main debug: `https://iptv-org.github.io/iptv/categories/sports.m3u' successfully opened
http debug: in DATA (0x00) frame of 38014 bytes, flags 0x01, stream 1
http debug: stream 1 closed by peer
prefetch debug: end of stream
main debug: deleting item `sports.m3u'
main debug: EOF reached
main debug: removing module "directory"
main debug: removing module "record"
main debug: removing module "playlist"
main debug: removing module "prefetch"
main debug: incoming request - stopping current input
main debug: removing module "access"
http debug: local stream 1 shut down
main debug: incoming request - stopping current input
http debug: out RST_STREAM (0x03) frame of 4 bytes, flags 0x00, stream 1
main debug: incoming request - stopping current input
http debug: local shutdown
http debug: out GOAWAY (0x07) frame of 8 bytes, flags 0x00, global
main debug: incoming request - stopping current input
main debug: dead input
main debug: processing request item: :Šport (1080p), node: Playlist, skip: 0
main debug: rebuilding array of current - root Playlist
main debug: rebuild done - 232 items, index 0
main debug: starting playback of new item
main debug: resyncing on :Šport (1080p)
main debug: :Šport (1080p) is at 0
main debug: creating new input thread
main debug: Creating an input for ':Šport (1080p)'
main debug: requesting art for new input thread
main debug: using timeshift granularity of 50 MiB
main debug: using timeshift path: C:\Users\G9FA8~1.CUR\AppData\Local\Temp
main debug: `http://88.212.7.10/live/test_rtvs_sport ... ylist.m3u8' gives access `http' demux `any' path `88.212.7.10/live/test_rtvs_sport_hevc/playlist.m3u8'
main debug: creating demux: access='http' demux='any' location='88.212.7.10/live/test_rtvs_sport_hevc/playlist.m3u8' file='\\88.212.7.10\live\test_rtvs_sport_hevc\playlist.m3u8'
main debug: looking for access_demux module matching "http": 15 candidates
main debug: looking for meta fetcher module matching "any": 1 candidates
main debug: no access_demux modules matched
main debug: creating access: http://88.212.7.10/live/test_rtvs_sport ... ylist.m3u8
main debug: (path: \\88.212.7.10\live\test_rtvs_sport_hevc\playlist.m3u8)
main debug: looking for access module matching "http": 27 candidates
lua debug: Trying Lua scripts in C:\Users\...\AppData\Roaming\vlc\lua\meta\fetcher
lua debug: Trying Lua scripts in C:\programs\x64\VideoLAN\VLC\lua\meta\fetcher
main debug: no meta fetcher modules matched
main debug: looking for art finder module matching "any": 2 candidates
http debug: resolving 88.212.7.10 ...
http debug: outgoing request: GET /live/test_rtvs_sport_hevc/playlist.m3u8 HTTP/1.1 Host: 88.212.7.10 Accept: */* Accept-Language: en_US User-Agent: VLC/3.0.21 LibVLC/3.0.21 Range: bytes=0-
lua debug: Trying Lua scripts in C:\Users\...\AppData\Roaming\vlc\lua\meta\art
lua debug: Trying Lua scripts in C:\programs\x64\VideoLAN\VLC\lua\meta\art
lua debug: Trying Lua playlist script C:\programs\x64\VideoLAN\VLC\lua\meta\art\00_musicbrainz.luac
lua debug: skipping script (unmatched scope) C:\programs\x64\VideoLAN\VLC\lua\meta\art\00_musicbrainz.luac
lua debug: Trying Lua playlist script C:\programs\x64\VideoLAN\VLC\lua\meta\art\01_googleimage.luac
lua debug: skipping script (unmatched scope) C:\programs\x64\VideoLAN\VLC\lua\meta\art\01_googleimage.luac
lua debug: Trying Lua playlist script C:\programs\x64\VideoLAN\VLC\lua\meta\art\02_frenchtv.luac
lua debug: skipping script (unmatched scope) C:\programs\x64\VideoLAN\VLC\lua\meta\art\02_frenchtv.luac
lua debug: Trying Lua playlist script C:\programs\x64\VideoLAN\VLC\lua\meta\art\03_lastfm.luac
lua debug: skipping script (unmatched scope) C:\programs\x64\VideoLAN\VLC\lua\meta\art\03_lastfm.luac
main debug: no art finder modules matched
main debug: looking for meta fetcher module matching "any": 1 candidates
lua debug: Trying Lua scripts in C:\Users\...\AppData\Roaming\vlc\lua\meta\fetcher
lua debug: Trying Lua scripts in C:\programs\x64\VideoLAN\VLC\lua\meta\fetcher
main debug: no meta fetcher modules matched
main debug: looking for art finder module matching "any": 2 candidates

[revel8n]

Looks like it actually gets past the call to vlc_tls_Write, but since it has the same issue within vlc_tls_Read and others, it eventually ends up waiting nonetheless.

vlc_https_headers_recv eventually calls that and wait indefinitely: https://code.videolan.org/videolan/vlc/ ... conn.c#L57
called from the vlc_h1_stream_wait callbackk method: https://code.videolan.org/videolan/vlc/ ... onn.c#L183

https://code.videolan.org/videolan/vlc/ ... tls.c#L228

readv fails, but errno is typically EAGAIN (WSAEWOULDBLOCK from recvmsg on Windows)) constantly so it never errors out, and there is nothing else to cause it to timeout or stop until stopped from the player.

Unfortunately i do not understand the vlc object model enough to know what method would even be available at this point in these methods in order to gain access to the timeout variable values.

[revel8n]

Looks like neither the HTTP nor the HTTPS access plugins handle the timeout option consistently in all cases.

The information presented so far appears to be related to the way the HTTPS access plugin attempts to handle accessing an HTTP connection. Currently it will not properly timeout in some cases.
i hardcoded the timeout check in a manner similar to that used elsewhere and this allowed it to eventually timeout.

But then the HTTP access module makes an attempt next.

On connect it initially makes an attempt to use the timeout: https://code.videolan.org/videolan/vlc/ ... tcp.c#L141

Called from here: https://code.videolan.org/videolan/vlc/ ... ttp.c#L711

The problem technically is that it appears it is not the initial write/connect that is the issue, but the attempt to read/gets afterwards. As stated above the vlc_tls_* methods do not attempt to make use of the configured timeouts, but outside of the net_ConnectTCP method, similar to the tls methods, the net_Read, net_Write, and net_Gets do not make any use of the configured timeouts either.

The call here also ends up blocking: https://code.videolan.org/videolan/vlc/ ... ttp.c#L732

But luckily i believe the default timeouts take effect and it eventually exits the net_Gets method after about 30 seconds instead of getting stuck indefinitely.

i have not tracked back to see if any attempt is ever made to configure the timeouts on the socket itself.

[revel8n]

For those interested, the discussion moved here: https://code.videolan.org/videolan/vlc/-/issues/28777

Should hopefully be resolved once the backport is merged: https://code.videolan.org/videolan/vlc/ ... uests/5994

Thanks to everyone for the help!