• 3 Posts
  • 17 Comments
Joined 2 years ago
cake
Cake day: July 6th, 2023

help-circle


  • There’s a really strong bias on Lemmy for OSS projects. I’m glad they get so much love here, but everything people say here about Jellyfin has to be taken with a huge grain of salt. It works and you can use it. Depending on your needs, it may even work perfectly for you. There are tons of rough edges though.

    Here’s a few:

    • A bunch of basic functionality most people are used to is missing by default. You can get things like intro detection and subtitle downloading to work with plugins, but you have to work at it.
    • Hardware acceleration still kind of sucks. You can get it to work, but the Jellyfin port of ffmpeg doesn’t work anywhere near as well as Plex’s.
    • The variety in app experience is bewildering sometimes. Apps look and feel very different between platforms.
    • Android TV app support sucks. The app is difficult to navigate and has a bunch of weird edges, like subtitle defaults not working. I have no idea what OP is talking about here, it sounds like they’re only judging the app on its animation speed.
    • Public network support is finicky. This is hard to quantify, but I’ve been on several remote networks where my Jellyfin connection dropped in and out and Plex did not. I suspect this is due to the Plex Relay service making up for bad routes between my house and the network.

    Jellyfin is improving all the time, and I hope the recent EFCore update improves performance and development velocity. I’m also holding out hope it will eventually lead to externally hosted databases and active-active servers.

    Disclaimer: I run Plex and Jellyfin and regularly check in on the state of things in Jellyfin. I donate to Jellyfin. I want Jellyfin to be better than Plex. I don’t think any objective measure bears this out yet.



  • thundermoose@lemmy.worldtoSelfhosted@lemmy.worldZFS new disk
    link
    fedilink
    English
    arrow-up
    5
    ·
    2 months ago

    Losing one drive in a striped pool with no redundancy means the entire pool is shot. Restoration from your HDDs may take a very long time, on top of data loss between the time of failure and your last snapshot. Striping without redundancy is fast, but dangerous.

    This may work at first, and maybe you really do have a use case where this kind of failure is tolerable. However, in my experience, data is precious more often than it isn’t. Over time, you’re more likely to find use cases where the loss of the pool will be frustrating at best, and devastating at worst.

    If you’re not using any redundancy, I would create separate pools so each drive can fail independently. You’ll have all 5TB of storage, but not contiguously. That at least constrains the failure modes you’re likely to run into.

    If you are striping with redundancy (e.g., RAID-Z1), which I would highly recommend, you can lose a drive and not lose any data. That would take at least 3 equally-sized drives though, and you’d only be able to use the capacity of 2 of them.