dtourolle
c0399e4ebd
Watching in a picture-in-picture window would occasionally drop to audio-only, and the audio would resume from wherever the video had been when PiP was entered while the picture had carried on past it. Two independent faults, both needed to produce that. The position froze (DR-265). VideoPlayer tracks the absolute position in its own `currentTime` rather than reading `videoElement.currentTime` at the point of use, because transcoded HLS resets the element to 0 on every segment rebuild. While playing, that variable had exactly one writer: a requestAnimationFrame loop. RAF is driven by the document being rendered, and an Android activity behind a PiP window is paused, so the loop stops while the element plays on. The `timeupdate` handler that would have covered the gap was written as a fallback "for when RAF isn't running" and gated itself on `!isPlaying` -- switching itself off at precisely the moment it was the only source left. Everything downstream froze with it: the seek bar, the ten-second progress reports, the position mirrored into Rust, and the handoff. The gate is now `shouldApplyTimeUpdate` and turns only on things that genuinely own the position -- an in-flight seek, a seek-bar drag, an element below HAVE_CURRENT_DATA. Both writers producing the same derived value costs nothing. The handoff fired at all (DR-266). PiP and the background-audio handoff are alternatives -- one keeps the picture, the other throws it away -- but exclusivity was enforced from one side only: arming the toggle suppressed *auto*-PiP, while the PiP button stayed ungated, so pressing it left both armed. What then stood between them was `isInPictureInPictureMode`, sampled once inside MainActivity.onStop(). That sample is not reliable: the keyguard dismissing the window, the window being stashed, or OEM variance in when onPictureInPictureModeChanged(false) lands can all leave the activity stopped with a window still on screen and the flag reading false. Now entering PiP disarms background audio, both directions go through one BackgroundBehaviour pair, and the PiP question accepts either witness -- the native sample or the frontend's latch over jellytau-pip-entered/exited. The latch cannot report a window that has closed: both events reach the WebView through the same message queue in dispatch order. The decision itself stays in Rust; the frontend only supplies a fact it can establish more reliably than the activity can. Red first, both: the existing behaviour was extracted into pure helpers, the tests written against the correct behaviour, and both watched to fail before either was changed.
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