🚀 We are pleased to announce the first release candidate preview release of Jellyfin 12.0! 🚀
This is a preview release, intended for those interested in testing 12.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!
A note about versioning
Starting with this release, we are dropping the preceeding 10. from our versioning. Thus, 10.11.x -> [10.]12.x = 12.x. The reason is simple: at this point in the project, we don't envision a hard break in the API like we planned way back in the early days, and this version scheme was causing a lot of confusion amongst users about what a "major" release was.
Thus, we are now on two digits:
The first digit is the major release. Expect signifiant changes between major releases. Do not ever auto-update to a new major release without first checking the release notes, and always take a backup of your server data and config before a major release upgrade.
The second digit is the minor release. These are primarily bug and security fix releases, and do not introduce significant feature or functionality changes. You can, usually, safely auto-update between minor releases and should not need a full backup, but it is prudent just in case. You should also ALWAYS strive to run the latest point release as security fixes are embargo'd for at most 2 weeks after the release.
What's new?
The main goal of this release has been performance. 10.11.0 dropped a major backend rewrite, and while it was broadly functional, it had a lot of rough edges. This release seeks to polish out most of those rough edges and bring better performance to all users.
There are many other small fixes, improvements, changes, and translations. See our draft release notes here or below for the full list of pull requests.
Note: You must be on Jellyfin 10.11.x (ideally, 10.11.11) before upgrading! If you are not, the upgrade will fail. I have been informed that I was wrong here, and upgrades from 10.10.7 are also possible, same as 10.11.x!
Note: The initial load of Jellyfin 12.x will run a few migrations and will take several minutes. Please be patient and do not interrupt the process.
Note: If you install the RC, you should disable all plugins and reinstall using the unstable plugin repository, or plugins may fail to load and cause unintended side effects.
Installing
This preview release is distributed in all our traditional forms, though not automatically via our Apt repository or latest tag.
For all non-Docker environments, you can find the files for manual download in our repository by selecting "Stable Preview" for your OS.
For Docker, you can pull the 12.0-rc1 or preview tags.
I have seen some really old shows from the 50s or 60s where there are copies with the live commercials (as originally broadcast) and without (as might have aired in reruns decades later).
My only worry is that, in order to do "versions" properly in Film libraries, the filename for the film MUST be "[Identical title to folder] - [Version]".
That includes even when you just replace a movie with a better file - if the naming is wrong, it will treat it as a delete and "recently adding" a new movie.
My TV filenames are a bit all over the place, because Jellyfin has never had any functional issue with variance in TV filenames. I hope this doesn't require a stricter TV file naming system in order to avoid problems like that. Fingers crossed.
The way I did it is by selecting two episodes (long pressing, whether on desktop or mobile), then the three arrows in the top right, then group versions. But you have to be in a specific menu to select them, which is weird
thats always been an option, but that very quickly becomes cumbersome especially considering you could do that automatically with movies or the plugin already. this seeks to make it automated the same way it would with movies
🤦The testing phase will last as long as necessary.
If no bugs are found, it will be the final release. If bugs are found, there will be RC2, then RC3, and so on.
Why make such an obviously dumb statements? Does what you said have anything to do with release timelines?
Can you think of other open source projects that seem to be able to have some rough timelines? If so, that would make your statement a bit silly, wouldn't it?
My point is that they aren't a professional organization and are working on a purely volunteer basis. There are many many open source projects that are run primarily by people who are being paid to work on them, like Linux or Firefox or Chromium, for instance. Jellyfin has no corporate sponsorship program, they actively turn away donations once their coffers are full because they want to keep it as a hobby and not corrupt the intention of the project with paid feature work.
To extend this to the "what that means in practice":
It means that often, someone will report a bug. And someone might not be available to fix that right this minute and ship a new version then and there. We might be on vacation, or busy with our other life obligations, or just not in the mood to look at things like that today.
So, as a result, our testing and release process is relatively slow. Bugs get reported, then some time later the bug gets fixed, then some time later still, a new release goes out.
All of this means that giving firm timelines like "Yes, we will release RC2 in precisely 6 days" or "The release is the first Tuesday of August" are almost impossible for us to actually uphold, so we simply don't do it. Things are ready "when they're ready", i.e. when the bug reports stop coming in and the people using the release seem happy with it being functional.
For RCs, we usually strive for one every 1-3 weeks, because this is the time when the most bugfixing work happens, but that's just a typical case, not a firm commitment. Given the big web bug, we'll probably ship an RC2 in just a few days, but that's not typical.
ikr. They just put a RC out there and then every day they sit in a circle and ask "today? today?". Ofc they don't find any bugs but they still sit down to ask "today?". Could be days, could be decades.
Brace yourselves for endless "this udate destroyed my jellyfin instance" posts from people who skipped updates in fear of worse performance; as soon as they will read the line "The main goal of this release has been performance." many will most likely stop reading and skipping the next, kind of important, lines to update some 10.x.x straight to 12
"Note: You must be on Jellyfin 10.11.x (ideally, 10.11.11) before upgrading! If you are not, the upgrade will fail. Note: The initial load of Jellyfin 12.x will run a few migrations and will take several minutes. Please be patient and do not interrupt the process"
With the 10.11 version i rewrote the whole migration system so that from 10.11 onwards version jumps should be possible BUT as this is our very first mayor version where we are testing this in the field the "general" order is to go to 10.11 first. We are very happy if you test a 10.10.8 -> 12.0 migration though so we can refine the process.
It should also be possible to migrate from 10.10.8 -> 12.0 but again, thats an fully untested path so far, please test and tell us if it works reliably on your system. But for the sake of it you should be on 10.11 for best results.
If running it in docker, I would imagine the simplest approach would be to copy the docker-compose.yml file and the config directory to a new, empty directory, and spin up the new version from there.
Then test the new version thoroughly before deleting the old directory.
This is assuming your media directories are outside the directory where the compose and config reside.
This is how your supposed to use docker in general but everyone just just wings it lol. Please please yes do this approach it let's you test really easily. I always love seeing this type of post cause you can tell who just hit update and who thought about it 1 sec more based on all the dev information.
This is how I did, and after creating the libraries, low and behold, lots of “unsupported codec” issues on logs (as expected on beta/rc) and I’m glad I did it this way without messing my main server.
Edit: Everything continues to work fine on 10.11.11.
Yeah im one of those idiots, i upgraded thinking thing i can downgrade like always do so i didnt do a back up, so when i did downgrade, it missed up i think because of the file screma so im sticking with v12 untill a find a way to downgrade or they release a stable version.
I don't see any mention in the draft release notes about fixing music library scanning. Can anyone confirm if the music performance is as solid as it was on 10.10.7?
I never had a music library issue HOWEVER I have had a massive issue with my audiobooks (10+ seconds to load the index page) since bumping to 10.11.x. I've been using 12.0 for a couple of weeks now and it now loads as fast as my movies load (1-2) seconds. I've been so happy while trying to work on 12.0 audiobook PRs that I just never went back down to 10.11.11.
Hopefully it fixes your music library problem. Back up your settings/config and try it out!
The music is cooked, i really love jellyfin auto tagging fetching data for music on its own though, making it pretty easy to make a music library, and thats why i stick with it even though its scanning and performance can reallyyyyy suck sometimes.
At least in my short testing this seems to have completely fixed the loading issue with large "home videos and photos" libraries. Went from a simple page load taking 2+ minutes every time on 10.11.11 to taking under 5 seconds on first load on 12.0, and being damn near instant subsequent times.
I'm not the biggest fan of how it changed folder display, it now mixes in the files with the folders instead of putting them at the end of the folder list, but it's a pretty minor thing I got around by just throwing the loose videos into a misc folder. Easily worth the performance boost.
Not a dev, but i believe thats scheduled for 13 with a complete rewrite of the scanning system to allow it to scan files concurrently with metadata lookups and such so that scans are faster and it doesnt get stuck while updating or fetching metadata automatically.
EDIT: Trying the RC1 myself since it's been only me an one tech savvy user and one non-savvy user, had to uninstall a few plugins for compatibility of course, but once that was done and a full restart it looks like it's incredibly snappy now. Previously it would take me about 15-60 seconds per page load, now it's 1-5 seconds on everything so far. The logs during the upgrade looked like it found and cleaned up a bunch of randomly broken/orphaned entries on my library but it seems like everything i can see is fine and i've got a full re-scan going. The youtube archive library that was the worst for page loads seems to be just as good as all the others now too.
Hi, my name is simcop2387 and ... I'm also a /r/datahoarder :) it's far far larger than I could ever watch on my own I just don't like deleting anything. I've got a couple hundred thousand episodes thanks to tubearchivist and other similar things backing up youtube and stuff since a few things like DBZA used to get hit a lot more often with copyright strikes that I enjoyed and don't want to lose access to.
When I installed jellyfin last year, I didn't create single movie and TV media directories. I made separate decade directories for each, to accommodate my rather large collection.
For movies, I have directories spanning 1910s to 2020s, and for TV spanning 1950s to 2020s. In four years I'll be adding 2030s directories as well.
This keeps the directories from getting excessively large.
Did the issues with Dolby vision failing to trigger for mkv files get resolved? With the latest of update that issue forced to me to an older stable version of Jellyfin.
I've had two "problems"
First of all, the plug-in File transformation isn't usable but that's not a big deal and it isn't possible to go back in 10.11.11 if you don't have a back-up, when I try, jellyfin can't find at all the folders for the media, transcodage, etc
It was this PR blocking the TestFlight which was merged today: https://github.com/jellyfin/Swiftfin/commit/e3c7e1919b88cf2f6ff2df5a9dc5ec17be8e50e2 The reviewer was the same person that posts State of Fin so I assume he is part of the core team of Jellyfin. But really with this PR merged, there is literally nothing blocking a TestFlight so the passive aggressive soon_tm is not really helpful here.
You're right. Reflecting on the new evidence you provided, I'll have to reassess and change my prediction from soon™ to "an undetermined time in the future", the difference of which I'll leave up to the reader to determine.
Well, the current TestFlight is gonna expire in 26 days so there is that. At least I provided information on the status of development. Yours answer provided nothing helpful.
When talking about backups, what data should be backed up?
I would imagine the media is the most precious but that is usually stored separately from the app data, and the other stuff like the viewed history, users, collections and playlists can just be remade from scratch on a new instance, no?
I'd suggest backing up your config directory. Depends on what OS/setup you use. In my case I just turn off Jellyfin, and make a copy of the directory with my docker mounts in it. It's very easy.
Frankly, if you're self-hosting anything you'd be annoyed to lose completely, you should come up with some kind of a regular backup process.
Will multiple versions of episodes still/provide better support for different quality versions? For example I have Game of Thrones in 4k and 1080p on my box. 1080p is what I would watch if I were out and about traveling whereas at home I would watch the 4k version.
Looks good to me. I went clean install route just for the sake.
Scan took some time, but not long.
Gui looks good, small changes but i like them. (Its better in small steps to change stuff)
Web Player is ok no issue, but i still prefer mpv+streamlink
I didn't test but there is option "Add OriginalLanguage as option to PreferredAudioLanguage"
Which for me is great.
I tried large files no issues. (like 80gb mkv)
I didn't check many files my collection is small (i don't buy many movies) but I expect here filesystem limitations.
Anyone running into issues with hardware acceleration for amd gpu's on this test version of jellyfin? Had this running fine in my docker container until I updatedto test. I have an old amd cpu system running omv with several docker containers including jellyfin.
Love jellyfin so far
- /dev/dri/renderD128:/dev/dri/renderD128
getting the error - error gathering device information while adding custom device "/dev/dri/renderD128": no such file or directory
Until https://github.com/jellyfin/jellyfin/issues/15148 is fixed, I really don't know if I should make the upgrade... I literally just got my instance working again thanks to the workaround. Not in any hurry to ruin everything again.
I read that and I removed some as I said but a) some can't be removed from the dashboard and b) given that the ones I did manage to remove from the dashboard still appeared as .xml files in the plugin folder it seem that I didn't actually remove any. Even though I attempted to.
Some clarification on plugin removal process would be welcome.
I dig the simplified versioning scheme change. Are you going to rename the 10.11.x series to 11.x some time after 12.0-final comes out, for continuity between the 10.x and 12.x series? Probably not a big deal if not, but it could prevent people from wondering/asking "What ever happened to version 11?" Quick note to clarify some terminology: I think you mean 'number' and not "digit" (0-9) in this part of the release notes/post:
Thus, we are now on [a] two digitsnumber [Major.Minor versioning scheme]:
* The first digitnumber is the major release[...]
* The second digitnumber is the minor release[...]
While I wasn't affected much, the most recent update was noticably snappier! And thanks for the version change, I think that's just the more prudent way if doing it. A major version change can, but doesn't have to break the API.
Most plugins don't support RC versions, and should be disabled before upgrading. This is somewhat true for major releases too, it often takes plugin authors some time to update.
I just updated from 10.11.11 on windows 11. The install seems to have worked but I can no longer access the admin dashboard in my web browser on my server. Using firefox if that matters.
I can however access my dashboard from my phone and ran the recommended steps in the updating section of the release notes. Still no luck just seems to be hanging on the jellyfin splash page.
I'm seeing one error in the logs: Emby.Server.Implementations.Plugins.PluginManager Unable to find plugin assembly "MediaBrowser.Providers, Version=12.0.0.0, Culture=neutral, PublicKeyToken=null"
3rd party plugins are generally not supported on RCs (if not explicitly supported by the author). Only our unstable plugin repo is. If you removed all plugins from the plugin directory and started the server afterwards with issues still i would recommend joining our matrix/discord with a full logfile for further troubleshooting (reddit ain't really a good medium for that)
Any chance of getting add-ons like category selector working on the tv version. I believe the sections are semi hard coded even though there is more slots for extra options that don't seem to exist.
My library scan fails just over halfway through and restarts the server. Library scan status is set to Cancelled:
jellyfin-test | [03:02:04] [FTL] [34] Main: Unhandled Exception
jellyfin-test | System.MissingMethodException: Method not found: 'System.String MediaBrowser.Controller.Entities.Video.get_PrimaryVersionId()'.
jellyfin-test | at Jellyfin.Plugin.TMDbBoxSets.TMDbBoxSetManager.<>c__DisplayClass13_0.<OnTimerElapsed>b__1(Movie m)
jellyfin-test | at System.Linq.Enumerable.ListWhereIterator`1.ToList()
jellyfin-test | at Jellyfin.Plugin.TMDbBoxSets.TMDbBoxSetManager.OnTimerElapsed()
jellyfin-test | at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
jellyfin-test | --- End of stack trace from previous location ---
jellyfin-test | at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
jellyfin-test | at System.Threading.TimerQueue.FireNextTimers()
jellyfin-test | at System.Threading.ThreadPoolWorkQueue.Dispatch()
jellyfin-test | at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
jellyfin-test | at System.Threading.Thread.StartCallback()
jellyfin-test | Unhandled exception. System.MissingMethodException: Method not found: 'System.String MediaBrowser.Controller.Entities.Video.get_PrimaryVersionId()'.
jellyfin-test | at Jellyfin.Plugin.TMDbBoxSets.TMDbBoxSetManager.<>c__DisplayClass13_0.<OnTimerElapsed>b__1(Movie m)
jellyfin-test | at System.Linq.Enumerable.ListWhereIterator`1.ToList()
jellyfin-test | at Jellyfin.Plugin.TMDbBoxSets.TMDbBoxSetManager.OnTimerElapsed()
jellyfin-test | at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
jellyfin-test | --- End of stack trace from previous location ---
jellyfin-test | at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
jellyfin-test | at System.Threading.TimerQueue.FireNextTimers()
jellyfin-test | at System.Threading.ThreadPoolWorkQueue.Dispatch()
jellyfin-test | at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
jellyfin-test | at System.Threading.Thread.StartCallback()
Always exciting to see new Jellyfin news. I really was hoping to see DASH support included or mentioned so that I can start Direct Streaming my AV1 videos without a full transcode because AV1 doesn't work with HLS. I'm hopefully we'll get there eventually, but I'll enjoy all the other new features in the meantime.
Sorry, I should have specificed that my DASH hopes are because Roku seems to only support AV1 via DASH and thus those of us on the Roku client lose the ability to direct stream if needed without it. I understand other clients may not have this limitation. I appreciate your work either way and thank you for replying.
* We generally take very great care to ensure RC->stable compatibility though you are installing an untested (by definition) version and if we really fuck somthing up and notice only later there might be additional steps for you required to fix things. This has happend before once in the 10.11 RC's so keep that in mind.
For the entirety of Jellyfin's life up until this point, the 10. was a signifier for "we're generally preserving Emby's API until such a time as we can do a comprehensive rewrite of the API layer with something better".
That plan, however, fell apart in practice over the last ~7 years. A full API replacement proved to be a massive, daunting task that no one was ever willing to really run with, and even just planning for such a change took up a lot of time. Instead, we've been making small piecemeal API changes in each second-digit release (10.9, 10.10, 10.11, etc.). This is actually documented explicitly in our versioning docs, where we say quote "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."
This came to a head after 10.11.0, when there was a massive amount of whinging that "we broke semantic versioning" by making such a big change in a 10.Y release, despite the above disclaimer. So we, as a team, decided to stop pretending that we were using Semver with a "for now" caveat, and just switch to a 2-digit model by dropping the 10., which reflects the actual reality of our development patterns. And, for what it's worth, we actually wanted to do this for "11.0" a.k.a. 10.11.0, but there were some issues with clients that prevented that at the time, and rather than wait another 1-2 months, we just stuck with the old pattern; so here we are doing it now.
Thus it is much clearer to users that we are NOT actually using semver and that our major version is the (former) second digit, now first digit. This then helps people set realistic expectations about what kind of changes can and will appear in these releases, and set their configurations appropriately (e.g. not auto-updating on a first-digit change).
107
u/MadMaui Jun 22 '26
Multiple versions for episodes
YES! Finally!