[Issue]: Server spawns many ffmpeg/ffprobe processes no matter the settings, exhausting IO, RAM and CPU #6312

New Issue

OVERLORD · 2026-02-07T03:26:19+03:00

OVERLORD commented

2026-02-07 03:26:19 +03:00

Originally created by @detly on GitHub (Sep 28, 2024).

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. The links can be found here.
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

I'm using Jellyfin 10.9.11 on a Raspberry Pi 2B+ running Raspbian 12. It's installed from the apt repo at https://repo.jellyfin.org/debian, not running in Docker.

I am aware that running Jellyfin on an RPi is not supported, but:

this issue does not seem like it depends on the platform
you probably don't want it to happen on a higher spec machine either
it was running absolutely fine on 10.8.13 or lower for years before this
I don't have another (supported) machine to try to repro this on
if you have suggestions for how I could debug this I'm happy to try them

Shortly after starting, Jellyfin appears to launch ffmpeg processes with no limit on number. This completely maxes out memory, CPU and IO to the point where the service is killed by eg. systemd, or the device itself needs to be hard power cycled.

So far I have:

set ParallelImageEncodingLimit to 1 in /etc/jellyfin/system.xml
set LibraryMetadataRefreshConcurrency to 1 in /etc/jellyfin/system.xml
set LibraryScanFanoutConcurrency to 1 in /etc/jellyfin/system.xml
set EncodingThreadCount to 1 in /etc/jellyfin/encoding.xml
set JELLYFIN_FFmpeg__analyzeduration="100M" in /etc/default/jellyfin
set JELLYFIN_FFmpeg__probesize="50M" in /etc/default/jellyfin

No matter what these are set to, Jellyfin will continue to spawn ffmpeg processes until the system is overwhelmed. Substantially reducing the ffmpeg parameters only means that more individual processes can be spawned before the whole lot (and Jellyfin) are killed. For eg. with the defaults, maybe around 10 processes can be spawned. Turning the limits down as far as they can go means almost a thousand can be spawned before being killed.

It is hard to get logs or other debugging information for this, because once the system is overwhelmed I cannot do much of anything to capture it. At times I've been able to use tmux and other tricks to capture things, but even that's hard because I often have to power cycle the thing to recover and it all goes away. (Hence, I apologise for the screenshots instead of text, but it's the best I can get for now.)

It is not one particular piece of media that seems to cause this; the logs show different files being processed over the many different runs I did.

Possibly related (or at least, similar?) issues:

Reproduction steps

I only have to enable/unmask/start the Jellyfin server systemd unit and this happens within 3 minutes.

What is the current bug behavior?

Many ffmpeg processes are spawned until the system is overwhelmed.

What is the expected correct behavior?

The number of ffmpeg processes and the resources they use are governed by configuration settings.

Jellyfin Server version

10.9.11+

Specify commit id

No response

Specify unstable release number

No response

Specify version number

No response

Specify the build version

n/a

Environment

- OS: Raspbian 12
- Linux Kernel: 6.1.21-v7+
- Virtualization: n/a
- Clients: n/a
- Browser: n/a
- FFmpeg Version: 6.0.1-Jellyfin
- Playback Method: n/a
- Hardware Acceleration: none
- GPU Model: none
- Plugins: TheTVDB, TMDb, Studio Images, OMDb, MusicBrainz, AudioDB
- Reverse Proxy: none
- Base URL: none
- Networking: host
- Storage: USB 2.0 connected spinning disk

Jellyfin logs

I cannot access the dashboard, and logging cuts out due to the system being overwhelmed. See screenshots in issue detail.

FFmpeg logs

No response

Client / Browser logs

No response

Relevant screenshots or videos

Screenshots (from earlier versions but confirmed behaviour is the same in recent versions):

journald logs for first couple of minutes of startup showing env vars and other parameters (from Jul 06 20:16:11)
journald logs shortly after startup when the ffmpeg processes started getting out of hand
htop showing a bunch of ffmpeg processes (this was the last it could refresh before the system became unresponsive)

Additional information

I don't know how to get the "build version" since I can't run the server for long enough to let the client connect and read it from the dashboard. Please let me know if there's another way to get it if you need it.

Originally created by @detly on GitHub (Sep 28, 2024). ### 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 first to troubleshoot with volunteers, before creating a report. The links can be found [here](https://jellyfin.org/contact/). - [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 I'm using Jellyfin 10.9.11 on a Raspberry Pi 2B+ running Raspbian 12. It's installed from the apt repo at `https://repo.jellyfin.org/debian`, not running in Docker. I am aware that running Jellyfin on an RPi is not supported, but: 1. this issue does not _seem_ like it depends on the platform 2. you probably don't want it to happen on a higher spec machine either 3. it was running absolutely fine on 10.8.13 or lower for _years_ before this 4. I don't have another (supported) machine to try to repro this on 5. if you have suggestions for how I could debug this I'm happy to try them Shortly after starting, Jellyfin appears to launch `ffmpeg` processes with no limit on number. This completely maxes out memory, CPU and IO to the point where the service is killed by eg. systemd, or the device itself needs to be hard power cycled. So far I have: - set `ParallelImageEncodingLimit` to `1` in `/etc/jellyfin/system.xml` - set `LibraryMetadataRefreshConcurrency` to `1` in `/etc/jellyfin/system.xml` - set `LibraryScanFanoutConcurrency` to `1` in `/etc/jellyfin/system.xml` - set `EncodingThreadCount` to `1` in `/etc/jellyfin/encoding.xml` - set `JELLYFIN_FFmpeg__analyzeduration="100M"` in `/etc/default/jellyfin` - set `JELLYFIN_FFmpeg__probesize="50M"` in `/etc/default/jellyfin` No matter what these are set to, Jellyfin will continue to spawn `ffmpeg` processes until the system is overwhelmed. Substantially reducing the `ffmpeg` parameters only means that more individual processes can be spawned before the whole lot (and Jellyfin) are killed. For eg. with the defaults, maybe around 10 processes can be spawned. Turning the limits down as far as they can go means almost a thousand can be spawned before being killed. It is hard to get logs or other debugging information for this, because once the system is overwhelmed I cannot do much of anything to capture it. At times I've been able to use tmux and other tricks to capture things, but even that's hard because I often have to power cycle the thing to recover and it all goes away. (Hence, I apologise for the screenshots instead of text, but it's the best I can get for now.) It is not one particular piece of media that seems to cause this; the logs show different files being processed over the many different runs I did. _Possibly_ related (or at least, similar?) issues: - #11588 - #12203 - #1713 - #3930 - #12116 - #9399 ### Reproduction steps I only have to enable/unmask/start the Jellyfin server systemd unit and this happens within 3 minutes. ### What is the current _bug_ behavior? Many `ffmpeg` processes are spawned until the system is overwhelmed. ### What is the expected _correct_ behavior? The number of `ffmpeg` processes and the resources they use are governed by configuration settings. ### Jellyfin Server version 10.9.11+ ### Specify commit id _No response_ ### Specify unstable release number _No response_ ### Specify version number _No response_ ### Specify the build version n/a ### Environment ```markdown - OS: Raspbian 12 - Linux Kernel: 6.1.21-v7+ - Virtualization: n/a - Clients: n/a - Browser: n/a - FFmpeg Version: 6.0.1-Jellyfin - Playback Method: n/a - Hardware Acceleration: none - GPU Model: none - Plugins: TheTVDB, TMDb, Studio Images, OMDb, MusicBrainz, AudioDB - Reverse Proxy: none - Base URL: none - Networking: host - Storage: USB 2.0 connected spinning disk ``` ### Jellyfin logs ```shell I cannot access the dashboard, and logging cuts out due to the system being overwhelmed. See screenshots in issue detail. ``` ### FFmpeg logs _No response_ ### Client / Browser logs _No response_ ### Relevant screenshots or videos Screenshots (from earlier versions but confirmed behaviour is the same in recent versions): - journald logs for first couple of minutes of startup showing env vars and other parameters (from `Jul 06 20:16:11`) ![journald logs for first couple of minutes of startup](https://github.com/user-attachments/assets/34ab643d-8b26-4d02-80ad-5c14cd2454dd) - journald logs shortly after startup when the `ffmpeg` processes started getting out of hand ![journald logs shortly after startup](https://github.com/user-attachments/assets/57a31627-1022-4297-b03b-5a00cecbadc1) - htop showing a bunch of `ffmpeg` processes (this was the last it could refresh before the system became unresponsive) ![htop showing a bunch of `ffmpeg` processes](https://github.com/user-attachments/assets/351583ad-6452-449b-851f-f775a3465d38) ### Additional information I don't know how to get the "build version" since I can't run the server for long enough to let the client connect and read it from the dashboard. Please let me know if there's another way to get it if you need it.

OVERLORD added the wontfix invalid labels 2026-02-07 03:26:19 +03:00

OVERLORD closed this issue

2026-02-07 03:26:20 +03:00

OVERLORD commented

2026-02-07 03:26:23 +03:00

@gnattu commented on GitHub (Sep 28, 2024):

It is doing image extraction and initial library scanning so this is kind of normal operation, it is probably just your Pi2 being too slow so that the image extraction process took (much) longer than expected and the image extraction process does not block the metadata update by design now. This is workaround-able by pooling the image extractor like the skia encoder but for your use case we can do very little because a processor that does not even support 64bit is really not something we will test on and the support for such processor is going to be removed in any time in the future.

@gnattu commented on GitHub (Sep 28, 2024): It is doing image extraction and initial library scanning so this is kind of normal operation, it is probably just your Pi2 being too slow so that the image extraction process took (much) longer than expected and the image extraction process does not block the metadata update by design now. This *is* workaround-able by pooling the image extractor like the skia encoder but for your use case we can do very little because a processor that does not even support 64bit is really not something we will test on and the support for such processor is going to be removed in any time in the future.

OVERLORD commented

2026-02-07 03:26:24 +03:00

@felix920506 commented on GitHub (Sep 28, 2024):

The only thing you could do would be to lower the Parallel library scan tasks limit setting in the dashboard.
In the info you provided, Jellyfin is working as intended, and your performance issues stem from running Jellyfin on inadequate hardware.
Please refer to our hardware selection guide for more info. https://jellyfin.org/docs/general/administration/hardware-selection

@felix920506 commented on GitHub (Sep 28, 2024): The only thing you *could* do would be to lower the `Parallel library scan tasks limit` setting in the dashboard. In the info you provided, Jellyfin is working as intended, and your performance issues stem from running Jellyfin on inadequate hardware. Please refer to our hardware selection guide for more info. https://jellyfin.org/docs/general/administration/hardware-selection

OVERLORD commented

2026-02-07 03:26:27 +03:00

@detly commented on GitHub (Sep 28, 2024):

The only thing you could do would be to lower the Parallel library scan tasks limit setting in the dashboard.

It's not possible to change settings via the dashboard. The dashboard can't connect to a non-responsive server. Do you know where is this setting stored in the server configuration files?

the image extraction process does not block the metadata update by design now

Do you know roughly when this changed? I'm just trying to reconcile this with the fact that I've been running Jellyfin on this device since 2021 with zero issues, performance or otherwise, until June, when it started trying to spawn 900+ subprocesses simultaneously for image/metadata extraction. I'm skeptical that burning resources on new hardware will help in the face of that.

@detly commented on GitHub (Sep 28, 2024): > The only thing you could do would be to lower the Parallel library scan tasks limit setting in the dashboard. It's not possible to change settings via the dashboard. The dashboard can't connect to a non-responsive server. Do you know where is this setting stored in the server configuration files? > the image extraction process does not block the metadata update by design now Do you know roughly when this changed? I'm just trying to reconcile this with the fact that I've been running Jellyfin on this device since 2021 with zero issues, performance or otherwise, until June, when it started trying to spawn 900+ subprocesses simultaneously for image/metadata extraction. I'm skeptical that burning resources on new hardware will help in the face of that.

OVERLORD commented

2026-02-07 03:26:29 +03:00

@detly commented on GitHub (Sep 29, 2024):

@gnattu kindly explained the details of this to me on Matrix, so I'll make notes here in case others encounter this or so devs can refer to it elsewhere.

on 10.8 and prior, Jellyfin did not do much in parallel; it does now
the metadata scanner itself uses a semaphore/pool, but the image extractor is run asynchronously from that
on supported systems, those things complete quickly enough that there's no issue
on a low performance system, the image extractor may still be in progress when an individual metadata scan task completes, hence they can "stack up" even if the metadata scan task pool is limited

It's possible that the specifics of which kinds of tasks/pools/etc. are involved are a bit inaccurate; the point is that yes, it can be explained by the limitations of the platform. (To be clear, I am 100% for the devs limiting the scope of what they support. I just saw this and my first instinct was that it was unexpected and unrelated to hardware.)

@detly commented on GitHub (Sep 29, 2024): @gnattu kindly explained the details of this to me on Matrix, so I'll make notes here in case others encounter this or so devs can refer to it elsewhere. - on 10.8 and prior, Jellyfin did not do much in parallel; it does now - the metadata scanner itself uses a semaphore/pool, but the image extractor is run asynchronously from that - on supported systems, those things complete quickly enough that there's no issue - on a low performance system, the image extractor may still be in progress when an individual metadata scan task completes, hence they can "stack up" even if the metadata scan task pool is limited It's possible that the specifics of which kinds of tasks/pools/etc. are involved are a bit inaccurate; the point is that yes, it can be explained by the limitations of the platform. (To be clear, I am 100% for the devs limiting the scope of what they support. I just saw this and my first instinct was that it was unexpected and unrelated to hardware.)

OVERLORD commented

2026-02-07 03:26:31 +03:00

@gnattu commented on GitHub (Sep 29, 2024):

Well this is not entirely correct because the image extractor is pooled internally as well, but I don't really know why it is not working on your system

@gnattu commented on GitHub (Sep 29, 2024): Well this is not entirely correct because the image extractor is pooled internally as well, but I don't really know why it is not working on your system

OVERLORD commented

2026-02-07 03:26:32 +03:00

@Crrispy commented on GitHub (May 14, 2025):

Hello,

I have the same issue on a QNAP TS-431P. I just want to use it as a local DLNA server, no transcode, nothing fancy. It launches several processes to scan the library, and since I'm on rotational 8TB disks (plus the cpu and ram are very modest), it puts down the nas to a crawl, basically anything above 1 program doing random access on the drives is a mess. I let it run all night and killed it this morning. I'm going to try some of the hints there, but it seems they don't really work?

@Crrispy commented on GitHub (May 14, 2025): Hello, I have the same issue on a QNAP TS-431P. I just want to use it as a local DLNA server, no transcode, nothing fancy. It launches several processes to scan the library, and since I'm on rotational 8TB disks (plus the cpu and ram are very modest), it puts down the nas to a crawl, basically anything above 1 program doing random access on the drives is a mess. I let it run all night and killed it this morning. I'm going to try some of the hints there, but it seems they don't really work?

OVERLORD commented

2026-02-07 03:26:34 +03:00

@lawleagle commented on GitHub (Oct 14, 2025):

I have the same issue, on 10.10.6, on FreeBSD with 96GB of RAM, around 15 of which are usually free. jellyfin spawns hundreds/thousands of ffprobe processes to scan a ~30TB library. honestly, I don't think running 1000 processes in parallel makes any of those processes go fast at all, and the settings in dashboard->general are not honored. already set "Parallel library scan tasks limit" to 8

@lawleagle commented on GitHub (Oct 14, 2025): I have the same issue, on 10.10.6, on FreeBSD with 96GB of RAM, around 15 of which are usually free. jellyfin spawns hundreds/thousands of ffprobe processes to scan a ~30TB library. honestly, I don't think running 1000 processes in parallel makes any of those processes go fast at all, and the settings in dashboard->general are not honored. already set "Parallel library scan tasks limit" to 8

Sign in to join this conversation.

Branches Tags

master

renovate/major-skiasharp-monorepo

renovate/sharpcompress-0.x

renovate/svg.skia-5.x

renovate/ghcr.io-devcontainers-features-docker-in-docker-4.x

release-10.11.z

standards-fix

release-10.9.z

openapi-cache

release-10.10.z

explicit-load

explicit-load-v2

feature/entity-framework

only-count-folder-item

fix/ci-workflow-refactor

release-10.8.z

release-10.7.z

EraYaN-add-management-interface

release-10.6.z

release-10.5.z

release-10.4.z

release-10.3.z

release-10.2.z

release-10.1.0

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/jellyfin#6312