starred/jellyfin
1
0
Fork 0
mirror of https://github.com/jellyfin/jellyfin.git synced 2026-07-16 05:43:54 +03:00
Code Issues 822 Packages Projects Releases 17 Wiki Activity

Inconsistent HTTP response times after upgrading to 10.11.0 #7556

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

Originally created by @Jacajack on GitHub (Oct 25, 2025).

Description of the bug

After upgrading to Jellyfin 10.11.0, I noticed that the HTTP server response times have degraded. Sometimes they exceed 1s which causes status check fails in my Netdata dashboard.

You can clearly see the point at which the upgrade happened here:
Image

The failed status checks correspond to such entries in my nginx logs:

127.0.0.1 - - - [24/Oct/2025:12:11:33 +0200] "GET /web/ HTTP/1.1" 499 0 "https://127.0.0.1:2287" "Netdata go.d.plugin/v2.7.0-102-nightly" 0.996 _ "-" "TLSv1.3" "TLS_AES_128_GCM_SHA256" amarok_client_id="" mtls_info="---"

This means that some of the responses take longer than 1s and Netdata times out the connection.

Reproduction steps

Run this command for a while to gather a sample of response times. Analyze them in tool of your choosing.

while true; do curl -w "%{time_total}\n" -o /dev/null -s http://127.0.0.1:3387/web | tee -a resp_times.txt; done

In my case this command accesses the Jellyfin web server directly (bypassing nginx).

What is the current bug behavior?

A very dumb statistical analysis shows some outlying response times up to 1s:

$ sort resp_times.txt | awk '{printf("%.2f\n", $1);}' | uniq -c
 127355 0.00
     34 0.01
      1 0.51
      1 0.52
      1 0.54
      1 0.55
      1 0.59
      2 0.63
      1 0.64
      1 0.67
      1 0.69
      2 0.71
      2 0.75
      1 0.76
      2 0.79
      2 0.83
      3 0.86
      1 0.87
      1 0.91
      1 0.93
      2 0.94
      1 0.95
      2 0.97
      1 0.98
      2 0.99
      1 1.00

Or as a histogram (1% outliers merged) if you like:
Image

What is the expected correct behavior?

The response times should be consistent.

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

Environment

- OS: Arch Linux
- Linux Kernel: 6.12.52-1-lts
- Virtualization: Docker
- Clients: Browser, curl
- Browser: Firefox
- FFmpeg Version: N/A 
- Playback Method: N/A
- Hardware Acceleration: QSV
- GPU Model: UHD Graphics 630
- Plugins: Open Subtitles
- Reverse Proxy: nginx
- Base URL: none
- Networking: Bridge/NAT
- Jellyfin Data Storage: SDD
- Media Storage: HDD
- External Integrations: none

Jellyfin logs

Jellyfin does not log anything at the relevant timestamps.

FFmpeg logs

Client / Browser logs

No response

Relevant screenshots or videos

No response

Additional information

No response

Originally created by @Jacajack on GitHub (Oct 25, 2025). ### Description of the bug After upgrading to Jellyfin 10.11.0, I noticed that the HTTP server response times have degraded. Sometimes they exceed 1s which causes status check fails in my Netdata dashboard. You can clearly see the point at which the upgrade happened here: <img width="869" height="1053" alt="Image" src="https://github.com/user-attachments/assets/45c1f191-83cb-41db-8f0f-366d00b1c71a" /> The failed status checks correspond to such entries in my nginx logs: ``` 127.0.0.1 - - - [24/Oct/2025:12:11:33 +0200] "GET /web/ HTTP/1.1" 499 0 "https://127.0.0.1:2287" "Netdata go.d.plugin/v2.7.0-102-nightly" 0.996 _ "-" "TLSv1.3" "TLS_AES_128_GCM_SHA256" amarok_client_id="" mtls_info="---" ``` This means that some of the responses take longer than 1s and Netdata times out the connection. ### Reproduction steps Run this command for a while to gather a sample of response times. Analyze them in tool of your choosing. ```bash while true; do curl -w "%{time_total}\n" -o /dev/null -s http://127.0.0.1:3387/web | tee -a resp_times.txt; done ``` In my case this command accesses the Jellyfin web server directly (bypassing nginx). ### What is the current _bug_ behavior? A very dumb statistical analysis shows some outlying response times up to 1s: ``` $ sort resp_times.txt | awk '{printf("%.2f\n", $1);}' | uniq -c 127355 0.00 34 0.01 1 0.51 1 0.52 1 0.54 1 0.55 1 0.59 2 0.63 1 0.64 1 0.67 1 0.69 2 0.71 2 0.75 1 0.76 2 0.79 2 0.83 3 0.86 1 0.87 1 0.91 1 0.93 2 0.94 1 0.95 2 0.97 1 0.98 2 0.99 1 1.00 ``` Or as a histogram (1% outliers merged) if you like: <img width="752" height="460" alt="Image" src="https://github.com/user-attachments/assets/87fc381a-5c1d-4303-8dd5-6a76a3648fa8" /> ### What is the expected _correct_ behavior? The response times should be consistent. ### 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 ### Environment ```markdown - OS: Arch Linux - Linux Kernel: 6.12.52-1-lts - Virtualization: Docker - Clients: Browser, curl - Browser: Firefox - FFmpeg Version: N/A - Playback Method: N/A - Hardware Acceleration: QSV - GPU Model: UHD Graphics 630 - Plugins: Open Subtitles - Reverse Proxy: nginx - Base URL: none - Networking: Bridge/NAT - Jellyfin Data Storage: SDD - Media Storage: HDD - External Integrations: none ``` ### Jellyfin logs ```shell Jellyfin does not log anything at the relevant timestamps. ``` ### FFmpeg logs ```shell ``` ### Client / Browser logs _No response_ ### Relevant screenshots or videos _No response_ ### Additional information _No response_
OVERLORD added the bugperformance labels 2026-02-07 05:10:49 +03:00
OVERLORD commented 2026-02-07 05:10:52 +03:00
Author
Owner
Copy Link

@Jacajack commented on GitHub (Oct 28, 2025):

This appears to have been fixed in 10.11.1. I'll let it run for a couple of days more and close this issue if I don't notice any degradation.

@Jacajack commented on GitHub (Oct 28, 2025): This appears to have been fixed in 10.11.1. I'll let it run for a couple of days more and close this issue if I don't notice any degradation.
OVERLORD commented 2026-02-07 05:10:53 +03:00
Author
Owner
Copy Link

@felizk commented on GitHub (Oct 31, 2025):

I'm seeing very similar results. I noticed if I refresh the jellyfin web UI in a browser while running this the response times spike terribly. (on 10.11.1)

@felizk commented on GitHub (Oct 31, 2025): I'm seeing very similar results. I noticed if I refresh the jellyfin web UI in a browser while running this the response times spike terribly. (on 10.11.1)
OVERLORD commented 2026-02-07 05:10:53 +03:00
Author
Owner
Copy Link

@Jacajack commented on GitHub (Nov 1, 2025):

You're right, it's not fixed. Interestingly, after I upgraded Jellyfin on 28th, the response times went back to normal for a while, but they are still degraded now.

Image
@Jacajack commented on GitHub (Nov 1, 2025): You're right, it's not fixed. Interestingly, after I upgraded Jellyfin on 28th, the response times went back to normal for a while, but they are still degraded now. <img width="1506" height="479" alt="Image" src="https://github.com/user-attachments/assets/d572d43f-bb17-462c-aa1f-7a1e1e8868cf" />
OVERLORD commented 2026-02-07 05:10:54 +03:00
Author
Owner
Copy Link

@jacobthemagicalpanda commented on GitHub (Nov 4, 2025):

I am having this same issue I found a similar issue #15097 I am on 10.11.2 so it seems that the most recent update did not fix it. My CPU usage is not bad unless I load the home screen or a media page like movies. If i sit idle on the screen or watch something my CPU usage is not super high

@jacobthemagicalpanda commented on GitHub (Nov 4, 2025): I am having this same issue I found a similar issue #15097 I am on 10.11.2 so it seems that the most recent update did not fix it. My CPU usage is not bad unless I load the home screen or a media page like movies. If i sit idle on the screen or watch something my CPU usage is not super high
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#7556
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?