mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-07-16 05:43:54 +03:00
Trickplay is being killed too soon #6519
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 @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.
@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.
@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:
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.
@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.
@tcely commented on GitHub (Feb 16, 2025):
"Increasing the
ImageExtractionTimeoutMsvalue above 20,000 may be needed for theIdlepriority."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.@ElDavoo commented on GitHub (Feb 16, 2025):
uh cool thanks i didn't know, so ok solved for me xd