9 Commits

Include renames

Author	SHA1	Message	Date
dtourolle	bb3ab1edd7	feat(windows): mpv draws Windows video into the app window ... DR-237's video half. mpv now renders Windows video the way tauri-plugin-libmpv does on Windows: MpvBackend is handed the main window's HWND and sets it as `wid` before mpv initialises, so mpv draws as a child of the app window beneath the transparent WebView2, with vo=gpu-next,gpu. osc, default bindings, VO keyboard and cursor handling are off, so the Svelte controls drawn over the picture are the only ones. - video_output() decides per platform (UT-274): Window(hwnd) on Windows, RenderApi on Linux, Off without native video. Windows with no handle draws nothing rather than letting mpv open a top-level window. - native_video::enabled() is true on Windows as well, so the frontend takes the native path there: NativePlayerAdapter, and the page clears its background while video is on screen. - enableNativeVideoCompositing() no longer logs a missing Android bridge as an error on the desktop, where there is no bridge to have. Verified: every option, wid included, is accepted by the real libmpv on Linux and by the shipped Windows DLL under wine; the Windows unit suite passes under wine (949). Not yet seen on real Windows hardware.	2026-09-24 22:42:42 -04:00
dtourolle	4daf172834	feat(windows): mpv plays audio on Windows, with libmpv shipped in the installer ... 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.	2026-09-24 22:25:31 -04:00
dtourolle	9c75e74ea3	fix(ci): give the builder image what linuxdeploy needs for the AppImage ... The v0.10.0 release build failed in Build Linux after 16 minutes: failed to bundle project: xdg-open binary not found /usr/bin/xdg-open: No such file or directory linuxdeploy embeds xdg-open into the AppImage and aborts the whole bundle when it is absent. deb and rpm had already bundled fine; only AppImage was affected. This is the one failure tonight that building locally could not have caught, and the reason is worth writing down: a developer machine is a desktop and always has xdg-utils, so the AppImage builds there and fails on a minimal server image. The asymmetry is the bug. Every other release defect this evening was found by building locally first; this one needed the runner. xdg-utils, desktop-file-utils and zsync are added together rather than one at a time. Each round trip costs an image rebuild plus a failed release build, and those three are what linuxdeploy commonly reaches for (xdg-open, desktop-file-validate, and zsync for delta updates). Workflows move to jellytau-builder:2026.08.1, built and pushed with all three verified present inside it before this commit. ci-operations.md gains two things learned here: that an apt addition invalidates the layer above the cargo-install steps, so it is a ~20 minute rebuild rather than the ~2 minutes the trailing layer normally gives; and that Tauri's AppImage bundler downloads linuxdeploy, AppRun and two plugin scripts from GitHub during the build, so an AppImage build depends on GitHub being reachable from the runner.	2026-08-22 02:52:32 +02:00
dtourolle	9a19d30e6c	fix(build): make the release actually buildable, and check it before tagging ... Preparing v0.10.0 meant building the release locally first. It did not build. Two separate defects were sitting on master, both invisible to every gate this project has, for the same reason: nothing in build-and-test.yml runs `tauri build`. Only a tag does. So the first time anyone would have discovered either was a failed release. **Tauri plugin versions had drifted apart.** Tauri refuses to build when a plugin's Rust crate and npm package are on different minor versions: tauri-plugin-log (v2.8.0) : @tauri-apps/plugin-log (v2.9.0) tauri-plugin-updater (v2.9.0) : @tauri-apps/plugin-updater (v2.10.1) Introduced by the updater and diagnostics work in this same branch -- `cargo add` took what the pinned toolchain allowed while `bun add` took latest, and the caret ranges let them separate. cargo check, clippy, cargo test and svelte-check all passed. Matching upward pulled wry 0.53.5 -> 0.54.2 along with wasm-bindgen, web-sys and webkit2gtk: the webview layer, which on Linux is the video playback path. That is not a change to make while cutting a release, so the npm packages are pinned down to the crates instead -- exactly, not by caret, since the caret is what allowed the drift. The upgrade is worth doing deliberately, with a playback check, and ci-operations.md says so. CI now runs `tauri info`, which performs the same comparison without building. Verified by reintroducing the mismatch and watching it fail. **The AppImage target had never been built.** It was added earlier in this branch because the release notes had advertised an AppImage for months while tauri.conf.json never produced one. It does not work out of the box: linuxdeploy carries its own `strip`, too old to parse the .relr.dyn section modern toolchains emit, and it fails on every bundled library -- strip: libzstd.so.1: unknown type [0x13] section `.relr.dyn' failed to bundle project `failed to run linuxdeploy` Ubuntu 23.10+ links with -z pack-relative-relocs by default, so the CI builder image fails exactly as a modern Arch host does. NO_STRIP=true is linuxdeploy's documented escape hatch. The resulting 153 MB AppImage was verified to be well-formed and to actually start. Without this the release would have failed at the Linux build step -- the artifact check added earlier refuses to publish when no AppImage is produced, which is the behaviour we want, but it would have refused a tagged build rather than a local one. Also: the traceability extractor now reads the tooling shell scripts that carry TRACES comments. DR-207, DR-213 and DR-220 all had them and were counted as uncovered because only .ts/.svelte/.rs were scanned. Listed individually rather than globbing scripts/*.sh -- most implement nothing, and adding one should be a decision. DR-221.	2026-08-21 20:22:12 +02:00
dtourolle	fb72bf3005	docs(ci): drop the runner-health references the amend missed ... The commit that removed .gitea/workflows/runner-health.yml was amended with a git add whose pathspec named the already-deleted file, so the add aborted and only the deletion was staged -- leaving ci-operations.md still describing a scheduled job that no longer exists. The runner section now says what to check by hand and why there is no job: on a single-slot runner a daily job takes the slot and pulls the builder image to run df, and df inside a container does not reliably describe the host disk.	2026-08-21 18:58:39 +02:00
dtourolle	6897b290ed	docs: add the governance and CI-operations files the project never had ... The repo had no SECURITY.md, CONTRIBUTING.md, code of conduct, or issue and PR templates. For a client that handles Jellyfin credentials and ships signed binaries, the missing one that actually matters is SECURITY.md: there was no stated way to report a vulnerability privately, so the only available channel was the public tracker. CONTRIBUTING.md documents the gates as they now stand, including the three ratchets and which direction each is allowed to move, and the two rules that surprise people: bug fixes start with a failing test, and Jellyfin's taxonomy stays in Rust. The bug template asks the three playback questions -- streaming or downloaded, transcoding or direct, music or video -- because those answers decide which of several very different code paths a report is about, and reconstructing them over several round trips is most of the cost of a playback bug report. docs/build/ci-operations.md is the missing operations manual: how to change the builder image and in what order (image pushed before the workflow that names it, or CI breaks), why tags are dated rather than :latest or per-SHA, what each secret is for, and what losing the updater private key would mean -- installed desktop clients only accept payloads signed by the key matching the public key they shipped with, so losing it means everyone reinstalls by hand. Disk exhaustion on the runner is documented as a manual check rather than a scheduled job. A daily job would occupy the only slot on a single-slot runner and pull the whole builder image to run `df` -- and `df` inside a container does not reliably describe the host's disk, so it would spend real build capacity reporting a number that might be wrong. What the doc records instead is the part that is actually hard to rediscover: the symptoms (cargo dying mid-link, docker refusing to pull, actions/cache quietly not saving) and that `docker volume prune` needs `-a` to touch named volumes, which is how it filled up unnoticed. Two things in these docs are stated plainly because they are true and were not written down anywhere: without branch protection every gate in the pipeline is advisory, and the Gitea instance -- canonical remote, signing secrets, registry, runner -- is not backed up by anything in this repository.	2026-08-21 18:45:40 +02:00
dtourolle	8fbf4d92cb	ci: match release bundles by extension, and ship the rpm ... Renaming the app to JellyTau renamed its bundles, and the release job globbed `bundle/deb/jellytau_*.deb`. The copy was wrapped in `if [ -f ... ]`, so the rename would have dropped the .deb from the release silently — a green build producing an incomplete release. Matching by extension removes the coupling between the product name and the pipeline, and an empty dist/linux now fails the job instead of passing quietly. That `if [ -f "dir/"*.ext ]` guard was also wrong on its own terms: with more than one match, test gets extra arguments and returns false. Found while verifying the rename: the rpm has been built by every release since deb+rpm became the bundle targets, and never copied, published or documented. It ships now. Also declares the package rename. Tauri kebab-cases productName into the Debian package name, so "JellyTau" produces `jelly-tau` — a different package from the `jellytau` earlier releases installed, which would have put a second copy alongside the old one. deb now declares Replaces/Conflicts/Provides and rpm Obsoletes/Provides, verified in the built control file. TRACES: | DR-214	2026-08-20 21:01:43 +02:00
dtourolle	2de91ae76c	docs: move the root-level build docs under docs/build/ ... build-release.md, build-desktop-packages.md and build-windows.md sat at the docs/ root while docker.md and build-builder-image.md were already in docs/build/, so "where do build docs live" had two answers. They now have one. Referrers updated: README.md, docs-site/SUMMARY.md, and the ../ links inside the moved files themselves, which each gained a level of depth — Dockerfile, Dockerfile.arch, packaging/arch/PKGBUILD, CHANGELOG.md, README.md, src-tauri/src/lib.rs and src/lib/services/webviewAudio.ts. Every one of those was caught by check-doc-links.sh rather than by reading, which is the point of having it. Two referrers are left for their owners: CLAUDE.md line 173 and the comment at scripts/build-windows-cross.sh line 11.	2026-08-20 19:32:04 +02:00
dtourolle	5ba9e0e958	chore: clean up repo organization ... - Standardize on bun: remove package-lock.json, add packageManager field, gitignore non-bun lockfiles, fix stray npm install in android:build:clean - Remove stale build logs and empty dirs (src-tauri/plugins, docs/tickets) - Move android-dev.sh into scripts/ - Consolidate root docs into docs/ (docker/builder under docs/build/); move the architecture overview to docs/architecture/README.md - Extract Requirements Specification from README into docs/requirements.md and slim README down to a project intro + docs index - Fix internal references to the moved files	2026-06-21 09:52:09 +02:00