v1.0.4

Fixes

• HLS playback on Windows: ffmpeg now receives forward-slash paths, fixing
  the 404 on fragment load that hit videos with soft subtitles or certain
  codec combinations (mkv, avi mpeg4/mp3).
• Native HLS support is now asked of the platform (WebKit) instead of the
  playback engine, avoiding a mismatch that could pick the wrong playback
  path.
• Pinned ffmpeg build repointed to a live BtbN release tag; the previous one
  had aged out of BtbN's history and broke CI/build fetches.

v0.1.3

Playback on Windows.

Every film that needed ffmpeg failed with This file could not be played. Only files handed over untouched (an MP4 the webview opens by itself) played at all.

The cause: Chromium, and so WebView2, answers "maybe" to canPlayType("application/vnd.apple.mpegurl") whether or not that build can open a playlist. The player read that as native HLS, skipped hls.js, and gave the element an .m3u8 it did nothing with. The answer now comes from the backend, which knows the platform at compile time.

Also in this release:

• No failure without a reason. The element's own MediaError, a failed hls.js import and the last non-fatal complaint from hls.js all reach the message on screen.
• A window with no Media Source Extensions says so, rather than reporting the film as unplayable. Where hls.js cannot run, the element still gets one last try, which is how webkit2gtk plays HLS.
• A retry that was on its way could be buried under a dead-end error from the stream it was replacing. It no longer is.

The Windows path now runs in the test suite and can be driven in Chrome, which is the same engine: cargo run --example serve prints a playlist URL, and preview.html?stream=<URL> plays it through the real player.

v0.1.2

Playback on Windows.

Nothing played on Windows in v0.1.0: every film ended on "This file could not be played", with console windows open behind it. The cause was the playlist. ffmpeg rewrites index.m3u8 in place after every segment, the server sent a length taken before it read the file, and a read landing inside a rewrite arrived empty or cut short. hls.js, which is what plays on every engine but WKWebView, treats a body without #EXTM3U as a fatal parse error and never asks again. macOS never saw it because Safari's engine plays HLS itself and simply asks again.

• The playlist is served whole, or not at all.
• A conversion that has not finished its first segment in twenty seconds now says so, instead of failing silently, and the player waits rather than giving up.
• No more console windows: every tool is spawned without one.
• When playback does fail, the message says what failed and where.
• Converted films start sooner: the encoder is told to close a segment when the playlist asks for one.

The HLS test suite had never run on Windows, which is how all of this reached a release. It runs there now, on every push, along with the rest. Its first run found one more thing, fixed here: v0.1.1 carries no Windows archive because of it.

ReelDrive v0.1.0

First release of ReelDrive — a portable player for a library of films and
series on an external drive.

Each archive is self-contained: the application together with the static
ffmpeg and ffprobe it needs to play anything. Nothing to install.

Download	For
ReelDrive-macos-arm64.zip	macOS, Apple Silicon
ReelDrive-macos-x86_64.zip	macOS, Intel
ReelDrive-windows-x86_64.zip	Windows 10/11, 64-bit
ReelDrive-linux-x86_64.zip	Linux x86_64 (AppImage, glibc 2.39 or newer)

macOS: the bundle is signed ad-hoc, so the first launch needs
right click → Open. Linux: unzip and keep ffmpeg/ffprobe next to the
AppImage — it looks for them there.