libmpv on Windows (DR-237):
- The builder image carries zhongfly's LGPL libmpv-2.dll, pinned by
asset name and sha256, plus an MSVC mpv.lib generated from the DLL's
own mpv_* exports (the archive ships only a MinGW .dll.a). LGPL, not
the GPL builds: no x264/x265, mpv -Dgpl=false; FFmpeg is version3, so
LGPL-3.0. THIRD_PARTY_NOTICES.md records it.
- build-windows-cross.sh stages both files into src-tauri/windows-libs/;
build.rs links mpv.lib from there and tauri.windows.conf.json bundles
the DLL beside jellytau.exe from there, with the licence texts under
licenses/. One directory, so the DLL shipped is the one linked.
- Workflows move to builder image 2026.09.1.
Windows audio:
- MpvBackend replaces WebviewAudioBackend on Windows (ao=wasapi), so
volume, EQ, normalization and gapless work there as on Linux. Local
files are passed to mpv as native paths, not file:// URLs.
Fixes found on the way:
- player_play_item decided "does the backend render video" with
cfg!(not(linux)), true on Windows, while get_player_status sent
Windows video to the <video> element. With mpv as the backend that
would decode every film's soundtrack twice. All three callers now
ask video_renders_natively() (UT-273).
- confine_queued_path rebuilt paths with PathBuf::push, so on Windows
a queued `downloads/x` was stored as `downloads\x`, no longer the
spelling the app built. It now keeps the caller's separator (UT-205,
which only ever ran on Linux, failed under Windows).
Verified: jellytau.exe imports libmpv-2.dll; the full unit suite
cross-compiled for Windows passes under wine against the shipped DLL
(943/943, including the mpv injection and TLS tests); the NSIS
installer contains the DLL and licence texts. Not yet run on real
Windows hardware.
dtourolle
4daf172834