fix: recover shell early eof

[kKaskak]

No description provided.

[kKaskak]

EOF Handling Notes

What we saw:

• mpv emitted mpv-event-ended with reason eof before playback was actually near the end.

• In user logs, FFmpeg also showed real transport failures:

  • Failed to resolve hostname ...
  • Unknown error
  • Seek failed
  • then mpv reported video/audio EOF and terminated demuxers.

• So there are two separate issues:

  1. Stremio UI treats early mpv EOF as real playback end.
  2. Shell/mpv/FFmpeg can still lose the HTTP stream and fail to recover, causing black screen.

What we tried:

• First fix attempted to recover early EOF by calling loadfile again at the last known timestamp.
• That stopped the false “loading failed” UI state, but caused flicker and restarted the mpv item/cache path.
• Practically, this looked like reloading/redownloading the video, so we removed it.

What we considered:

• Passing FFmpeg HTTP reconnect options through mpv with stream-lavf-o.
• This might help socket/network failures, but it is a separate transport recovery fix.
• Also, for glutin shell specifically, stream-lavf-o may need shell-side support because the Rust IPC validates allowed mpv property names.
• We decided not to include socket recovery in this stremio-video branch.

What we shipped in the branch:

• EOF-only fix in stremio-video.
• When shell reports EOF, we now check known time-pos against known duration.
• If EOF happens more than 1 minute before reported duration, we suppress ended.
• If EOF happens within 1 minute of reported duration, we treat it as real end.
• Package bumped to 0.0.82.

Remaining issue:

• If FFmpeg/mpv loses the HTTP stream and cannot reconnect/seek, playback can still go black.
• That needs a separate shell/server/mpv transport recovery fix, not this EOF UI guard branch.

[Aztup]

Tested and fixed the issue