The spike proved compositing works on Linux, including Wayland, and left two blockers. One is now closed: DR-228 measured a single EXT-X-STREAM-INF in the server's master playlist, so there is no adaptive bitrate for mpv to lose and finding 3 of playback-backend-unification.md is false. The spike is updated to record that. The other — an unexplained SIGSEGV in a decoder thread — is carried into the spec as DR-231 rather than chased: the spike had no render-context teardown at all, which is DR-184 on Android restated, and removing the likeliest cause is worth doing whether or not it was the cause. The spec targets every desktop platform rather than Linux alone, because the maintenance argument runs the other way. Video has three renderers today. A Linux-only version makes it four, permanently — mpv on Linux, HTML5 on Windows, ExoPlayer on Android, hls.js underneath — and the webview path then survives indefinitely because something still needs it. Finishing the job leaves mpv on desktop and ExoPlayer on Android, and hls.js, html5Adapter.ts, videoLoaderFor and the <video> element are deleted in a phase that has its own acceptance criterion so it cannot quietly become "later". The load-bearing change is DR-233: the device profile stops being a compile-time platform constant and becomes a property of the renderer that will decode the stream. The measured 7% desktop direct-play rate and Android's 85% differ by nothing except which component decodes, so that one change is what converts the former toward the latter. It looks like configuration and is not — it decides whether the server re-encodes, and it fails silently when wrong. Windows is costed rather than waved at: the surface is genuinely different code (WebView2 in an HWND, not GTK), but everything else is shared, so nothing may be guarded on cfg!(target_os = "linux"). The real cost is build — libmpv is a Linux-only dependency while Windows cross-compiles via cargo-xwin, so a Windows libmpv must reach that build and ship in the NSIS bundle under the LGPL terms DR-216 already records. Allocates UR-080, DR-230..236, IR-033. No product code yet.

JellyTau
A cross-platform Jellyfin client built with Tauri, SvelteKit, and TypeScript.
Business logic lives in a Rust backend; a UI-rich Svelte frontend handles presentation and talks to it over Tauri's IPC. Targets Linux (libmpv) and Android (ExoPlayer).
Getting Started
This project uses bun as its package manager.
# Activate the Rust environment (fish shell)
source "$HOME/.cargo/env.fish"
# Install dependencies
bun install
# Run in development
bun run tauri dev
# Type-check the frontend
bun run check
# Build for Linux
bun run tauri build
# Build for Android
bun run tauri android build
For the full set of build, test, and Android helper scripts, see scripts/README.md.
Documentation
| Topic | Location |
|---|---|
| Architecture overview & subsystem docs | docs/architecture/ |
| Requirements, traceability & technical debt | docs/requirements.md |
| Build & release process | docs/build/build-release.md |
| Docker builds | docs/build/docker.md |
| Traceability tooling & CI | docs/traceability.md, docs/traceability-ci.md |
| Release checklist | docs/release-checklist.md |
| UX flows | docs/ux-flows.md |
| CI operations (builder image, secrets, runner) | docs/build/ci-operations.md |
Contributing
CONTRIBUTING.md covers the setup, the gates a change has to pass, and the two rules that catch people out (bug fixes start with a failing test; Jellyfin's taxonomy stays in Rust). Please also read the Code of Conduct.
Found a security problem? Do not open an issue — see SECURITY.md.
Verifying a download
Every release publishes SHA256SUMS covering all of its artifacts, plus an SBOM
of what went into the build:
sha256sum -c SHA256SUMS
Desktop builds update themselves from Settings → Updates, verifying each payload against JellyTau's signing key before installing. Android installs are handled by the system installer, so the app links to the releases page instead.
Recommended IDE Setup
VS Code + Svelte + Tauri + rust-analyzer.
License
MIT