cross-posted from: https://lemmy.zip/post/40833329

We are pleased to announce the first release candidate preview release of Jellyfin 10.11.0!

This is a preview release, intended for those interested in testing 10.11.0 before it's final public release. We welcome testers to help find as many bugs as we can before the final release.

As always, please ensure you stop your Jellyfin server and take a full backup before upgrading!

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

This is the first release that uses the new EF Core database mapper. If you'd like to help test this release, please remember to remove all plugins to make debugging logs as easy as possible.

all 38 comments

sorted by: hot top controversial new old
[–] 8 points 1 year ago

Media watch status no longer persists on media rename. When you move or rename your media files, previously Jellyfin remembered the watch status based on external IDs alone; now it uses an actual reference to the database entry. This is a transitional change and we are working on a better way to handle that in a future version.

I hope they do figure out a solution for that soon... Until that's fixed I'm going to stay on 10.10.7 for a while.

  • source
  • [–] 6 points 1 year ago*

    Important note: This release can only be upgraded to if you're on 10.7 or later. Make sure to update to 10.10 soon or the process might become more manual.

  • source
  • [+] 16 points 1 year ago (22 children)
  • [–] 60 points 1 year ago (13 children)

    This is the database rework that's been in progress for a while to remove all the bad inherited database code from when the forked Emby. No more SQL statements in code or plugins, any DB access now goes through the core library. There are a few blog posts in their website with more details.

  • source
  • parent
  • hideshow 13 child comments
  • [–] 44 points 1 year ago (7 children)

    I'll be honest, Im not sure why theyre not releasing this as 11.x.

    This seems to be a major update. From what I can tell there are API changes, plugins might not work, your entire db is converted to another format, etc.

    I'm excited for it and thankful for all the work- just seems so big that it should be tagged 11.0.0

  • source
  • parent
  • hideshow 7 child comments
  • [–] 12 points 1 year ago (6 children)

    I kinda agree here. https://jellyfin.org/docs/general/contributing/release-procedure/

    Claims to follow semantic versioning, explicitly mentioning changes to plugin APIs as reasoning for a new major version.

  • source
  • parent
  • hideshow 6 child comments
  • [–] 24 points 1 year ago (2 children)

    Their reasoning is literally the second sentence on that page.

    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

    Any 10.Y.Z release is cleanup and can include breaking changes. That's been the case for 10.9 and 10.10 already btw.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 11 points 1 year ago* (last edited 1 year ago) (1 child)

    Sure they put a note in, but why not just follow semver to begin with instead of using semver with a bunch of asterisks, and essentially ignoring what semver is?

  • source
  • parent
  • hideshow 1 child comment
  • [–] 6 points 1 year ago

    Consider the 10.y.z simply to be 0.y.z and everything works out.

    Jellyfin inherited a lot of shitty code and architecture from emby. They simply cannot guarantee anything across patches until it is sorted out.

    imho much better then releasing major version after major version because the break stuff regularly.

  • source
  • parent
  • [–] 8 points 1 year ago (2 children)

    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,

    Its right there at the link you posted.

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

    "Breaks all compatibility [with emby]" was my interpretation of that. Not a huge deal either way but I'd definitely have been calling it 11 with this DB rework myself

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

    ... and may also break compatibility with previous 10.Y releases if required for later cleanup work.

    If you read through the whole paragraph, it is clear that they mean the compatibility of previous jellyfin versions.

    Also, again:

    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,

    That means that the code is not cleaned up with that release.

    If you would release 11 before the code is considered cleaned up, you would basically break your own defined versioning convention. That is best decided by the active maintainers.

  • source
  • parent
  • [–] 5 points 1 year ago (4 children)

    any DB access now goes through the core library

    Out of curiosity, this is better because of encapsulation? Protection from bad plugins?

  • source
  • parent
  • hideshow 4 child comments
  • [–] 9 points 1 year ago (1 child)

    Also for internal use. The original emby source used not within the code base standardized database access.

    Basically changes to the database were not possible since finding references across the code base which part uses which values was impossible.

  • source
  • parent
  • hideshow 1 child comment
  • [–] [S] 12 points 1 year ago* (last edited 1 year ago) (1 child)

    Sorry, I didn’t realize some Lemmy clients don’t show cross-post descriptions. I’ll copy paste it below:

    We are pleased to announce the first release candidate preview release of Jellyfin 10.11.0!

    This is a preview release, intended for those interested in testing 10.11.0 before it's final public release. We welcome testers to help find as many bugs as we can before the final release.

    As always, please ensure you stop your Jellyfin server and take a full backup before upgrading!

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

    This is the first release that uses the new EF Core database mapper. If you'd like to help test this release, please remember to remove all plugins to make debugging logs as easy as possible.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 21 points 1 year ago* (5 children)

    I'm serious, there's so much lazy posting on Lemmy regarding software releases.

    • no mention of what the software is or does ✔️
    • no mention of what's interesting about the software or this release. ✔️

    Jellyfin is quite a big name, but still, the pattern is clear.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 12 points 1 year ago (3 children)

    I have to admit, it's something I'd like to see done a bit better (not that I'd be the one posting about it typically)

    "Crocoslut version 12 released!"

    Uh... great?

    Though sometimes you go to the website and it's not much better.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 8 points 1 year ago

    Though sometimes you go to the website and it's not much better.

    Dude yes. Among my comments you'll see that I ranted about this for a few days in the comments of another post. That's even worse, when you can't even find out for yourself.

  • source
  • parent
  • [–] 8 points 1 year ago

    We could have a tag for things like this (if tags are a thing on lemmy) or a required prefix, such as "Software release: ".

    I do like to see an announcement for things I use and have slow release schedule.

  • source
  • parent
  • [–] 3 points 1 year ago

    Wow this one looks major, and possibly disruptive.

  • source
  • [–] 2 points 1 year ago

    Dayum.
    Some nice things in there!

  • source
  • [–] 1 point 1 year ago (11 children)

    i gave emby and jellyfin a testrun yesterday using docker. I kept emby because i can easily add smb shares using the webinterface. jellyfin requires me to mount those to the host/container. am i using jellyfin wrong?

  • source
  • hideshow 11 child comments
  • [–] 10 points 1 year ago (8 children)

    Why is it not mounted on the host/cointainer? I dont think you are using jellyfin "wrong" but its not like you cant just configure a mount point if you wanted to use jellyfin with it.

    That is an interesting thing to point out though, im not actually sure but i think they used to support smb shares directly, i might just be thinking of kodi though.

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

    it is not mounted to the container because that is a shit solution. the host would need to mount it and pass that to tge container. emby i stop the container and no connection to the share. mounted in host it would still be there. not to mention the hassle this also means more traffic. an idea why jellyfin doesnt do shares like emby?

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

    Maybe because it's not an obviously wanted feature? But I'm just guessing. You should request it and see what happens, maybe more people want it. I've never even thought about it, since in the case of Podman/docker it's so "obvious" and easy to just mount network shares to the host first. And in the case of Kubernetes you can just mount NFS shares directly into pods.

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

    Docker(/Compose) can do mounts directly to the container as well.

    https://blog.stefandroid.com/2021/03/03/mount-nfs-share-in-docker-compose.html

    https://docs.docker.com/engine/storage/volumes/#create-a-service-which-creates-an-nfs-volume

    I've used NFS mounts with docker compose before but I see the second link also includes an example for CIFS as well.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 1 year ago* (2 children)

    I’m using UnRAID for storage and getting another Linux machine to mount a share on boot has been an exercise in futility so I get it.

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

    Using nfs on ext4 file systems, I've always just added them to fstab and it works just like that

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

    Yeah it definitely does not work in this case. Spent many hours online looking through threads of people with the same problems, but no real solution. I think it has something to do with Unraids MFS implementation. Might be a little older. Only way to get it to work is have a script run every 10 minutes to check for the drive and if it’s not mounted, mount it. Works well enough.

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

    I see you've got some downvotes, but without anyone suggesting a solution.

    You can add the mount points in the docker compose file and then configure Jellyfin to read from the path(s) mounted in the container (/media/movies)

    Eg:

    volumes: 
      # local path : path in container 
      - /mnt/storage/media/movies:/media/movies
    
    
  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 1 year ago

    i know. i did. i hate it. thanks though. but that usually also requires fiddling with fstab and nobody wants that. just imagine the user roles and rights desasters that anyone with access to the host can see the mount. mount where you need the data, not in 2 or more places just to access it from one place. for me personally emby works much better on this. there are so many environments where you can deploy docker but not modify the host - so i do not see jellyfin really being useable here. i wish they'd add this, but from google searches i understand that it has been requested and there does not seem to be any intention to implement it.

  • source
  • parent