CreateJobObjectA / SetInformationJobObject / AssignProcessToJobObject were called inside the per-start thread and their return values were ignored. Two consequences: 1. Each server crash-restart created a fresh kernel JobObject HANDLE that was never CloseHandle'd. The HANDLE went out of scope when the spawned thread exited, leaking a kernel object every crash. 2. On Win 7/8 (single-job systems) and inside parent jobs that disallow breakaway, AssignProcessToJobObject silently failed, so stremio-runtime could survive the shell's death and hold port 11470. Hoist the setup into ensure_parent_job_object() guarded by sync::Once so it runs exactly once per shell process, and check each return value explicitly with a clear log message when the OS-level safety net is degraded. The HANDLE is intentionally not closed: closing it while KILL_ON_JOB_CLOSE is set would terminate the shell itself. Closes #47 Closes #48 |
||
|---|---|---|
| .github/workflows | ||
| bin | ||
| bin-arm64 | ||
| images | ||
| mpv-arm64 | ||
| mpv-x64 | ||
| setup | ||
| src | ||
| .gitignore | ||
| build-arm64.ps1 | ||
| build.ps1 | ||
| build.rs | ||
| Cargo.lock | ||
| Cargo.toml | ||
| generate_descriptor.js | ||
| libmpv-2_arm64.zip | ||
| libmpv-2_x64.zip | ||
| README.md | ||
| rust-toolchain.toml | ||
| server.js | ||
| stremiover.js | ||
| upload.ps1 | ||
Stremio shell: new gen
A Windows-only shell using WebView2 and MPV
Goals:
- Performance
- Reliability
- Easy to ship
In all three, this architecture excels the Qt-based shell: it is about 2-5x more efficient depending on the use case, as it allows MPV to render directly in the window through it's optimal video output rather than using libmpv to integrate with Qt.
This is due to Qt having a complex rendering pipeline involving ANGLE and multiple levels of composing and drawing to textures, which inhibits full HW acceleration.
Meanwhile in this setup MPV uses whichever pipeline it considers to be optimal (like the mpv desktop app), which is normally d3d11, allowing full HW acceleration.
For web rendering, we use the native WebView2, which is Chromium based but shipped as a part of Windows 10: therefore we do not need to ship our own "distribution" of Chromium.
Finally, this should be a lot more reliable as it uses a much simpler and more native overall architecture.