119
Jellyfin 10.11.0 RC6 (github.com)
submitted 1 year ago by to c/jellyfin@lemmy.ml
21 comments fedilink hide all child comments
 

Jellyfin, the open source media server, has released their 6th RC for version 10.11.0.

This is a preview release, intended for those interested in testing 10.11.0 before it’s final public release.

If you intend to test this, BE SURE you stop your Jellyfin server and take a full backup before upgrading!

WIP release notes here for now: https://notes.jellyfin.org/v10.11.0_features

See the GitHub link for more details and a full list of changes.

all 22 comments

sorted by: hot top controversial new old
[+] 16 points 1 year ago* (last edited 9 months ago)
[deleted]
  • permalink
  • fedilink
  • source
    •
    [–] 14 points 1 year ago (2 children)

    I feel like something with such a major backend change that will affect compatibility deserves a higher version number. I'm going to tweak my docker compose file to ensure I dictate when this big database update happens

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
  • [–] 10 points 1 year ago

    Be aware,

    Jellyfin uses semantic versioning. All releases will have versions in the X.Y.Z format, starting from 10.0.0. Note however that the 10.Y.Z release chain represents the "cleanup" of the codebase, so it should be accepted that 10.Y.Z breaks all compatibility, at some point, with previous Emby-compatible interfaces, and may also break compatibility with previous 10.Y releases if required for later cleanup work

  • permalink
  • fedilink
  • source
  • parent
    • [–] 9 points 1 year ago (5 children)

    According to the release notes, the DB migration could take "up to several days" depending on library size. Oof.

  • permalink
  • fedilink
  • source
  • hideshow 5 child comments
    •
  • [–] 1 point 1 year ago (1 child)

    Couldn't I just rebuild the database completely? Start from scratch and have it just remake all the metadata?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 1 year ago

    Well you would lose the watched status for all your media, as well as any custom settings and whatnot.

    My plan, when the time comes to upgrade, is to copy the DB and bring up an isolated container using the copy, let the upgrade proceed in the background, then swap to the new container when the upgrade is done. That way there's minimal downtime and no data loss.

  • permalink
  • fedilink
  • source
  • parent
    • [–] 9 points 1 year ago (4 children)

    I hope the EFCore migration will make it easier to eventually support external databases like Postgres

  • permalink
  • fedilink
  • source
  • hideshow 4 child comments
    •
  • [–] 6 points 1 year ago (3 children)

    There's a PR already!

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 4 points 1 year ago (2 children)

    Do you have a link for that PR?

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

    This is a great update. All said, this will break my system as i have a lot of configurations.

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
    • [–] 3 points 1 year ago (1 child)

    While a lot of backend changes,nothing from a user perspective wants to me jump on board...no new features and your extensions will break......I think I'll wait lol

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
    • [–] 3 points 1 year ago

    Looking forward to the release :)

  • permalink
  • fedilink
  • source
    •
    [–] 1 point 1 year ago (1 child)

    So when a full backup is recommended, does that include media files, or is it just the cache(?) and jellyfin database?

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •