starred/jellyfin

Fork 0

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

Trickplay is being killed too soon #6517

New issue

Closed

opened 2025-12-22 04:22:53 +01:00 by backuprepo · 5 comments

backuprepo commented

2025-12-22 04:22:53 +01:00

Owner

Originally created by @tcely on GitHub (Nov 27, 2024).

There should really be a mention on the settings page that when using "Idle" process priority, the interval between images needs to be set higher.

1272bb9a84/MediaBrowser.Model/Configuration/ServerConfiguration.cs (L211-L213)

My logs are full of "Creating trickplay files" followed by "Killing ffmpeg process" because while sometimes there were 7 seconds between images, often enough the system wasn't idle and it took much longer.

I'm trying 30 seconds now, to see if that's a more useful timeout. Maybe the default should just be to wait longer?

1272bb9a84/MediaBrowser.MediaEncoding/Encoder/MediaEncoder.cs (L44-L53)

1272bb9a84/MediaBrowser.MediaEncoding/Encoder/MediaEncoder.cs (L991-L1055)

I had no idea why the logs were not making sense until I searched / browsed GitHub to see what the conditions were for "Trickplay process unresponsive" in the code.

Originally created by @tcely on GitHub (Nov 27, 2024). There should really be a mention on the settings page that when using "Idle" process priority, the interval between images needs to be set higher. https://github.com/jellyfin/jellyfin/blob/1272bb9a8420a92329cdd36898b4b0240018327f/MediaBrowser.Model/Configuration/ServerConfiguration.cs#L211-L213 My logs are full of "Creating trickplay files" followed by "Killing ffmpeg process" because while sometimes there were 7 seconds between images, often enough the system wasn't idle and it took much longer. I'm trying 30 seconds now, to see if that's a more useful timeout. Maybe the default should just be to wait longer? https://github.com/jellyfin/jellyfin/blob/1272bb9a8420a92329cdd36898b4b0240018327f/MediaBrowser.MediaEncoding/Encoder/MediaEncoder.cs#L44-L53 https://github.com/jellyfin/jellyfin/blob/1272bb9a8420a92329cdd36898b4b0240018327f/MediaBrowser.MediaEncoding/Encoder/MediaEncoder.cs#L991-L1055 I had no idea why the logs were not making sense until I searched / browsed GitHub to see what the conditions were for "Trickplay process unresponsive" in the code.

backuprepo

2025-12-22 04:22:53 +01:00

closed this issue
added the
wontfix
label

backuprepo commented

2025-12-22 04:22:56 +01:00

Author

Owner

@gnattu commented on GitHub (Nov 27, 2024):

30 seconds is not a more useful timeout and that is a ridiculously high timeout. If your CPU needs 30 seconds to even extract one single frame you really should not enable this feature because the generation will take years or even lifetime.

@gnattu commented on GitHub (Nov 27, 2024): 30 seconds is not a more useful timeout and that is a ridiculously high timeout. If your CPU needs 30 seconds to even extract one single frame you really should not enable this feature because the generation will take years or even lifetime.

backuprepo commented

2025-12-22 04:22:58 +01:00

Author

Owner

@tcely commented on GitHub (Nov 27, 2024):

As I understand the code, if any image takes longer than 1020 seconds, then the ffmpeg will be killed. It's not as if it's only checking for the first image to appear then leaving the ffmpeg to complete in the idle time.

The idle priority means that when the system is busy for longer than 20 seconds, no idle cycles are assigned to trickplay, then the process is killed.

This is suboptimal behavior, because it wasted all the completed images and if the process were not killed it would have completed as normal when idle cycles became available.

For reference, here is one of my recent successful Trickplay creation tasks with the 30 second timeout active:

[12:18:43] [INF] [73] Jellyfin.Server.Implementations.Trickplay.TrickplayManager: Creating trickplay files at 320 width
[12:21:07] [INF] [78] Jellyfin.Server.Implementations.Trickplay.TrickplayManager: Finished creation of trickplay files

As you can see, when there are idle cycles available it doesn't take years, but extended busy periods do occur. Also, this is a background scheduled task, so I wouldn't actually care if it took more than 30 minutes total.

@tcely commented on GitHub (Nov 27, 2024): As I understand the code, if any image takes longer than ~10~20 seconds, then the ffmpeg will be killed. It's not as if it's only checking for the first image to appear then leaving the ffmpeg to complete in the idle time. The idle priority means that when the system is busy for longer than 20 seconds, no idle cycles are assigned to trickplay, then the process is killed. This is suboptimal behavior, because it wasted all the completed images and if the process were not killed it would have completed as normal when idle cycles became available. For reference, here is one of my recent successful Trickplay creation tasks with the 30 second timeout active: ``` [12:18:43] [INF] [73] Jellyfin.Server.Implementations.Trickplay.TrickplayManager: Creating trickplay files at 320 width [12:21:07] [INF] [78] Jellyfin.Server.Implementations.Trickplay.TrickplayManager: Finished creation of trickplay files ``` As you can see, when there are idle cycles available it doesn't take years, but extended busy periods do occur. Also, this is a background scheduled task, so I wouldn't actually care if it took more than 30 minutes total.

backuprepo commented

2025-12-22 04:23:00 +01:00

Author

Owner

@ElDavoo commented on GitHub (Feb 15, 2025):

About 1/4th of my trickplays failed because of this. Sometimes the network can be slow, and/or the CPU is busy doing other stuff. I'd at least make it tunable somehow.

@ElDavoo commented on GitHub (Feb 15, 2025): About 1/4th of my trickplays failed because of this. Sometimes the network can be slow, and/or the CPU is busy doing other stuff. I'd at least make it tunable somehow.

backuprepo commented

2025-12-22 04:23:02 +01:00

Author

Owner

@tcely commented on GitHub (Feb 15, 2025):

I'd at least make it tunable somehow.

"Increasing the ImageExtractionTimeoutMs value above 20,000 may be needed for the Idle priority."

There is already a tunable setting for this (in system.xml), but there is no way to adjust it from the web interface, that I am aware of.

@tcely commented on GitHub (Feb 15, 2025): > I'd at least make it tunable somehow. "Increasing the `ImageExtractionTimeoutMs` value above 20,000 may be needed for the `Idle` priority." There is already a tunable setting for this (in `system.xml`), but there is no way to adjust it from the web interface, that I am aware of.

backuprepo commented

2025-12-22 04:23:04 +01:00

Author

Owner

@ElDavoo commented on GitHub (Feb 16, 2025):

There is already a tunable setting for this (in system.xml),

uh cool thanks i didn't know, so ok solved for me xd

@ElDavoo commented on GitHub (Feb 16, 2025): > There is already a tunable setting for this (in `system.xml`), uh cool thanks i didn't know, so ok solved for me xd

backuprepo referenced this issue

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

[PR #6517] [MERGED] Bump prometheus-net.DotNetRuntime from 4.2.0 to 4.2.1 #10825

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#6517

No description provided.

Rows
Columns