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

Too many ffprobe instances on big library scan #7172

New Issue
Closed
opened 2026-02-07 04:39:53 +03:00 by OVERLORD · 1 comment
OVERLORD commented 2026-02-07 04:39:53 +03:00
Owner
Copy Link

Originally created by @Weegley on GitHub (Jul 20, 2025).

This issue respects the following points:

  • This is a bug, not a question or a configuration issue; Please visit our forum or chat rooms first to troubleshoot with volunteers, before creating a report.
  • This issue is not already reported on GitHub (I've searched it).
  • I'm using an up to date version of Jellyfin Server stable, unstable or master; We generally do not support previous older versions. If possible, please update to the latest version before opening an issue.
  • I agree to follow Jellyfin's Code of Conduct.
  • This report addresses only a single issue; If you encounter multiple issues, kindly create separate reports for each one.

Description of the bug

When scanning library with big amount of files Jellyfin launches more than thousand of ffprobe instances + ffmpeg
here is tasklist output:

C:\>tasklist | find /C "ffmpeg"
26

C:\>tasklist | find /C "ffprobe"
1105

Each of them reads files which, especially on external HDD leads to HDD 100% busy and unresponsive

Reproduction steps

Just launch "update metadata" with "find missing metadata"

What is the current bug behavior?

More than thousand ffprobe + some ffmpeg instances:

C:\>tasklist | find /C "ffmpeg"
26
C:\>tasklist | find /C "ffprobe"
1105

Each of them reads files which, especially on external HDD leads to HDD 100% busy and unresponsive and eventually hangs

What is the expected correct behavior?

limit instances to some adequate number

Jellyfin Server version

10.10.0+

Specify the build version

10.10.7

Environment

- OS: Windows 11
- Clients: Browser, Android
- Browser: Firefox
- FFmpeg Version: latest available for Jellyfin
- Jellyfin Data Storage: Local SSD
- Media Storage: External USB HDD

Jellyfin logs

Log is full of errors as below:

[ERR] [18] MediaBrowser.MediaEncoding.Encoder.MediaEncoder: I-frame image extraction failed, will attempt standard way. Input: "file:\"somefile""
MediaBrowser.Common.FfmpegException: ffmpeg image extraction timed out for file:"somefile" after 10000ms

Additional information

External USB HDD just can't sustain such load

Originally created by @Weegley on GitHub (Jul 20, 2025). ### This issue respects the following points: - [x] This is a **bug**, not a question or a configuration issue; Please visit our [forum or chat rooms](https://jellyfin.org/contact/) first to troubleshoot with volunteers, before creating a report. - [x] This issue is **not** already reported on [GitHub](https://github.com/jellyfin/jellyfin/issues?q=is%3Aopen+is%3Aissue) _(I've searched it)_. - [x] I'm using an up to date version of Jellyfin Server stable, unstable or master; We generally do not support previous older versions. If possible, please update to the latest version before opening an issue. - [x] I agree to follow Jellyfin's [Code of Conduct](https://jellyfin.org/docs/general/community-standards.html#code-of-conduct). - [x] This report addresses only a single issue; If you encounter multiple issues, kindly create separate reports for each one. ### Description of the bug When scanning library with big amount of files Jellyfin launches more than thousand of ffprobe instances + ffmpeg here is tasklist output: ``` C:\>tasklist | find /C "ffmpeg" 26 C:\>tasklist | find /C "ffprobe" 1105 ``` Each of them reads files which, especially on external HDD leads to HDD 100% busy and unresponsive ### Reproduction steps Just launch "update metadata" with "find missing metadata" ### What is the current _bug_ behavior? More than thousand ffprobe + some ffmpeg instances: ``` C:\>tasklist | find /C "ffmpeg" 26 C:\>tasklist | find /C "ffprobe" 1105 ``` Each of them reads files which, especially on external HDD leads to HDD 100% busy and unresponsive and eventually hangs ### What is the expected _correct_ behavior? limit instances to some adequate number ### Jellyfin Server version 10.10.0+ ### Specify the build version 10.10.7 ### Environment ```markdown - OS: Windows 11 - Clients: Browser, Android - Browser: Firefox - FFmpeg Version: latest available for Jellyfin - Jellyfin Data Storage: Local SSD - Media Storage: External USB HDD ``` ### Jellyfin logs Log is full of errors as below: ```shell [ERR] [18] MediaBrowser.MediaEncoding.Encoder.MediaEncoder: I-frame image extraction failed, will attempt standard way. Input: "file:\"somefile"" MediaBrowser.Common.FfmpegException: ffmpeg image extraction timed out for file:"somefile" after 10000ms ``` ### Additional information External USB HDD just can't sustain such load
OVERLORD added the bug label 2026-02-07 04:39:53 +03:00
OVERLORD commented 2026-02-07 04:39:57 +03:00
Author
Owner
Copy Link

@crobibero commented on GitHub (Jul 20, 2025):

This is already fixed for 10.11

@crobibero commented on GitHub (Jul 20, 2025): This is already fixed for 10.11
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
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#7172
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?