starred/jellyfin

Fork 0

mirror of https://github.com/jellyfin/jellyfin.git synced 2026-01-23 23:20:51 +01:00

High CPU usage due to MediaSegments and TrickplayInfos SELECT DbCommands #6773

New issue

Closed

opened 2025-12-22 04:46:40 +01:00 by backuprepo · 4 comments

backuprepo commented

2025-12-22 04:46:40 +01:00

Owner

Originally created by @Skaytacium on GitHub (Feb 26, 2025).

Description of the bug

I recently noticed extremely high CPU usage by the jellyfin process during playback (paused or resumed) of any content. It looks like the following when playback is paused:

and like the following during playback (completely uses up ~200% of CPU (2 cores)):

This happens regardless of the client (tried on jellyfin-media-player, jellyfin mpv shim and the jellyfin android app). This is on direct streaming, since the above pictures are the CPU usage of the jellyfin process and not any ffmpeg processes.

Since initially I figured it might be an issue with some of the plugins (namely, Playback Reporting and Kodi Sync Queue), I uninstalled both and checked but the issue still persisted.

I have already tried debugging this on the troubleshooting channel on the jellyfin server, but a solution wasn't found.

What seemed odd to me was the no. Executed DbCommand logs that seemed to match with the exact timing of the CPU usage spiking while paused and were constantly thrown during resumed playback. They were the following repeated over and over:

[2025-02-26 05:51:36.907 +05:30] [INF] [19] Microsoft.EntityFrameworkCore.Database.Command: Executed DbCommand ("0"ms) [Parameters=["@__itemId_0='?' (DbType = Guid)"], CommandType='Text', CommandTimeout='30']"
""SELECT EXISTS (
    SELECT 1
    FROM \"MediaSegments\" AS \"m\"
    WHERE \"m\".\"ItemId\" = @__itemId_0)"
[2025-02-26 05:51:36.909 +05:30] [INF] [19] Microsoft.EntityFrameworkCore.Database.Command: Executed DbCommand ("0"ms) [Parameters=["@__itemId_0='?' (DbType = Guid)"], CommandType='Text', CommandTimeout='30']"
""SELECT EXISTS (
    SELECT 1
    FROM \"MediaSegments\" AS \"m\"
    WHERE \"m\".\"ItemId\" = @__itemId_0)"
[2025-02-26 05:51:36.910 +05:30] [INF] [19] Microsoft.EntityFrameworkCore.Database.Command: Executed DbCommand ("0"ms) [Parameters=["@__itemId_0='?' (DbType = Guid)"], CommandType='Text', CommandTimeout='30']"
""SELECT \"t\".\"ItemId\", \"t\".\"Width\", \"t\".\"Bandwidth\", \"t\".\"Height\", \"t\".\"Interval\", \"t\".\"ThumbnailCount\", \"t\".\"TileHeight\", \"t\".\"TileWidth\"
FROM \"TrickplayInfos\" AS \"t\"
WHERE \"t\".\"ItemId\" = @__itemId_0"

These are clearly running every few milliseconds and as I mentioned, matched exactly with the CPU usage spikes. What's odd to me is that when I ran the following tasks, it took very little time to execute:

My Trickplay settings are set to default (shown down below in additional information).

Reproduction steps

Start watching something
Observe CPU usage

What is the current bug behavior?

Extremely high CPU usage for no reason (since there is no transcoding happening).

What is the expected correct behavior?

Normal CPU usage (~10-20%).

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.10.6

Environment

- OS: Void Linux
- Linux Kernel: 6.6.78_1
- Virtualization: None (bare metal)
- Clients: Jellyfin Media Player 1.11.1, Jellyfin MPV Shim 2.8.0, Latest Jellyfin Android Application (as of 27/02/2025)
- Browser: Firefox 135.0.1
- FFmpeg Version: 6.1.2
- Playback Method: Direct
- Hardware Acceleration: None
- GPU Model: None
- Plugins: None and with Playback Reporting 15 and Kodi Sync Queue 14
- Reverse Proxy: nginx
- Base URL: https://media.skaytacium.com
- Networking: Direct Ethernet connection
- Storage: Local HDDs

Jellyfin logs

Posted below in additional files (I've provided debug logs, since the basic logging doesn't provide any useful information at all. I will send those too if required.)

FFmpeg logs

Client / Browser logs

No response

Relevant screenshots or videos

No response

Additional information

Debug logs for the server

Originally created by @Skaytacium on GitHub (Feb 26, 2025). ### Description of the bug I recently noticed extremely high CPU usage by the jellyfin process during playback (paused or resumed) of any content. It looks like the following when playback is paused: ![Image](https://github.com/user-attachments/assets/521e632f-c8b1-495f-937d-637c13924535) and like the following during playback (completely uses up ~200% of CPU (2 cores)): ![Image](https://github.com/user-attachments/assets/4652049a-99b9-4737-90b5-f191d272475a) This happens regardless of the client (tried on jellyfin-media-player, jellyfin mpv shim and the jellyfin android app). This is on direct streaming, since the above pictures are the CPU usage of the jellyfin process and not any ffmpeg processes. Since initially I figured it might be an issue with some of the plugins (namely, Playback Reporting and Kodi Sync Queue), I uninstalled both and checked but the issue still persisted. I have already tried debugging this on the troubleshooting channel on the jellyfin server, but a solution wasn't found. What seemed odd to me was the no. `Executed DbCommand` logs that seemed to match with the exact timing of the CPU usage spiking while paused and were constantly thrown during resumed playback. They were the following repeated over and over: ``` [2025-02-26 05:51:36.907 +05:30] [INF] [19] Microsoft.EntityFrameworkCore.Database.Command: Executed DbCommand ("0"ms) [Parameters=["@__itemId_0='?' (DbType = Guid)"], CommandType='Text', CommandTimeout='30']" ""SELECT EXISTS ( SELECT 1 FROM \"MediaSegments\" AS \"m\" WHERE \"m\".\"ItemId\" = @__itemId_0)" [2025-02-26 05:51:36.909 +05:30] [INF] [19] Microsoft.EntityFrameworkCore.Database.Command: Executed DbCommand ("0"ms) [Parameters=["@__itemId_0='?' (DbType = Guid)"], CommandType='Text', CommandTimeout='30']" ""SELECT EXISTS ( SELECT 1 FROM \"MediaSegments\" AS \"m\" WHERE \"m\".\"ItemId\" = @__itemId_0)" [2025-02-26 05:51:36.910 +05:30] [INF] [19] Microsoft.EntityFrameworkCore.Database.Command: Executed DbCommand ("0"ms) [Parameters=["@__itemId_0='?' (DbType = Guid)"], CommandType='Text', CommandTimeout='30']" ""SELECT \"t\".\"ItemId\", \"t\".\"Width\", \"t\".\"Bandwidth\", \"t\".\"Height\", \"t\".\"Interval\", \"t\".\"ThumbnailCount\", \"t\".\"TileHeight\", \"t\".\"TileWidth\" FROM \"TrickplayInfos\" AS \"t\" WHERE \"t\".\"ItemId\" = @__itemId_0" ``` These are clearly running every few milliseconds and as I mentioned, matched exactly with the CPU usage spikes. What's odd to me is that when I ran the following tasks, it took very little time to execute: ![Image](https://github.com/user-attachments/assets/04dbbe11-7a93-46f8-b820-1159cc511914) ![Image](https://github.com/user-attachments/assets/bb0a19c1-6c03-432f-b599-1d9138a6834b) My Trickplay settings are set to default (shown down below in additional information). ### Reproduction steps 1. Start watching something 2. Observe CPU usage ### What is the current _bug_ behavior? Extremely high CPU usage for no reason (since there is no transcoding happening). ### What is the expected _correct_ behavior? Normal CPU usage (~10-20%). ### 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.10.6 ### Environment ```markdown - OS: Void Linux - Linux Kernel: 6.6.78_1 - Virtualization: None (bare metal) - Clients: Jellyfin Media Player 1.11.1, Jellyfin MPV Shim 2.8.0, Latest Jellyfin Android Application (as of 27/02/2025) - Browser: Firefox 135.0.1 - FFmpeg Version: 6.1.2 - Playback Method: Direct - Hardware Acceleration: None - GPU Model: None - Plugins: None and with Playback Reporting 15 and Kodi Sync Queue 14 - Reverse Proxy: nginx - Base URL: https://media.skaytacium.com - Networking: Direct Ethernet connection - Storage: Local HDDs ``` ### Jellyfin logs ```shell Posted below in additional files (I've provided debug logs, since the basic logging doesn't provide any useful information at all. I will send those too if required.) ``` ### FFmpeg logs ```shell ``` ### Client / Browser logs _No response_ ### Relevant screenshots or videos _No response_ ### Additional information [Debug logs for the server](https://github.com/user-attachments/files/18993689/log_20250226.log) ![Image](https://github.com/user-attachments/assets/8aedc431-c7fa-48f8-9e89-4ffae8d5f541) ![Image](https://github.com/user-attachments/assets/db38fd72-06f5-4b2a-ac16-cacac1cacf61) ![Image](https://github.com/user-attachments/assets/df941848-2192-4a95-afc0-c74a219e7a26)

backuprepo

2025-12-22 04:46:40 +01:00

closed this issue
added the
bug
label

backuprepo commented

2025-12-22 04:46:45 +01:00

Author

Owner

@gnattu commented on GitHub (Feb 26, 2025):

Are you using things like JellyStats which will periodically perform expensive queries to the server?

@gnattu commented on GitHub (Feb 26, 2025): Are you using things like JellyStats which will periodically perform expensive queries to the server?

backuprepo commented

2025-12-22 04:46:47 +01:00

Author

Owner

@Skaytacium commented on GitHub (Feb 26, 2025):

Nope, the only external connections to the server are:

Radarr
Sonarr
Homepage

@Skaytacium commented on GitHub (Feb 26, 2025): Nope, the only external connections to the server are: - Radarr - Sonarr - Homepage

backuprepo commented

2025-12-22 04:46:49 +01:00

Author

Owner

@Skaytacium commented on GitHub (Jun 7, 2025):

So, after roughly 8 hours of debugging it turns out the in the new version (10.10.7), that the issue is with jellyfin-mpv-shim. There's already an issue opened there (jellyfin/jellyfin-mpv-shim#265), in which I'll probably do some more investigation and open a PR.

For future reference and further clarification: After playing around with the source code, I found out that there's being a bunch of GET requests made to the /Users/{UserId}/Items/{ItemId} endpoint. This matches the Jellyfin.Api.Controllers.UserLibraryController.GetItemLegacy endpoint, and causes the GetTrickplayManifests function to run. This then queries the database. This doesn't happen with the web client and jellyfin-media-player anymore, so maybe something changed in the web UI? No clue.

@Skaytacium commented on GitHub (Jun 7, 2025): So, after roughly 8 hours of debugging it turns out the in the new version (10.10.7), that the issue is with `jellyfin-mpv-shim`. There's already an issue opened there (jellyfin/jellyfin-mpv-shim#265), in which I'll probably do some more investigation and open a PR. For future reference and further clarification: After playing around with the source code, I found out that there's being a bunch of GET requests made to the `/Users/{UserId}/Items/{ItemId}` endpoint. This matches the `Jellyfin.Api.Controllers.UserLibraryController.GetItemLegacy` endpoint, and causes the `GetTrickplayManifests` function to run. This then queries the database. This doesn't happen with the web client and jellyfin-media-player anymore, so maybe something changed in the web UI? No clue.

backuprepo commented

2025-12-22 04:46:52 +01:00

Author

Owner

@Skaytacium commented on GitHub (Jun 8, 2025):

This is embarrassing. I've found out what the issue was and it's got nothing to do with jellyfin-mpv-shim. I'll give an explanation here and submit a PR soon. I'll be using the latest release

The function that causes CPU (and disk) load is GetBaseItemDtos:
c2cc27a8a9/Emby.Server.Implementations/Dto/DtoService.cs (L84)

This basically runs an SQL query for every item mentioned in its parameters. Now, this function is called by, obviously, a lot of things. In this context, the culprit is something that is repeated very often and has a very large list of parameters. After some more thorough debugging, it turns out that on every progress update, this function is being called.

The OnPlaybackProgress function calls UpdateNowPlayingItem.
c2cc27a8a9/Emby.Server.Implementations/Session/SessionManager.cs (L870-L886)

This update function can be extremely expensive, depending on whether if there is a queue.
c2cc27a8a9/Emby.Server.Implementations/Session/SessionManager.cs (L385)
c2cc27a8a9/Emby.Server.Implementations/Session/SessionManager.cs (L457-L468)

In my previous comment, the observations correlate entirely with the way this might work. Smaller shows don't cause this issue, movies don't cause this issue and when one is towards the end of the show (remaining queue is small), this issue is not caused. Of course, even with a queue of just 3 episodes, the server load on a weaker machine (such as my Raspberry Pi 5) is significant enough to not only be noticeable, but cause slight slowdown.

jellyfin-mpv-shim is a client that queues the remaining episodes of a show, jellyfin-media-player does not do this, but it used to. This also makes sense why the CPU load is caused even when the show is paused. Direct streaming obviously doesn't cause this issue, since there are no progress updates being posted. This is consistent with all of the observations and has been proven by the following logs (from modified source code):

I'll submit a PR soon enough, since I've been testing this out on the v10.10.7 tag, but the master branch still has the same behavior.

@Skaytacium commented on GitHub (Jun 8, 2025): This is embarrassing. I've found out what the issue was and it's got nothing to do with `jellyfin-mpv-shim`. I'll give an explanation here and submit a PR soon. I'll be using the latest release The function that causes CPU (and disk) load is `GetBaseItemDtos`: https://github.com/jellyfin/jellyfin/blob/c2cc27a8a9dc1555b6ccc5d24671ef3792a05589/Emby.Server.Implementations/Dto/DtoService.cs#L84 This basically runs an SQL query for every item mentioned in its parameters. Now, this function is called by, obviously, a lot of things. In this context, the culprit is something that is repeated very often and has a very large list of parameters. After some more thorough debugging, it turns out that on every progress update, this function is being called. The `OnPlaybackProgress` function calls `UpdateNowPlayingItem`. https://github.com/jellyfin/jellyfin/blob/c2cc27a8a9dc1555b6ccc5d24671ef3792a05589/Emby.Server.Implementations/Session/SessionManager.cs#L870-L886 This update function *can* be extremely expensive, depending on whether if there is a queue. https://github.com/jellyfin/jellyfin/blob/c2cc27a8a9dc1555b6ccc5d24671ef3792a05589/Emby.Server.Implementations/Session/SessionManager.cs#L385 https://github.com/jellyfin/jellyfin/blob/c2cc27a8a9dc1555b6ccc5d24671ef3792a05589/Emby.Server.Implementations/Session/SessionManager.cs#L457-L468 In my previous comment, the observations correlate entirely with the way this might work. Smaller shows don't cause this issue, movies don't cause this issue and when one is towards the end of the show (remaining queue is small), this issue is not caused. Of course, even with a queue of just 3 episodes, the server load on a weaker machine (such as my Raspberry Pi 5) is significant enough to not only be noticeable, but cause slight slowdown. `jellyfin-mpv-shim` is a client that queues the remaining episodes of a show, `jellyfin-media-player` does not do this, but it used to. This also makes sense why the CPU load is caused even when the show is paused. Direct streaming obviously doesn't cause this issue, since there are no progress updates being posted. This is consistent with all of the observations and has been proven by the following logs (from modified source code): ![Image](https://github.com/user-attachments/assets/685f97f5-1834-469e-b530-168c88f70e17) I'll submit a PR soon enough, since I've been testing this out on the v10.10.7 tag, but the master branch still has the same behavior.

backuprepo referenced this issue

2025-12-22 08:25:54 +01:00

[PR #6774] [MERGED] Make sure ReadToDescendant was successful before continuing #10933

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: starred/jellyfin#6773

No description provided.

Rows
Columns