We are pleased to announce the latest stable release of Jellyfin, version 10.10.7! This minor release brings several bugfixes to improve your Jellyfin experience. THIS IS A SECURITY RELEASE - UPGRADIN

cross-posted from: https://aussie.zone/post/19146681

Jellyfin Server 10.10.7

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.

Security

  • Fix validation of API parameters to FFmpeg [GHSA-2c3c-r7gp-q32m], by @Shadowghost
  • Fix trusting forward headers if none are configured [GHSA-qcmf-gmhm-rfv9], by @JPVenson

Note: GHSAs will be published seven (7) days after this release.

General Changes

  • Fix regression where “Search for missing metadata” not handling cast having multiple roles [PR #13720], by @Lampan-git
  • Clone fallback audio tags instead of use ATL.Track.set [PR #13694], by @gnattu
  • Backport 10.11 API enum changes [PR #13835], by @nielsvanvelzen
  • Support more rating formats [PR #13639], by @IDisposable
  • Fix stackoverflow in MediaSourceCount [PR #12907], by @JPVenson
  • Upgrade LrcParser to 2025.228.1 [PR #13659], by @congerh
  • Include Role and SortOrder in MergePeople to fix “Search for missing metadata” [PR #13618], by @Lampan-git
  • Delete children from cache on parent delete [PR #13601], by @Bond-009
  • Fix overwrite of PremierDate with a year-only value [PR #13598], by @IDisposable
  • Wait for ffmpeg to exit on Windows before we try deleting the concat file [PR #13593], by @Bond-009
  • Fix 4K filtering when grouping movies into collections [PR #13594], by @theguymadmax
  • Remove empty ParentIndexNumber workaround [PR #13611], by @Shadowghost
  • Update dependency z440.atl.core to 6.20.0 [PR #13845], by @Shadowghost

Jellyfin Web 10.10.7

General Changes

  • Fix parsing minor version of Tizen [PR #6661], by @dmitrylyzo
  • Fix re-focusing on pause button when displaying OSD [PR #6510], by @dmitrylyzo
  • Fix skip button not displaying correctly with OSD [PR #6583], by @rlauuzo
  • Fix catalog plugin page not setting page title [PR #6570], by @nielsvanvelzen
    • jonne@infosec.pubEnglish
      10·
      2 days ago

      I mean, it’s patching a security issue caused by trusting headers it shouldn’t, so I don’t think they should wait for a big number release.

      • sugar_in_your_tea@sh.itjust.worksEnglish
        15·
        1 day ago

        Why wait? Just release it as a big number release. The version number doesn’t define the size or cadence of a release, it just says whether there’s a breaking change.

        • mac@lemm.eeEnglish
          71·
          1 day ago

          At least in my org we use semantic versioning ( Major.Minor.patch) where patch must either be a new feature, a fix, or something that is backwards compatible

          Minor can be breaking

          Major is basically something you’re proud of lol

    • N0x0n@lemmy.mlEnglish
      55·
      2 days ago

      I mean, where else should they show that warning? It’s also posted in the forum. They also edited the documentation page.

      Maybe you’re more into mailing list or the like? I’m genuine curious on what/ how/ where you expected getting this kind of information.

      • fitgse@sh.itjust.worksEnglish
        291·
        2 days ago

        I expect in a patch release that nothing has changed and I can blindly update getting minor bug fixes and security fixes. In a minor release I expect to review the changes for configuration changes or any minor UI changes. For a major release I expect to read docs on how to upgrade and prepare backups and downtime.

        • N0x0n@lemmy.mlEnglish
          81·
          1 day ago

          Ohhh thanks for the clarification ! As you guessed I’m not into dev/programming so I wasn’t aware of this kind of detail !

          Thank you :)

          Edit: Now semver makes sense !

          • sugar_in_your_tea@sh.itjust.worksEnglish
            5·
            1 day ago

            Yeah, it’s really nice when done properly. I have my images pinned to minor releases (they can sometimes break backwards compatibility on accident), so I expect upgrades to newer patch versions to mostly be safe. Mistakes happen, but if 95% of my patch upgrades work w/o intervention, I’ll probably enable automatic updates.

            As a refresher for others, a semantic version looks like this: X.Y.Z:

            • X - bump when breaking backwards compatibility
            • Y - bump for new features
            • Z - bump for bug fixes

            You can always bump a “higher” version whenever you like (e.g. 2.0 may not break compatibility w/ 1.0), but never bump a lower version (i.e. bumping Z should never break backwards compatibility). A version bump generally indicates how much I should pay attention to the release notes.

        • sugar_in_your_tea@sh.itjust.worksEnglish
          202·
          2 days ago

          Exactly. It has nothing to do with where they post it, but what their version numbers communicate. I should be able to blindly apply patch releases, and this breaks that.

          I’m even okay with a minor release here. It was never advertised to work that way so removing it technically isn’t a breaking change, but there is a known breakage here. I’m much more likely to read minor release notes than patch release notes, so I would likely see this warning if it was a minor release.