I've been trying to upgrade from 10.10 to 10.11 for a while now, as the Android TV app keeps nagging me, and every attempt ended with impossibly long library scan times.

After some thorough investigation, it appeared that a Home Videos type collection causes unending scan (yet to be solved), but also that Jellyfin does a lot of writes to the config directory (either database or metadata or both). Mine's on spinning media part of a ZFS pool. I tried a few performance tuning options, such as testing the config dir with recordsize (similar to block size) of 4K, 8K, 64K, 128K and library scans fell from 30-40 minutes down to 8-13min with 4K-64K. The ZFS tuning wiki suggest 64K recordsize with LZ4 compression for SQLite workloads such as Jellyfin. That seems to work as well as 4K and 8K but likely is faster when reading thumbnails and such.

Note that upgrading to 12-rc3, which is supposed to speed up library scans did not improve scan times for me. Optimizing config/database write speed did. I cross-checked the culprit by experimenting with moving the config dir to NVMe and RAM. Both of those got the scan times down to 8-9 minutes compared to the optimized spinning media's 12-13.

So if you had upgraded (or about to) to 10.11 your library scans are (about to get) dog slow and your Jellyfin's config dir resides on spinning media, optimize its write performance for SQLite.

top 80 comments

sorted by: hot top controversial new old
[–] 139 points 3 months ago (60 children)

Isn’t it ironic that you post this meme along with complex instructions to fixing a problem in jellyfin?

  • source
  • hideshow 60 child comments
  • [–] [S] 63 points 3 months ago* (last edited 3 months ago) (18 children)

    With great power come great .. uuh .. :D

    Also the meme is just bait so you read abt the problem and see if you need to solve it for your setup.

  • source
  • parent
  • hideshow 18 child comments
  • [–] 2 points 3 months ago (14 children)

    Yeah but tell me about this tool for Plex remote streaming...

  • source
  • parent
  • hideshow 14 child comments
  • [–] 4 points 3 months ago (12 children)

    It's a wrapper called jellyfin

  • source
  • parent
  • hideshow 12 child comments
  • [+] 2 points 3 months ago* (10 children)
  • [–] 1 point 3 months ago (7 children)

    Why not? Unless you're talking about unauthenticated steaming of media if you reverse engineer a servers folder structure.

  • source
  • parent
  • hideshow 7 child comments
  • [+] 0 points 3 months ago (6 children)
  • [–] 1 point 3 months ago (5 children)

    Do you have any proof that it's not secure?

  • source
  • parent
  • hideshow 5 child comments
  • [+] 0 points 3 months ago (4 children)
  • [–] 1 point 3 months ago (3 children)

    I think you've fundamentally misunderstood some of their communication.

    There's the issue I described earlier where it is possible to stream files unauthenticated if you know the folder structure on the video. The devs have responded that they won't fix this. Outside of streaming content, there's no other access through this mean. https://github.com/jellyfin/jellyfin/issues/1501

    Then there's the release of 10.11.7 that fixed a number of security issues. https://github.com/jellyfin/jellyfin/releases/tag/v10.11.7 with no major security issues since then. And all the issues were privilagr escalation for a normal user account on jellyfin. So the attacker would already needed to have an account on your server, and only the data that jellyfin could see was at risk, nothing escaped contagion so to say.

    They also officially support a reverse proxy set up: https://jellyfin.org/docs/general/post-install/networking/reverse-proxy/.

    I have no idea where you've got the idea where they themselves claim it's unsecure to open it to the internet. Of course there's always a risk associated with exposing something, but jellyfin doesn't pose any larger risk than anything else you might publish.

  • source
  • parent
  • hideshow 3 child comments
  • [+] 1 point 3 months ago* (last edited 3 months ago) (2 children)
  • [–] 1 point 3 months ago (1 child)

    Hi, could you tell me why? I mean, I think I understand the basics of the risk of brute force attacks. My mitigation for the admin account is, not to allow login outside the local network. Users are allowed from anywhere, as my family uses the library. Also my service (there are others) are routed through NGINX.

    Do you have tips for external users using, for example, a VPN only for specific addresses / IPs? At least that was an idea I had, but didn't got got around to dig for solutions.

    Thanks in advance.

  • source
  • parent
  • hideshow 1 child comment
  • load more comments (1 reply)
  • [–] -3 points 3 months ago (40 children)

    Also doesn't jellyfin not support remote streaming?

  • source
  • parent
  • hideshow 40 child comments
  • [–] 50 points 3 months ago (34 children)

    It's a nonsensical statement. Jellyfin is accessed through a website. You're responsible for routing to it.

  • source
  • parent
  • hideshow 34 child comments
  • [+] -7 points 3 months ago (32 children)

    It's a very sensical statement. I'm not exposing a whole ass website on my own network just for remote viewing. With plex you don't need to do that.

  • source
  • parent
  • hideshow 32 child comments
  • [–] 27 points 3 months ago (10 children)

    You don't need to do that with jellyfin either. It includes the website for convenience, but you can just disable it or completely remove it and have just the server.

  • source
  • parent
  • hideshow 10 child comments
  • [–] 3 points 3 months ago (9 children)

    How do you communicate with the server outside of your network? You'd still need to expose those ports directly to the internet right? (excluding VPNs/reverse proxy etc)

  • source
  • parent
  • hideshow 9 child comments
  • [–] 3 points 3 months ago (1 child)

    It is still an issue that is easier on plex which is why I run both because I can't setup and troubleshoot vpns for all my family that has access. Plex is much easier on that way. Jellyfin is great but look what you need to mimic a fraction of plexs power 😆

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 3 months ago (6 children)

    I mean, if you put restrictions on the requirement sure. At that point it kinda becomes a loaded question though.

    If you remove the restriction, just use a cloudflare tunnel.

  • source
  • parent
  • hideshow 6 child comments
  • [–] 1 point 3 months ago (5 children)

    Yeah dont use a cloudflare tunnel for media streaming

  • source
  • parent
  • hideshow 5 child comments
  • [–] 2 points 3 months ago (4 children)

    They don’t care, that line in the ToS was removed years ago now.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 3 months ago (3 children)

    I believe it was moved, not removed, and that it is now located in a different document, but still applies.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 1 point 3 months ago (2 children)

    No it was definitely removed, they now have essentially “don’t be an ass with the bandwidth.”

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 3 months ago (1 child)

    No, it was moved. It now sits in their CDN service terms; the difficulty is in determining whether tunneled traffic constitutes CDN usage because CF are kinda vague on this stuff. Are they going to limit your account over a little streaming? Probably not, but I would not risk it unless you don't really care about the account.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 3 months ago

    Tunnels aren’t inherently CDN, you can tunnel UDP info for instance (if you use cloudflared on both sides) and inherently transient things such as websockets.

    I’ve had none of my media be cached in their CDN for instance. In fact you’d likely have to do some hoop jumping to make it happen.

  • source
  • parent
  • [–] 14 points 3 months ago (20 children)

    Yes you do. It just does it for you including handling SSL.

  • source
  • parent
  • hideshow 20 child comments
  • [–] -1 points 3 months ago (19 children)

    Inside the network you do, but not for remote access outside the network.

  • source
  • parent
  • hideshow 19 child comments
  • [–] 21 points 3 months ago (17 children)

    Outside the network you still have to open your server to allow plex cloud to access it and potentially tunnel your traffic through plex.tv if a direct connection doesn’t work. This happens automatically but it does happen

    With Jellyfin you just have to supply your own relay, like Tailscale or wireguard, which does require more setup but is completely free, means that you can stop your media traffic from being funneled through services that harvest your data (which plex absolutely does), and doesn’t go to shit if plex.tv goes down

  • source
  • parent
  • hideshow 17 child comments
  • [–] 5 points 3 months ago (1 child)

    You can do the exact same thing with Plex, you just don't need to since automatic remote streaming is built in. In fact, the article's solution is literally Tailscale.

    You can also bypass plex authentication on any ip range you choose, so if you add your local network and plex's auth service goes down, it's no big deal.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 11 points 3 months ago

    Yeah obviously, you can also use Tailscale to tunnel to whatever service you want (including just to the server itself). But if you’re bothering to override remote plex access with all this I don’t know why you wouldn’t just pick the option that doesn’t harvest your data and increasingly treat its customers as hostile

  • source
  • parent
  • [–] -1 points 3 months ago* (last edited 3 months ago) (14 children)

    This happens automatically but it does happen

    And that's the key, it happens automatically and it just works. With jellyfin you have to expose the web server to the internet, or point an app to something else exposed on the internet. With plex you don't. If you don't want to (or can't) a direct connection from your server to their servers, then their servers to your device is established. No VPNs, no reverse proxies, no port forwarding, nothing exposed to the rest of the internet.

    What I'm praying for is for Jellyfin to add a tailscale like direct peer to peer system. They can skip the backup funneling traffic through their servers. But just have something that coordinates a direct connection with just basic NAT.

  • source
  • parent
  • hideshow 14 child comments
  • [–] 10 points 3 months ago (10 children)

    They won’t do that because it’s expensive and free software generally doesn’t have the budget to do this

    I don’t know why you think the “just works” is any different from tunneling with a service. Your server is still opened to the internet through upnp with direct connections and through a tunnel to plex.tv when a direct connection is not possible. In fact plex is inherently less secure because their infra is both the encryption endpoint (as opposed to your client with Jellyfin and Tailscale or whatever) and their infra has been vulnerable in the past (like the massive breach in 2022).

    Jellyfin with something like nginx and a vpn is open to the internet, yes, but a service that tunnels (like wireguard, Tailscale) bypasses this issue and it’s up to you to set it up as to your level of comfort

    Plex is just easier but as with all things tech (especially those infected with VC dollars) “ease” translates to less secure and far more likely to exploit your data

  • source
  • parent
  • hideshow 10 child comments
  • [–] [S] 1 point 3 months ago (9 children)

    I came up with a funny strategy I use to lock it down a bit. What's exposed to the internet for me is Apache2 reverse proxy. The proxy is locked down to reject all connections EXCEPT for the ones coming from a special subdomain which is something like a 64-character long random string. This prevents pretty any unwanted connections. Obviously the special subdomain must remain as secret as a shared password among the Jellyfin users. It works for trusted users.

    What I want ideally is an "authenticated firewall." OpenWrt rejecting all connections on the open port except for an allowlist of IPs. Then there must be a system where users can authenticate and their IP is added to the allowlist. I haven't found an off-the-shelf solution like this but I'll make it some day. Too bad I figured this random string subdomain trick cause it seems good enough for now. :D

  • source
  • parent
  • hideshow 9 child comments
  • [–] 1 point 3 months ago (7 children)

    How is your DNS set up for that subdomain? Is it on a wildcard DNS record?

  • source
  • parent
  • hideshow 7 child comments
  • [–] [S] 1 point 3 months ago* (last edited 3 months ago) (6 children)

    Do you mean the SSL cert? Yes, that's wildcard on *.mydomain.com. Then the subdomain is kvtn4ftxfreurdcw7qtr21mcywxaqqm.mydomain.com.

  • source
  • parent
  • hideshow 6 child comments
  • [–] 1 point 3 months ago (5 children)

    In this case I mean the DNS entry for the random string. The thing pointing that subdomain at your IP/proxy.

  • source
  • parent
  • hideshow 5 child comments
  • [–] [S] 1 point 3 months ago (4 children)

    It's just an A record pointing to my IP. IP's updated from my router via the DNS provider API.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 2 points 3 months ago (3 children)

    If that A record isn’t a wildcard, anyone can see it, is what I’m getting at.

  • source
  • parent
  • hideshow 3 child comments
  • [–] [S] 1 point 3 months ago* (2 children)

    Hm. As far as I know that can only be done if AXFR is enabled (it's not), if the domain has entered some search engine that has remembered it, through SSL cert that's not wildcard, or through brute force lookup. Am I missing something?

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 3 months ago (1 child)

    Give it a look on https://dnsdumpster.com/ or similar. Your dns records are inherently public, so anyone that works out the domain can work out the subdomain. In fact there are plenty of tools that just scan every domain/subdomain they can find.

  • source
  • parent
  • hideshow 1 child comment
  • [–] [S] 2 points 3 months ago

    Thanks for the pointer. Checked, tried a couple others - they don't know about it. They have some other non-random DNS records. AFAIK they can absolutely find it if they scan for all domains, but it'll take forever if the name is randomly-generated and sufficiently long. Someone has to be determined to spend the resources. This doesn't guard against that but against bots trying to fuck with the service at the port. I could move it to a wildcard though. There's an overlap with another subdomain (they're actually sub-subdomains and the first sub is common) but I could move that.

  • source
  • parent
  • [–] 3 points 3 months ago (1 child)

    It is literally a cloudflare tunnel/ tailscale type thing but contained in the app. The only real difference is that it is bundled in the app, so less setup and in exchange, Plex itself is free to harvest all of your data.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 5 points 3 months ago

    Let'scrypt and port forward. Sprinkle on some free ddns with a sync script/job to keep ddns pointing to your real public IP. Can even roll in some headscale if you're feeling adventurous

  • source
  • parent
  • [–] 1 point 3 months ago

    It absolutely does but you have to do it yourself, they dont accept any liability for doing that and nor should they, so if you dont know how to do it with at least the minimal level of safety and security and accept that risk yourself then you really shouldn’t try. Ideally you would only do it via a private VPN to trusted users.

    Plex has some features built in to make just opening the port reasonably safe, though I'd still recommend against that. They also have a reasonably secure account verification system, and the software itself has proven to be somewhat safe.

    Jellyfin has very little security built in and is not intended to be public facing, it also has the double edged sword of being open source, so you could read through all the code and pick it apart for flaws and exploits if you wanted to and we all just trust that when exploits or flaws are found they are reported properly.

    JF is great but you are on your own if you want to make it available via WAN.

  • source
  • parent
  • [–] 19 points 3 months ago (1 child)

    I run the DB on the SSD and media on the hdds and haven't had any issues, but I don't have a huge library though. However, things are generally speedy. I thought the higher record sizes were recommended for media, not the DB? but if it worked for you, that's good

  • source
  • hideshow 1 child comment
  • [–] [S] 3 points 3 months ago

    64K is generally small recordsize. For media they recommend 1M. My db was sitting on the default 128K recordsize and perforned fine on 10.10. It doesn't matter much for reads because ZFS keeps it in RAM and if it gets evicted it goes into SSD cache (l2arc). But for writes the cache wouldn't help unless I disable sync which risks data loss. I don't think 10.10 did much writes during lib scan so write perf only mattered when something changed.

  • source
  • parent
  • [–] 12 points 3 months ago* (1 child)

    If you use folders a lot, the library will get faster with v12 https://github.com/jellyfin/jellyfin/issues/15141

    OP said this didn’t improve their situation though.

  • source
  • hideshow 1 child comment
  • [–] [S] 2 points 3 months ago

    Not sure if this is the problem I was hitting with my Home Videos library type. It's got directories with YouTube videos. I tried re-adding it in 12-rc3, which was released a month after the nightly mentioned in the issue thread. Still couldn't complete. I ended up re-adding the media as Shows library. Works okay with the directory structure I have.

    The write performance was recorded without the problematic library (deleted).

  • source
  • parent
  • [–] 3 points 3 months ago (2 children)

    I've had initial scans take hours and scans afterwards usually also take some minutes. Why do you think that is an unreasonable amount of time to check all entries for updated metadata?

    unending != 40 minutes.

  • source
  • hideshow 2 child comments
  • [–] [S] 3 points 3 months ago (1 child)

    That would be reasonable. I did repeated rescans and only counted subsequent rescans. For me the initial scan after upgrade took a bit more but not hours. Subsequent scans took less. E.g. 20min -> 13min for write-optimized filesystem. So that's reasonable, although 10.10 was way faster. Library scans are expected to get faster in 13 according to some Github threads I read.

    When I had the broken Home Videos library I waited 3 days for the initial scan to complete and it did not. Repeated rescans did not seem to complete although I didn't wait 3 days for them. I'm not taking into account those scan times. Something was wrong with this library type on 10.11 and/or my media. Worked fine on 10.10.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 3 months ago (1 child)

    I've always kept my apps and databases on solid state media, putting them on spinning rust, even in a well tuned ZFS pool with lots of disks is way too slow for their (admittedly inefficient) database.

  • source
  • hideshow 1 child comment
  • [–] [S] 1 point 3 months ago* (last edited 3 months ago)

    This is true but it's nice to have the whole app, data and database in one place, going together, snapshotted together, "backupable" together. It's slower for sure. That said it can be reasonably fast with a large pool (more disks). With the magic of SSD cache, database reads fly and reads are the majority of the loads in my heads. In the future I would put root on ZFS as well and either do SSD cache or have root on ZFS SSD pool that gets send/recved regularly onto the spinning pool so it's easy to restore when needed.

  • source
  • parent
  • [–] 2 points 3 months ago

    Thanks, will take a look a my setup

  • source
  • [–] 2 points 3 months ago* (1 child)

    Hey not bad for the developer...he vibe coded it right

  • source
  • hideshow 1 child comment
  • [–] [B] 1 point 3 months ago* (last edited 3 months ago)

    Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:

    Fewer Letters More Letters
    CGNAT Carrier-Grade NAT
    DNS Domain Name Service/System
    Git Popular version control system, primarily for code
    ISP Internet Service Provider
    NAT Network Address Translation
    NVMe Non-Volatile Memory Express interface for mass storage
    Plex Brand of media server package
    SATA Serial AT Attachment interface for mass storage
    SSD Solid State Drive mass storage
    UDP User Datagram Protocol, for real-time communications
    VPN Virtual Private Network
    ZFS Solaris/Linux filesystem focusing on data integrity

    12 acronyms in this thread; the most compressed thread commented on today has 13 acronyms.

    [Thread #66 for this comm, first seen 31st Jul 2026, 00:40] [FAQ] [Full list] [Contact] [Source code]

  • source
  • [–] -4 points 3 months ago (8 children)

    Doesn't jellyfin need a static IP.

  • source
  • hideshow 8 child comments
  • [+] 6 points 3 months ago (5 children)
  • [–] 1 point 3 months ago (4 children)

    Most ISP connection are behind CGNAT(ipv4), and in case of ipv6 to have a secure connection wouldn't that require SSL certificate and a domain?

  • source
  • parent
  • hideshow 4 child comments
  • [–] 5 points 3 months ago*

    You could use tailscale or netbird. Alternatively, you can use a dynamic DNS provider which usually provide free subdomains, if you don't want to pay for a domain. And even with all of that, Jellyfin doesn't require HTTPS, although there may be clients that do (make sure you're behind a VPN in this case).

  • source
  • parent
  • [–] 1 point 3 months ago (1 child)

    Jellyfin expects you to actually host it yourself, instead of baking in a proxy and selling you the service.

    There are plenty of free subdomain providers, and let's encrypt gives out free certs.

    If you're not hosting through a VPN you should consider those a requirement so you're not sending an unencrypted password to your jellyfin instance over the internet. Regardless of your ISP situation...

  • source
  • parent
  • hideshow 1 child comment
  • load more comments (1 reply)