Jellyfin 10.10.0 → 10.11.0

Important Notes

• Configurations behind a reverse proxy that did not explicitly configure trusted proxies will not work after this release. This was never a supported configuration, so please ensure you correct your configuration before upgrading. See the updated docs here for more information.

WARNING: There are very important release notes to review before upgrading! Please find all the details in our blog post on the release.

TL; DR

IT IS VERY IMPORTANT THAT YOU READ THIS SECTION BEFORE UPGRADING TO JELLYFIN 10.11.0! Failure to do so may cause issues! Always feel free to ask for help in our chat if you are unclear or run into trouble.

1. As always for major upgrades, ensure you STOP Jellyfin and take a FULL MANUAL BACKUP OF YOUR DATA AND CONFIG DIRECTORIES before upgrading! While the upgrade process should be seamless and has guardrails, we've seen a lot of strange bugs during RC testing and it's better to be safe than sorry.

2. You MUST be running Jellyfin 10.10.7 before upgrading to 10.11.0! You may be fine with Jellyfin 10.9.11 but this is less-extensively tested. Upgrading from any other versions is NOT supported and WILL fail; upgrade to 10.10.7 first, then upgrade to 10.11.0.

3. The initial upgrade will include MULTIPLE LONG-RUNNING MIGRATIONS that may take up to several hours depending on your library size and state. DO NOT CANCEL OR INTERRUPT THE SYSTEM during these migrations; let them run overnight if possible on very large libraries. You can use the new Startup UI and Log Viewer (see below) from your local network to view the progress during the upgrade, and please see the section below for more details on "why".

4. The upgrade will make a backup of your existing library.db file named library.db.old. This file can be used to recover should the upgrade fail. Once you have successfully upgraded and Jellyfin 10.11.0 is running smoothly, you may delete this backup. If you need to try the migrations again due to a failure, stop Jellyfin, rename this file back to library.db, then start Jellyfin again, and the migration will be re-attempted.

5. If you have adjusted the Library Page Size to anything other than the default of 100, we recommend putting it back for performance reasons before upgrading.

6. After upgrading, we strongly recommend running a full library scan to ensure that all data is correctly populated. Failure to do so may result in weird bugs if any metadata entries were corrupt or not properly migrated (rare but possible). Additionally, users should also perform a scan for missing metadata on their Music libraries, as this may be necessary for proper music functionality after the upgrade. While it may not be strictly required, performing this additional scan on other libraries is recommended to ensure everything functions correctly.

7. Jellyfin 10.11.0 is NOT compatible with 32-bit ARM systems (armhf), like 1st and 2nd generation Raspberry Pis or other low-end or old SBCs, or any ARM system running a 32-bit operating system. You must be running an ARM64 operating system to run Jellyfin 10.11.0 on ARM systems. See below for more information.

8. This release also fixes several security bugs, both for ourselves and from upstream projects like DotNET. We do recommend upgrading to 10.11.0 as soon as possible.

9. As always with major Jellyfin releases, bugs will exist, even after 6 months of RC testing. This is a second reminder to take a full backup before upgrading, as this is the only way to downgrade back to a previous version if you find that you need to.

Removal of ARM32 (armhf) support

In Jellyfin 10.10.0, we deprecated ARM32 support and have fully removed it from Jellyfin 10.11.0; Jellyfin now requires an ARM64 operating system to run on ARM platforms. In practical terms, this means dropping support for very old or very low-end ARM SBCs (Raspberry Pi 1/2, etc.). We found consistently that these very old SBCs were absolutely terrible at running Jellyfin, even without transcoding, and we decided that dropping support would streamline our release processes and help ensure that users get the best experience out of the box. If you are still running on one of these systems, or on a newer ARM SBC that isn't running a 64-bit operating system, you will need to upgrade your hardware and/or reinstall a 64-bit operating system in order to upgrade to Jellyfin 10.11.0.

Deprecation of internal TLS/SSL support

We are announcing the deprecation of internal TLS/SSL support in Jellyfin, which we are planning to remove in Jellyfin 10.12.0. The current internal TLS mechanisms are cumbersome and do not integrate well with external systems e.g. Let's Encrypt's certbot, which means manual work and manual restarts whenever a certificate needs to be updated. In addition, compiling in TLS support means dependencies on external libraries that complicate our packaged Linux binaries. We have always recommended running Jellyfin behind a reverse proxy, all of which provide far better integration for TLS/SSL, so with our next release we will be removing this functionality. For anyone running a production-grade Internet-facing instance using TLS without a reverse proxy, now is the time to get that set up. Even with this removal, we are planning to still provide manual configuration options for the built-in Kestrel TLS system, which would serve as an alternative way to configure TLS, but it will not be exposed through the frontend UX and would be recommended only for very advanced, specific usecases; normal instances should move to reverse proxies.

Free Space Checks

Jellyfin now actively checks the available free space for its configuration and data directories. If you have less than 2GB of free space in each data directory, Jellyfin now refuses to start to prevent data corruption. Additionally, checks are implemented to prevent certain path misconfigurations that are known to cause issues.