# Tsukimi: a GTK4 Jellyfin client for Linux that plays video through embedded mpv

> Tsukimi is a GPL-3.0 Jellyfin desktop client written in Rust with GTK4 and libadwaita, using mpv for playback. It is for Linux users who want a native client rather than a browser tab, and it ships on Flathub and in several distribution repositories.

**tsukinaha/tsukimi** — A simple third-party Jellyfin client for Linux

- Repository: https://github.com/tsukinaha/tsukimi
- Stars: 3,059 · Forks: 198
- Language: Rust
- License: GPL-3.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/tsukinaha-tsukimi

## What Tsukimi solves for Jellyfin users on Linux

Jellyfin ships a web interface, and a browser tab is a workable way to watch a library. It is not a desktop application. It has no MPRIS integration with the system media controls, no native window management, and no access to a video pipeline you control. Tsukimi exists to close that gap for Linux specifically. The README describes it as "a simple third-party Jellyfin client for Linux", and the repository topics list gtk4-rs, jellyfin, linux, mpv, music-player and video-player. That combination is the whole pitch: a GTK4 application that talks to a Jellyfin server and hands playback to mpv.

The audience is narrow on purpose. This is not a cross-platform client, and the README does not claim to be one. If your desktop is GNOME or another GTK4 environment, and you already have mpv installed or are willing to have it pulled in, Tsukimi is aimed at you. If you watch Jellyfin on a television or a phone, the project has nothing for you. The developers also state a disclaimer that they have no affiliation with the content providers available, which is a normal note for a client that connects to a self-hosted server.

## How the GTK4 front end and the mpv backend fit together

The architecture visible in Cargo.toml is a Rust workspace with several local crates. The default member is crates/tsukimi, and the workspace also contains mutsumi-prelude, danmakw, mutsumi, dandanapi, dandanapi-client and yzlm. The dependency list tells you what each layer does. The interface is built on gtk 0.11 (package gtk4) and adw 0.9 (package libadwaita), with pango and gdk-wayland and gdk-x11 available as separate crates. Playback goes through libmpv2 6.0 and libmpv2-sys 4.0.1. Networking uses reqwest 0.13 with serde and serde_json for the Jellyfin API. Desktop integration includes mpris-server 0.10, which is what puts the client into the system media controls.

The interesting piece is the embedder. The README states that the project uses wl-proxy for mpv gpu-next vo embedding, and links to the embedder at MutsumiUniverse/Mutsumi. The same embedder was used to build a separate local player, Fughetta. This is a design decision with consequences. Rather than rendering video inside a GTK widget through GStreamer, Tsukimi proxies a Wayland surface so mpv's gpu-next output can sit inside the application window. The workspace does carry gstreamer 0.25 and glycin 3.1.0 as dependencies, so GStreamer is not absent from the tree, but the README names mpv and wl-proxy as the playback path. The practical effect is that your mpv configuration matters. The README links to the mpv manual's files section under an MPV Config heading and says nothing further, which means the project expects you to know how mpv reads its configuration.

## Installing Tsukimi on Fedora, Arch, Gentoo, AOSC OS and Nix

The README points first at Flathub, where the application is published as moe.tsuna.tsukimi. That is the shortest path if you use Flatpak and do not want to manage a distribution package. The README also carries a repology badge for native packaging status, which is the place to check what your distribution currently ships.

Fedora users enable a COPR repository and install the package:

```bash
sudo dnf copr enable walker874/tsukimi
sudo dnf install tsukimi
```

After the COPR is enabled, dnf resolves tsukimi from that repository; the README gives no separate dependency instructions, so the package is expected to pull what it needs.

Arch Linux has four documented routes, two from the AUR and two from the archlinuxcn repository. The AUR packages are tsukimi-bin for a release build and tsukimi-git for the latest commit:

```bash
paru -S tsukimi-bin
paru -S tsukimi-git
```

The archlinuxcn repository carries both names as well, installed with pacman:

```bash
sudo pacman -Syu tsukimi
sudo pacman -Syu tsukimi-git
```

AOSC OS uses oma, and Gentoo goes through the gentoo-zh overlay:

```bash
sudo oma install tsukimi
```

```bash
sudo eselect repository enable gentoo-zh
sudo emerge --sync gentoo-zh
sudo emerge --ask media-video/tsukimi
```

On Nix, the README states that tsukimi is available in nixpkgs since 24.11, so the ordinary nixpkgs installation applies. After installing by any of these routes, the first real use is to launch the application and point it at your Jellyfin server: the client is a Jellyfin client, so it needs a server address and credentials before it shows a library. The README does not document that sign-in flow, so treat the server URL and login as the first thing to have ready.

If you want to build from source, the repository uses Meson through a justfile. The default target lists the recipes, and the build recipe reads a DANDANAPI_SECRET_KEY from secret/key when that file exists:

```bash
just build
just run
```

The run recipe installs into build/dev-prefix and launches the binary with GSETTINGS_SCHEMA_DIR and XDG_DATA_DIRS pointed at that prefix. The workspace declares rust-version 1.92 and edition 2024 in Cargo.toml, so a toolchain at least that new is required for a source build.

## Where Tsukimi is the wrong choice

The Wayland proxy is the largest constraint. The README says the project uses wl-proxy to embed mpv's gpu-next video output. That is a Wayland-specific mechanism, and the README does not describe an X11 fallback for embedding. The workspace does depend on gdk-x11, so X11 is present in the build, but the documented playback path is the Wayland one. If you run an X11 session, or a compositor that does not cooperate with this kind of surface proxying, you are outside what the README describes, and nothing in it promises that playback will work there.

Second, the README does not document rollback or downgrade. Releases are frequent (v26.8.4 on 2026-08-20, v26.9.1 on 2026-09-05, v26.9.2 on 2026-09-11), and the version scheme is date-like, but there is no stated procedure for returning to an earlier build if an upgrade misbehaves. On a rolling distribution that pulls from tsukimi-git, you are tracking main directly.

Third, this is a client, not a server, and it is a third-party one. The README's disclaimer about content providers is the only statement about scope; there is no compatibility matrix listing which Jellyfin server versions are supported. If your server is older or heavily modified, the README gives you nothing to check against. Finally, if you want a client on a platform other than Linux, the project's own description rules it out.

## How Tsukimi differs from Jellyfin Media Player and the web UI

The obvious alternative is Jellyfin Media Player, which wraps the Jellyfin web client in a Qt desktop shell with mpv handling playback. The difference is in what each one is built from. Jellyfin Media Player reuses the web front end, so its interface tracks the server's web UI. Tsukimi builds a native GTK4 interface with libadwaita, and the README credits GNOME Music, Fractal and Clapper as references during development. That means the interface follows GNOME conventions rather than web conventions, and the feature set is whatever the Tsukimi developers implemented rather than whatever the web client does.

The playback difference is subtler. Both use mpv, but Tsukimi embeds mpv's gpu-next output through wl-proxy rather than through a Qt window, and it exposes mpv configuration directly (the README's MPV Config section links to the mpv manual). If you already tune mpv through its config files, that is a point in Tsukimi's favour. If you want the widest feature coverage and the interface you already know from the browser, the web-wrapping client is the safer pick. The plain browser tab remains the third option and needs no installation at all, at the cost of no MPRIS integration and no native window.

## Licence, maintenance and the cost of upgrading

Tsukimi is licensed under GPL-3.0, stated in the README and present as the LICENSE file at the repository root. For anyone running the application, that changes nothing. For anyone who wants to link the code into a proprietary product, the GPL's copyleft terms apply to derivative distribution, and the README's only licence statement is the link to the GNU GPLv3 text. This is not legal advice; if you plan to redistribute a modified build, read the licence itself.

The repository is not archived, and the last push was on 2026-09-22, two days before this writing, with the most recent release v26.9.2 published on 2026-09-11. That is a fast cadence, and it has a cost: the AUR tsukimi-git package and any other build that tracks main will move under you. The release packages (tsukimi-bin, the COPR, the Flathub build) are the calmer channel. Because the README documents no rollback procedure, pinning a known-good version in your package manager is the only lever the documentation gives you, and on Flathub or a distribution repository that may mean holding the package rather than downgrading after the fact. The workspace's release profile sets lto, strip, debug = "limited" and codegen-units = 1, so source builds are optimised for size and speed at the expense of build time.

## Conclusion

Adopt Tsukimi if you run Jellyfin on a Linux desktop with GTK4 and libadwaita available, want a native client instead of a browser, and accept that playback depends on mpv and on Wayland proxy behaviour for gpu-next embedding. Do not adopt it if you need a client for Windows, macOS, Android or a TV, or if you need a documented rollback path for upgrades, because the README describes none. Before installing, check the repology badge for your distribution and confirm the version your repository carries, since the Flathub build and the distribution packages are separate channels.

## FAQ

### What is Tsukimi?

Tsukimi is a third-party Jellyfin client for Linux, written in Rust with GTK4 and libadwaita, and licensed under GPL-3.0. It plays media through mpv, using wl-proxy to embed mpv's gpu-next video output in the application window.

### How do I install Tsukimi on Linux?

The README points to Flathub as moe.tsuna.tsukimi and documents native packages for Fedora via the walker874/tsukimi COPR, Arch Linux via the AUR and archlinuxcn, AOSC OS via oma, Gentoo via the gentoo-zh overlay, and nixpkgs since 24.11.

### Does Tsukimi work on Wayland only?

The README states that the project uses wl-proxy for mpv gpu-next vo embedding, which is Wayland-specific, and it does not describe an X11 embedding path. The build does depend on gdk4-x11, but the documented playback mechanism is the Wayland one.

### What licence is Tsukimi released under?

GPL-3.0. The README links to the GNU GPLv3 text and the repository carries a LICENSE file at its root.

## Sources

- [Issues](https://github.com/tsukinaha/tsukimi/issues)
- [License: GPL-3.0](https://github.com/tsukinaha/tsukimi/blob/main/LICENSE)
- [README](https://github.com/tsukinaha/tsukimi/blob/main/README.md)
- [Releases](https://github.com/tsukinaha/tsukimi/releases)
- [tsukinaha/tsukimi on GitHub](https://github.com/tsukinaha/tsukimi)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tsukinaha-tsukimi