Server Version: 1.43.0.10492
Player Version: PlexWeb/4.156.0
I noticed that Plex Web appears to apply a 10-second timeout when fetching video segments (.m4s files). From what I observed, some video segments are around 6.4 MiB, which means they require a sustained download speed of roughly 650 KiB/s to complete within 10 seconds.
This causes a problematic failure mode when accessing Plex remotely over a slower but otherwise stable connection. For example, if the connection speed is around 620 KiB/s, the segment cannot finish downloading before the 10-second timeout. Plex then aborts the request and starts fetching the same segment again from the beginning. As a result, playback gets stuck retrying the same segment indefinitely, even though the connection would be fast enough to play the video if the client simply waited a bit longer for the segment to finish downloading.
I do not think a fixed total request timeout is appropriate for media segment downloads, especially when the connection is still making steady progress. A better approach would be to use an idle/progress timeout instead: only abort the request if no data has been received for a certain amount of time, or if the transfer has clearly stalled. If the request does need to be aborted, the client should ideally resume using HTTP Range requests or otherwise avoid discarding already downloaded data when retrying the same segment.
In short, I think the best practice would be:
- Do not abort an active segment download just because the total elapsed time exceeds 10 seconds.
- Use an idle timeout or progress-based timeout instead of a fixed total timeout.
- If a segment download is interrupted, resume from the downloaded byte range when possible, rather than restarting from the beginning.
- Alternatively, adapt the timeout based on segment size and observed network throughput.
Please consider changing this behavior, as the current implementation makes playback impossible on slower but stable remote connections.
