• 0 Posts
  • 8 Comments
Joined 16 days ago
cake
Cake day: June 26th, 2025

help-circle
  • Yep, transcoding is the main reason I had to buy any new hardware when getting my library going with Jellyfin.

    For me, the main draw of Jellyfin wasn’t the transcoding. It was being able to browse and stream my library from anywhere. My partner and I would alternate weekends hanging out at each other’s places, and we just wanted access to the library from wherever we were and whatever device we were using.

    I was willing to put up with weeks of encoding to get everything into a web-compatible format. But that’s just me and I know it’s not for everyone. I’m curious where the palatibility for that is on the spectrum more broadly.


  • The short answer is because it’s a fun project, and I wanted to see if I had it in me to make exactly the media server I want.

    The longer answer is that I wanted something dramatically and fundamentally different from what either Jellyfin or Plex have to offer.

    • Can run without breaking a sweat on junk/old/cheap hardware like a Raspberry Pi or old laptop.
    • Can be safely Internet-facing – no anonymous access, and no web-based admin features or API.
    • Hyper-lean and minimal. All-in, I wanted something on the order of 1MB for client app, server, all dependencies, everything.

    I don’t see either of those goals happening with a contribution or fork, because achieving them would require some dramatic feature deprecation.




  • True.

    When I migrated off of Jellyfin, I re-encoded everything up to that point directly from the Blu-ray rips wherever possible. Because I’d already started culling those for space, I did end up just doing another pass on the first round of encoding for a portion of the library. There’s some noticable degradation on those, and I’ll want to re-rip those at some point.

    Fortunately, I’ve got my process pretty dialed in for ripping and I actually enjoy it, so if I ever have a quality issue, it’s not a huge ordeal to re-rip and encode.