Tested on Apple TV and iPhone.
When seeking, infuse abandons the previous streaming TCP socket (ie. stops doing read(2)) without closing (close(2)). When using
ss to monitor open TCP connections on the webdav server, an open TCP socket with a filled read buffer is observed, one for each seek.
There seems to be other cases as well - for example, upon starting a new video, 2 HTTP requests are done with 2 different sockets, with different Content-Range headers, but then one of the HTTP requests (the first one?) is similarly abandoned (filled read buffer on the server side, unclosed).
Upon backing out of the video, all sockets (including stale) are closed at once.
It should be infuse’s responsibility to close these sockets rather than having the server be responsible for timing them out and closing them. I’m convinced this is an issue with infuse because I’ve never observed this issue with VLC and mpv (old sockets are always closed immediately on seek), but happens every time I play a video with infuse.
This can have a large impact on streaming speed as the number of these sockets pile up.