mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-07-16 05:43:54 +03:00
[10.11.0] Seasons take a while to appear in a TV show, whereas Cast and More Like This appear beforehand
#7419
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @HammyHavoc on GitHub (Oct 15, 2025).
Description of the bug
All the RC builds for the latest version have given me this issue.
Reproduction steps
Open a TV show with a fair few seasons and episodes (in my case, it's a daily TV show I did post-production on for quite a few years and similar results with other equally large documentary series I've worked on).
What is the current bug behavior?
Seasons for a lot of things take an abnormally long amount of time to appear, yet
Cast & CrewandMore Like Thisappear long before the seasons do, if they do whatsoever. Sometimes it appears to time out as onlyNext Upappears, resulting in the seasons not appearing. Sometimes they appear after a while if I refresh, other times, they don't. The larger the number of seasons/episodes, the more frequent this problem appears to be.What is the expected correct behavior?
That they would appear as fast as browsing through the libraries in general. Bizarre to me why this would be so slow.
Jellyfin Server version
10.10.0+
Specify commit id
No response
Specify unstable release number
No response
Specify version number
No response
Specify the build version
10.11.0-rc9
Environment
Jellyfin logs
FFmpeg logs
Client / Browser logs
No response
Relevant screenshots or videos
No response
Additional information
No response
@Simon-Eklundh commented on GitHub (Oct 15, 2025):
I've done a bit of work figuring this out. this is indeed an issue in jellyfin rc9. it seems to specifically be a problem with the /Shows/{userId}/Seasons. specifically when the api call includes the userId query param.
example:
calling 10.10.7 with userid: 657ms
calling 10.10.7 without userid: 4ms
calling 10.11.0-rc9 with userid: 36.2s (note seconds not ms)
calling 10.11.9-rc9 without userId: 14ms
@clowncracker commented on GitHub (Oct 29, 2025):
Is this being prioritized? This is probably my biggest issue with 10.11.x.
@DragoPrime commented on GitHub (Oct 30, 2025):
Yup, it takes about 24 hours for the season to appear. I need to do a full metadata update to show the season earlier.
@clowncracker commented on GitHub (Oct 30, 2025):
That's not the problem I have and I'm fairly certain sure that's not the issue outlined in this ticket. The issue here is this UI element is slow to load, not that there are specific seasons showing up or requiring metadata refreshes to have seasons appear. I think the issue you're having is unrelated to this ticket.
@HammyHavoc commented on GitHub (Oct 30, 2025):
Yes, totally different issue! Thanks for chiming in about that, it's appreciated.
@matthewpritchett commented on GitHub (Nov 8, 2025):
I'm also seeing this issue on shows with large number of seasons.
@clowncracker commented on GitHub (Nov 14, 2025):
@theguymadmax just wanted to follow up on this again, any movement on this ticket?
@theguymadmax commented on GitHub (Nov 14, 2025):
The next bug fix should be released in the next few days, but I don’t think there’s anything in particular that would help with this issue. There is one major migration bug that will be included that could help, but it only affects users upgrading from 10.10.x directly to 10.11.3. If you have a backup of the 10.10.x version (note that you can’t roll back; it must be a backup copy), you could try re-migrating. However, running a scan with the “Scan for missing metadata” option on all libraries individually should have the same effect as the bug fix, which now correctly migrates existing ancestor IDs.
One tip I can share is to disable “Display specials within seasons they aired in” under Dashboard → Libraries → Display. This reduced the load time from 5 seconds to 1 second for a series I have that contains a large number of seasons.
@HammyHavoc commented on GitHub (Nov 14, 2025):
This sounds interesting! Any info on remigrating? Would be interested in having a play around with this.
Do you know if user passwords are a part of that backup copy? Ergo, remigrating would change passwords?
@clowncracker commented on GitHub (Nov 14, 2025):
Will running a
Search for missing metadatascan for each individually library in 10.11.2 work or is the fix being released in 10.11.3?@theguymadmax commented on GitHub (Nov 14, 2025):
Sorry if that last post wasn’t clear. There was a bug with 10.11.0 → 10.11.2 for users migrating their old DB from 10.10.x. The ancestorids were not migrated. This caused several issues, such as not being able to play or shuffle an album, playlists disappearing, and seasons not displaying any episodes if the “Display specials within seasons they aired in” option was disabled, plus probably many other issues. Ancestorids are re-created when you scan libraries with the “scan for missing metadata” option, but you have to do this individually for each library, as there is no option to do it for all libraries at once. Also, due to other issues, many people have errors, such as DB locks, so these scans will fail. Sometimes you may need to scan multiple times for the database to repopulate with the ancestorids.
The bug fix only applies to users doing a database migration from 10.10.x to 10.11.3. When I said re-migrate, I meant that if you have a full backup of 10.10.x, then you could restore that and then do the upgrade from 10.10.x to 10.11.3. Yes, you would lose all userdata since making that backup, since this is a restore from backup.
Yes, you don’t need to wait for 10.11.3. Running a “Search for missing metadata” scan for each library in 10.11.2 will have the same effect as running it on 10.11.3, it will restore the missing ancestorids.
This is why we put this in the release notes:
“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.”
Now we know about the bug, and that it affected more than the music library. A scan for missing metadata should be done for all libraries. Although, like I said, I don’t know if it will solve slow loading, but it should be done regardless.
@matthewpritchett commented on GitHub (Nov 14, 2025):
@theguymadmax just for more data points. I did have the bug you were describing and did the missing items scan. Unfortunately, my seasons still take a long time to load on shows with lots of seasons. Like 30-50 seasons takes around 30-60 seconds to show up in web ui.
@HammyHavoc commented on GitHub (Nov 15, 2025):
When attempting to run a scan for missing metadata, it doesn't seem to end up happening. I don't see anything in the
Logs,DashboardorLibrariessection to indicate it (or anything else) is currently running.@HammyHavoc commented on GitHub (Nov 15, 2025):
Running
Scan All Librariesresults in a progress bar appearing, but I'm guessing that's not the same as scanning for missing metadata?@clowncracker commented on GitHub (Nov 15, 2025):
Based on this ticket: https://github.com/jellyfin/jellyfin/issues/15014 the issue has potentially been identified, has this been looked at by the def team?
@DwayneGoddem commented on GitHub (Jan 16, 2026):
This issue is still in 10.11.5 I use the THE SIMPSONS as the test as it has 38 seasons and they NEVER show up.
I have even moved to a different folder out of the library scanned to make sure it was removed from Jellyfin did a DB cleanup task etc.
Moved it back did a full scan and it will only show the newest EP when you go to the TV Show page.
I have also tested in this weeks unstable build but they is way slower that 10.11.5 even in home page.
@matthewpritchett commented on GitHub (Jan 16, 2026):
Agreed, still seeing the same issue.
@methbkts commented on GitHub (Jan 16, 2026):
I wish I never updated to 10.11 😅