This entry is about Jellyfin, sure — but really it’s about that specific kind of friction that happens when an open-source project stops being a focused tool and starts trying to be everything for everyone.
Recently, I ran into a bug where Jellyfin was misreporting playback capabilities for certain media items. It wasn’t just a minor cosmetic glitch; it was breaking the logic downstream. When I dug into the issue and its proposed fix, the pushback from some of Jellyfin’s core maintainers was interesting to read. Their primary concern? They didn’t want to break existing clients.
I find myself disagreeing with that prioritization. As the server, you have a responsibility to be the source of truth: if a media stream contains Dolby Vision metadata, report it accurately. I understand the maintainers’ caution — regressions on real legacy devices are a legitimate concern — but I’d start from a spec-compliant baseline and layer device-specific compatibility behavior on top. Defaulting to “don’t break clients” too often means the spec bends to the weakest implementation.
This vagueness caused real headaches for me with some Dolby Vision content I own. The metadata was muddled. More critically, the bandwidth reported for HDR and SDR streams was identical. On iOS, this is a problem because AVPlayer relies on distinct bandwidth metrics to perform intelligent adaptive switching. If the server tells the player that 4K HDR and 720p SDR have the same data cost, the client can’t make smart decisions about quality versus network load. It forces a dumb playback experience in the name of compatibility.
It’s a classic open-source trap: you try to please every edge case, every legacy client, and every weird configuration, and eventually, the core ethos gets buried under the weight of backward compatibility. You stop improving; you start maintaining.
This stagnation brings me to another thread I stumbled upon. Someone asked a fairly common question: “When are we going to rewrite Jellyfin in Rust?”
The response from some contributors was, frankly, a bit snarky. They pushed back hard, asking if this was just another “C# is bad” rant or if there was a tangible reason for the effort. They pointed out the sheer scale of the task — Jellyfin spun off from Emby with a massive codebase that has grown even larger since. The consensus was that a full rewrite was nearly insurmountable given current resources.
That thread has been sitting there since early 2024.
A lot has changed in the agentic coding space since then. I’m not saying an LLM can magically press a button and output a perfect, production-ready Rust monolith overnight. But the idea that manual translation is the only bottleneck? That feels outdated. Modern coding agents are genuinely good at the mechanical side of a migration — semantic translation, test generation, repetitive refactoring — and a rewrite could target the most critical paths incrementally rather than attempting a wholesale replacement. The architectural and verification risks don’t go away; the economics of confronting them have changed.
Jellyfin’s tendency to cater to everyone is visible in its issue tracker — it’s crowded with open PRs and long-running debates over edge cases. That’s why I’m doubling down on my own path: the Moonberry Server rewrite.
Once I get my client far enough along, I’m going to push forward with Moonberry as a true all-in-one media hub. Jellyfin started as a fork of a video server. I want Moonberry to handle movies and TV, yes, but also audiobooks, e-books, comics, and manga. The goal is a unified backend that treats all your media with the same level of rigor, regardless of format.
Right now, I have video playback working end to end — authentication and playback negotiation included — which gives me a solid foundation to build on. It’s proof that the core logic can hold up. If I can get this project to a stable, feature-rich state, it will be something I’m genuinely proud of — not just because it works, but because it has a point of view.