starred/jellyfin
1
0
Fork 0
mirror of https://github.com/jellyfin/jellyfin.git synced 2026-05-04 18:09:12 +03:00
Code Issues 822 Packages Projects Releases 10 Wiki Activity

Performance - Season folders slow to load #7233

New Issue
Open
opened 2026-02-07 04:44:07 +03:00 by OVERLORD · 10 comments
OVERLORD commented 2026-02-07 04:44:07 +03:00
Owner
Copy Link

Originally created by @mojothemonkey2 on GitHub (Aug 9, 2025).

Description of the bug

Season folders can take a long while to load.
Especially for shows with many series, it seems to be exponentially worse.
Inspecting network timings with chrome, the cause is the Shows/<id>/Seasons api call.
I can verify this with a curl to the api.

Interestingly if we call the api adding enableUserData=false, it will only take a fraction of a second to run.

The problem is several times worse on v10.11.0/master.

Some timings (for show with 36 series):

cpu              v10.7.0      v10.11.0
Intel N6005      2s           6s
ARM A55          12s          47s

I put some performance logging in, and traced it as far as this bit of the code:
601ce4c3b1/MediaBrowser.Controller/Entities/Folder.cs (L1702-L1714)
But I don't yet know what it is doing under the hood.
I can see it is fetching userdata for one series at a time, but this alone does not explain why it takes so long. Each series takes 1.2s or more (on the A55, v10.11.0), while the query for the whole show without userdata takes 0.2s.
I also see that during the call, the cpu usage is maxed out (for 1 core at least). Perhaps also indicating more to the problem than per-series db calls.

Reproduction steps

Using chrome to inspect network traffic, while browsing to a TV show, we can find the Season api call, with user and show ids.
We can create an api token in the dashboard, so that we can access the api via curl.
Then we can construct a curl command like:

TOKEN=****
SHOW=db391fa226a17534ea33faef2ead66c5
USER=023f23d597294a5a9d316e12ec9d851f
time curl -s -H "X-MediaBrowser-Token: $TOKEN" "http://localhost:8096/Shows/$SHOW/Seasons?userId=$USER&Fields=ItemCounts%2CPrimaryImageAspectRatio%2CCanDelete%2CMediaSourceCount"

...json output here...

real    0m56.424s
user    0m0.037s
sys     0m0.037s

What is the current bug behavior?

Shows//Seasons api call, with userdata can take many seconds to run.

What is the expected correct behavior?

The api call should be sub 1 second.

Jellyfin Server version

Master

Specify commit id

b00e381109

Specify unstable release number

No response

Specify version number

No response

Specify the build version

10.11.0

Environment

- OS: Ubuntu 22.04
- Linux Kernel: 5.15.118
- Virtualization: no
- Clients: Browser/Curl
- Browser: Chrome
- FFmpeg Version: 4.4.2 
- Playback Method: n/a
- Hardware Acceleration: none
- GPU Model: n/a
- Plugins: none
- Reverse Proxy: no
- Base URL: none
- Networking: host
- Jellyfin Data Storage: local sata SSD
- Media Storage: local sata HDD
- External Integrations: none

Jellyfin logs

The Seasons api call is not logged in the code.

FFmpeg logs

Client / Browser logs

No response

Relevant screenshots or videos

No response

Additional information

I see another ticket re performance issues on v10.11.0 https://github.com/jellyfin/jellyfin/issues/14278
It does not mention this specific problem, but perhaps related to worsening performance on this version.

Originally created by @mojothemonkey2 on GitHub (Aug 9, 2025). ### Description of the bug Season folders can take a long while to load. Especially for shows with many series, it seems to be exponentially worse. Inspecting network timings with chrome, the cause is the `Shows/<id>/Seasons` api call. I can verify this with a curl to the api. Interestingly if we call the api adding `enableUserData=false`, it will only take a fraction of a second to run. The problem is several times worse on v10.11.0/master. Some timings (for show with 36 series): ``` cpu v10.7.0 v10.11.0 Intel N6005 2s 6s ARM A55 12s 47s ``` I put some performance logging in, and traced it as far as this bit of the code: https://github.com/jellyfin/jellyfin/blob/601ce4c3b1033169d9ae615045b2780df844cd62/MediaBrowser.Controller/Entities/Folder.cs#L1702-L1714 But I don't yet know what it is doing under the hood. I can see it is fetching userdata for one series at a time, but this alone does not explain why it takes so long. Each series takes 1.2s or more (on the A55, v10.11.0), while the query for the whole show without userdata takes 0.2s. I also see that during the call, the cpu usage is maxed out (for 1 core at least). Perhaps also indicating more to the problem than per-series db calls. ### Reproduction steps Using chrome to inspect network traffic, while browsing to a TV show, we can find the Season api call, with user and show ids. We can create an api token in the dashboard, so that we can access the api via curl. Then we can construct a curl command like: ``` TOKEN=**** SHOW=db391fa226a17534ea33faef2ead66c5 USER=023f23d597294a5a9d316e12ec9d851f time curl -s -H "X-MediaBrowser-Token: $TOKEN" "http://localhost:8096/Shows/$SHOW/Seasons?userId=$USER&Fields=ItemCounts%2CPrimaryImageAspectRatio%2CCanDelete%2CMediaSourceCount" ...json output here... real 0m56.424s user 0m0.037s sys 0m0.037s ``` ### What is the current _bug_ behavior? Shows/<id>/Seasons api call, with userdata can take many seconds to run. ### What is the expected _correct_ behavior? The api call should be sub 1 second. ### Jellyfin Server version Master ### Specify commit id b00e381109d1d3b1d83da0ed678b8b27d70341d1 ### Specify unstable release number _No response_ ### Specify version number _No response_ ### Specify the build version 10.11.0 ### Environment ```markdown - OS: Ubuntu 22.04 - Linux Kernel: 5.15.118 - Virtualization: no - Clients: Browser/Curl - Browser: Chrome - FFmpeg Version: 4.4.2 - Playback Method: n/a - Hardware Acceleration: none - GPU Model: n/a - Plugins: none - Reverse Proxy: no - Base URL: none - Networking: host - Jellyfin Data Storage: local sata SSD - Media Storage: local sata HDD - External Integrations: none ``` ### Jellyfin logs ```shell The Seasons api call is not logged in the code. ``` ### FFmpeg logs ```shell ``` ### Client / Browser logs _No response_ ### Relevant screenshots or videos _No response_ ### Additional information I see another ticket re performance issues on v10.11.0 https://github.com/jellyfin/jellyfin/issues/14278 It does not mention this specific problem, but perhaps related to worsening performance on this version.
OVERLORD added the bugperformance labels 2026-02-07 04:44:07 +03:00
OVERLORD commented 2026-02-07 04:44:08 +03:00
Author
Owner
Copy Link

@mojothemonkey2 commented on GitHub (Aug 11, 2025):

Some progress in the right direction..

If we enabled db logging in config/logging.default.json:
"Microsoft.EntityFrameworkCore.Database.Command": "Information"

We can see that for each Season the db query matches using:
"b"."SeriesPresentationUniqueKey" = @__filter_SeriesPresentationUniqueKey_1
but, as far as I can see, this is the id for the whole Show.
So we are fetching the whole Show for each season, 36 times over in my case.

Now, if we amend the query in Series.cs to use ParentId (same as done for SourceType=Channel):

--- a/MediaBrowser.Controller/Entities/TV/Series.cs
+++ b/MediaBrowser.Controller/Entities/TV/Series.cs
@@ -400,6 +400,7 @@ namespace MediaBrowser.Controller.Entities.TV
             }
             else
             {
+                query.Parent = parentSeason;
                 allItems = LibraryManager.GetItemList(query);
             }

Then it will append the db query matching with:
"b"."ParentId" = @__filter_ParentId_0

And this way return just one Season at a time.
With this, the api call time on my A55 is down from 47s to 7s (v10.11.0).
Clearly an improvement.
(Though perhaps a better approach would be to query the whole Show in a single query, and remove the iteration. But this would be a large job).

Downside, it appears to break the episode counts for "Season Unknown", which I guess is the specials.
So needs further fine tuning.

@mojothemonkey2 commented on GitHub (Aug 11, 2025): Some progress in the right direction.. If we enabled db logging in config/logging.default.json: "Microsoft.EntityFrameworkCore.Database.Command": "Information" We can see that for each Season the db query matches using: "b"."SeriesPresentationUniqueKey" = @__filter_SeriesPresentationUniqueKey_1 but, as far as I can see, this is the id for the whole Show. So we are fetching the whole Show for each season, 36 times over in my case. Now, if we amend the query in Series.cs to use ParentId (same as done for SourceType=Channel): ``` --- a/MediaBrowser.Controller/Entities/TV/Series.cs +++ b/MediaBrowser.Controller/Entities/TV/Series.cs @@ -400,6 +400,7 @@ namespace MediaBrowser.Controller.Entities.TV } else { + query.Parent = parentSeason; allItems = LibraryManager.GetItemList(query); } ``` Then it will append the db query matching with: "b"."ParentId" = @__filter_ParentId_0 And this way return just one Season at a time. With this, the api call time on my A55 is down from 47s to 7s (v10.11.0). Clearly an improvement. (Though perhaps a better approach would be to query the whole Show in a single query, and remove the iteration. But this would be a large job). Downside, it appears to break the episode counts for "Season Unknown", which I guess is the specials. So needs further fine tuning.
OVERLORD commented 2026-02-07 04:44:09 +03:00
Author
Owner
Copy Link

@mojothemonkey2 commented on GitHub (Aug 12, 2025):

The specials seems to be at the centre of the issue...

I notice my problematic Show has 6 special episodes within Season 4.
If I amend the setting:
Libraries > Display > Display specials within season they aired in = yes (default) > no
It makes a huge difference. Here are the timings on my A55 with the setting enabled/dislabed:

                       v10.11.0    v10.10.7
Display specials=yes   47s         12s
Display specials=no    13s         0.5s

So on v10.10.7, with specials disabled the seasons load in just 0.5s! And with db logging enabled, there does not even seem to be any db query necessary in this case?!
While on v10.11.0, there appears to be one db query per Season using PresentationUniqueKey, though for some reason not as bad as with specials enabled.

Note, on either version, whether specials are enabled or not, they are still shown in Season 4, and the unplayed count remains the same at 28 (22 normal episodes + 6 specials).

And the json output of the Seasons api call is not changed much.
On v10.11.0, specials disabled just yields UnplayedItemCount=0 for "Season Unknown".
On v10.7.0, there is no "Season Unknown", and specials disabled makes no difference at all!

So perhaps some work around specials was being added for v10.11.0, but it leads to a lot heavier db work.

@mojothemonkey2 commented on GitHub (Aug 12, 2025): The specials seems to be at the centre of the issue... I notice my problematic Show has 6 special episodes within Season 4. If I amend the setting: Libraries > Display > Display specials within season they aired in = yes (default) > no It makes a huge difference. Here are the timings on my A55 with the setting enabled/dislabed: ``` v10.11.0 v10.10.7 Display specials=yes 47s 12s Display specials=no 13s 0.5s ``` So on v10.10.7, with specials disabled the seasons load in just 0.5s! And with db logging enabled, there does not even seem to be any db query necessary in this case?! While on v10.11.0, there appears to be one db query per Season using PresentationUniqueKey, though for some reason not as bad as with specials enabled. Note, on either version, whether specials are enabled or not, they are still shown in Season 4, and the unplayed count remains the same at 28 (22 normal episodes + 6 specials). And the json output of the Seasons api call is not changed much. On v10.11.0, specials disabled just yields UnplayedItemCount=0 for "Season Unknown". On v10.7.0, there is no "Season Unknown", and specials disabled makes no difference at all! So perhaps some work around specials was being added for v10.11.0, but it leads to a lot heavier db work.
OVERLORD commented 2026-02-07 04:44:11 +03:00
Author
Owner
Copy Link

@mojothemonkey2 commented on GitHub (Aug 12, 2025):

So I RTFM https://jellyfin.org/docs/general/server/media/shows#show-specials
My specials were mixed in with the numbered season folders, but they should be in their own folder, so I moved them to "Season 00".

This fixes the "Season Unknown" in the json output, it now reads "Specials".
And I now see Specials in the json using v10.7.0 too.

The manual also explains why there is no difference in the json with DisplaySpecialsWithinSeasons enabled/disabled, since there is also extra metadata config needed.

The performance numbers remain the same though.
OK for v10.7.0, since we can disable DisplaySpecialsWithinSeasons to make things nice and speedy.
(maybe it should be disabled by default? given the high impact on performance, and it won't make any difference without the extra metadata config).

But v10.11.0 can still be pretty slow, at 12s with DisplaySpecialsWithinSeasons disabled.

@mojothemonkey2 commented on GitHub (Aug 12, 2025): So I RTFM https://jellyfin.org/docs/general/server/media/shows#show-specials My specials were mixed in with the numbered season folders, but they should be in their own folder, so I moved them to "Season 00". This fixes the "Season Unknown" in the json output, it now reads "Specials". And I now see Specials in the json using v10.7.0 too. The manual also explains why there is no difference in the json with DisplaySpecialsWithinSeasons enabled/disabled, since there is also extra metadata config needed. The performance numbers remain the same though. OK for v10.7.0, since we can disable DisplaySpecialsWithinSeasons to make things nice and speedy. (maybe it should be disabled by default? given the high impact on performance, and it won't make any difference without the extra metadata config). But v10.11.0 can still be pretty slow, at 12s with DisplaySpecialsWithinSeasons disabled.
OVERLORD commented 2026-02-07 04:44:12 +03:00
Author
Owner
Copy Link

@mojothemonkey2 commented on GitHub (Aug 12, 2025):

Retrying query.Parent = parentSeason change on v10.11,0 change with specials moved to Season00.

The json output is now the same before and after the change with correct unplayed count for Specials.
(Not sure if it would break anything if we had the extra metadata configured such that specials would should within season folders).
So maybe the change is worthwhile on it's own, to improve performance when DisplaySpecialsWithinSeasons=yes.

But with or without DisplaySpecialsWithinSeasons enabled, the api call takes 7s to run on my A55, which is not great.

So the main issue is with v10.11.0 performance in general, which may be the same as https://github.com/jellyfin/jellyfin/issues/14278

@mojothemonkey2 commented on GitHub (Aug 12, 2025): Retrying `query.Parent = parentSeason` change on v10.11,0 change with specials moved to Season00. The json output is now the same before and after the change with correct unplayed count for Specials. (Not sure if it would break anything if we had the extra metadata configured such that specials would should within season folders). So maybe the change is worthwhile on it's own, to improve performance when DisplaySpecialsWithinSeasons=yes. But with or without DisplaySpecialsWithinSeasons enabled, the api call takes 7s to run on my A55, which is not great. So the main issue is with v10.11.0 performance in general, which may be the same as https://github.com/jellyfin/jellyfin/issues/14278
OVERLORD commented 2026-02-07 04:44:13 +03:00
Author
Owner
Copy Link

@jellyfin-bot commented on GitHub (Dec 11, 2025):

This issue has gone 120 days without an update and will be closed within 21 days if there is no new activity. To prevent this issue from being closed, please confirm the issue has not already been fixed by providing updated examples or logs.

If you have any questions you can use one of several ways to contact us.

@jellyfin-bot commented on GitHub (Dec 11, 2025): This issue has gone 120 days without an update and will be closed within 21 days if there is no new activity. To prevent this issue from being closed, please confirm the issue has not already been fixed by providing updated examples or logs. If you have any questions you can use one of several ways to [contact us](https://jellyfin.org/contact).
OVERLORD commented 2026-02-07 04:44:14 +03:00
Author
Owner
Copy Link

@hollanbm commented on GitHub (Dec 11, 2025):

This issue has gone 120 days without an update and will be closed within 21 days if there is no new activity. To prevent this issue from being closed, please confirm the issue has not already been fixed by providing updated examples or logs.

If you have any questions you can use one of several ways to contact us.

Not fixed

@hollanbm commented on GitHub (Dec 11, 2025): > This issue has gone 120 days without an update and will be closed within 21 days if there is no new activity. To prevent this issue from being closed, please confirm the issue has not already been fixed by providing updated examples or logs. > > If you have any questions you can use one of several ways to [contact us](https://jellyfin.org/contact). Not fixed
OVERLORD commented 2026-02-07 04:44:15 +03:00
Author
Owner
Copy Link

@cgbspender commented on GitHub (Jan 6, 2026):

This is still not fixed as of 10.11.5 and makes using Jellyfin for TV kind of useless if it takes several minutes to load the seasons of a TV show.

@cgbspender commented on GitHub (Jan 6, 2026): This is still not fixed as of 10.11.5 and makes using Jellyfin for TV kind of useless if it takes several minutes to load the seasons of a TV show.
OVERLORD commented 2026-02-07 04:44:16 +03:00
Author
Owner
Copy Link

@v3DJG6GL commented on GitHub (Jan 7, 2026):

this plugin helps a lot for various loading issues: https://github.com/pelluch/jellyfin-plugin-disable-user-data

@v3DJG6GL commented on GitHub (Jan 7, 2026): this plugin helps a lot for various loading issues: https://github.com/pelluch/jellyfin-plugin-disable-user-data
OVERLORD commented 2026-02-07 04:44:17 +03:00
Author
Owner
Copy Link

@BoHoliday commented on GitHub (Jan 20, 2026):

this plugin helps a lot for various loading issues: https://github.com/pelluch/jellyfin-plugin-disable-user-data

It doesn't help with season loading.

@BoHoliday commented on GitHub (Jan 20, 2026): > this plugin helps a lot for various loading issues: https://github.com/pelluch/jellyfin-plugin-disable-user-data It doesn't help with season loading.
OVERLORD commented 2026-02-07 04:44:18 +03:00
Author
Owner
Copy Link

@cawnull commented on GitHub (Jan 28, 2026):

What fixed the season loading problem for me was turning ON the setting "Libraries -> Display -> Display specials within seasons they aired in". Immediately resolved the long loading time of seasons. Still a bug to be resolved, but that's the workaround for me for now.

@cawnull commented on GitHub (Jan 28, 2026): What fixed the season loading problem for me was turning ON the setting "Libraries -> Display -> Display specials within seasons they aired in". Immediately resolved the long loading time of seasons. Still a bug to be resolved, but that's the workaround for me for now.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
EFjellyfin.db
area:database
awaiting-feedback
backend
blocked
breaking change: web api
bug
build
ci
confirmed
discussion needed
dotnet future
downstream
duplicate
enhancement
feature
future
github-actions
good first issue
hdr
help wanted
invalid
investigation
librarydb
live-tv
lyrics
media playback
music
needs testing
nuget
performance
platform
pull-request
Mirrored from GitHub Pull Request
 question
regression
release critical
requires-web
roadmap
security
security
stale
support
syncplay
ui & ux
upstream
wontfix
No Label bug performance
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/jellyfin#7233
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?