Video playback restarts if file is updated (streaming over torrent)

[Maleriandro]

Describe the bug
When viewing a video being downloaded (through torrent for example), the video starts playing, but every time a new piece of the video is downloaded, Screenbox starts the video from start again

How To Reproduce
Steps to reproduce the behavior:

1. Start downloading a mp4 video from torrent, setting it to sequential download.
2. Wait for start of video to have already downloaded
3. Before the download ends (might help setting a download speed limit), open video.
4. Start reproducing and wait for new piece to arrive.

Expected behavior
I would expect for the video to not restart. To continue playing even when its still being downloaded. Like VLC does.

Environment

• OS: Windows 11
• Device: Desktop PC
• App Version: 0.17.0.0

Additional context
ffprobe info:
Metadata:
encoder : libebml v1.4.5 + libmatroska v1.7.1
creation_time : 2026-01-11T08:31:45.000000Z
Duration: 00:24:07.08, start: 0.000000, bitrate: 7721 kb/s
Stream #0:0: Video: h264 (High), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn (default)
Metadata:
title : ToonsHub
Stream #0:1(jpn): Audio: aac (LC), 48000 Hz, stereo, fltp (default)
Stream #0:2(eng): Audio: aac (LC), 48000 Hz, stereo, fltp
Stream #0:3(eng): Subtitle: ass (ssa) (default)

[dosubot]

Hi @Maleriandro! I'm Dosu and I’m helping the Screenbox team.

Screenbox doesn't have any explicit logic to monitor file changes or restart playback when a file is updated during torrent streaming. This means the restart behavior is likely coming from how LibVLC interacts with the UWP/WinRT file system, especially when using winrt:// URIs for file access. Unlike desktop VLC, which handles growing files smoothly, Screenbox on UWP may not support incremental file updates as reliably due to platform I/O limitations and the way it accesses files through storage tokens. There are no configuration options or workarounds in Screenbox or its documentation that address this specific issue, and recent code changes do not touch this area. Known playback issues with MKV files and UWP's I/O bottlenecks may also contribute to the problem, but the app itself does not trigger restarts on file updates—it's likely a limitation of the underlying platform or LibVLC integration on UWP. For reference, see the discussion of related playback and file handling issues here and here.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}