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#47Closes#48
stdout.read(...).unwrap_or(!0) substituted usize::MAX on Err, then
`if on > buffer.len() { continue; }` swallowed it and looped back into
read(). On a sticky IO error (broken pipe, EBADF) the thread spun a
CPU core forever and the accumulated logs were never flushed.
Match Ok(0)/Ok(n)/Err(e) explicitly: break on EOF, break on error after
logging, and treat any other Ok(n) as bytes read. Same change for
stderr.
Closes#51
Commit 0b882f3 synthesized an Event::EndFile(Error) whenever
event_context.wait_event returned libmpv2::Error::Raw and forwarded it
to the web layer. MPV is fully able to continue playback after such
transient errors (its demuxer cache is intact), so fabricating an
end-of-file caused long-running HTTP streams (e.g. RealDebrid) to flip
to a blocking "Loading failed" overlay mid-playback. Revert that branch
to the prior log-and-continue behavior.
Also downgrade PlayerEnded errors from critical:true to critical:false
so genuine mpv_end_file_reason::Error surfaces as a 3s toast in
stremio-web (Player.js), letting the user retry, instead of an
unrecoverable full-screen overlay.
