Quick answer

What this guide helps you do

Jellyfin 12, 12.1 or 12.2 using too much CPU or RAM, scanning forever or transcoding unexpectedly? Check version, scan state, logs, hardware acceleration, migrations and rollback safely.

Jellyfin beginner path

New to Jellyfin? Follow this order.

These guides form the SmallGrid Jellyfin path: install it, fix folder access, solve empty libraries, reduce unnecessary transcoding, then choose the right mini PC.

  1. How to Reduce Jellyfin Server Power Use on Ubuntu
  2. Give Jellyfin Access to Media Folders on Ubuntu
  3. Jellyfin Library Not Showing Files? 8 Checks That Fix It
  4. Jellyfin Direct Play vs Transcoding: What Is the Difference?
  5. Best Mini PC for Jellyfin: CPU, RAM and Quick Sync Specs

Quick answer

If Jellyfin 12 suddenly uses much more CPU or memory after an upgrade, first determine what the server is actually doing before changing settings or restarting it repeatedly.

Start with this order:

check Jellyfin version
→ check whether a library scan or migration is active
→ record CPU and memory use
→ inspect Jellyfin logs
→ verify hardware acceleration is still enabled
→ identify whether playback is transcoding
→ separate a long first scan from a scan that is stuck or looping
→ inspect migration errors before restarting again
→ preserve the backup before attempting rollback

Jellyfin 12.1 was released on 15 September 2026 with 47 server fixes, and Jellyfin 12.2, a minor bug-fix release, followed on 5 October 2026. If you are still on 12.0, take a fresh backup and review the 12.1 release notes before troubleshooting a problem that may already have been fixed in the point release.

Do not assume every Jellyfin 12 server has a memory leak or broken migration. There are confirmed issue reports affecting particular libraries and databases, but they are not evidence of a universal defect.

If your problem is broader than performance or scanning, use Jellyfin 12 Upgrade Problems: What to Check After Updating instead.

1. Check whether you are on Jellyfin 12.0 or 12.1

Open:

Dashboard → General

For Docker:

docker exec jellyfin jellyfin --version
docker inspect jellyfin --format '{{.Config.Image}}'
docker inspect jellyfin --format '{{.Image}}'

For native Ubuntu:

jellyfin --version
apt-cache policy jellyfin jellyfin-server jellyfin-web jellyfin-ffmpeg

Interpret the result:

VersionWhat to do
10.10.7 / 10.11.xUse the Jellyfin 12 preparation guide before upgrading
12.0Back up and review the 12.1 fixes before deeper troubleshooting
12.1Continue with the checks below
12.2Continue with the checks below, and see the Jellyfin 12.2 update guide

Do not combine the 12.0 → 12.1 update with an Ubuntu release upgrade, Docker Engine update, storage move or GPU-driver redesign.

2. Record CPU and memory use before changing anything

For Docker:

docker stats jellyfin

For native Ubuntu:

ps -C jellyfin -o pid,pcpu,pmem,rss,vsz,etime,cmd
free -h

Record:

Jellyfin version:
CPU %:
Memory / RSS:
Uptime:
Library scan active: yes/no
Playback active: yes/no
Transcoding active: yes/no

The trend matters more than one number.

Healthy upgrade work often looks like:

resource use rises
→ scan progresses
→ activity eventually falls

A more suspicious pattern is:

resource use rises continuously
→ scan progress barely changes
→ logs repeat the same operation
→ memory never settles

3. Check whether a library scan is actually running

Jellyfin 12 requires a full library scan after the major upgrade from 10.11.

Open the dashboard and check scheduled-task/activity state.

For Docker, follow logs:

docker logs -f jellyfin

For Ubuntu:

sudo journalctl -u jellyfin -f

If the log is progressing through different files, libraries or tasks, the server may simply be busy.

If the same path, migration or item repeats continuously, capture that exact pattern before restarting.

A long scan is not automatically a failed scan.

4. Distinguish a normal first scan from a runaway scan

The first scan after Jellyfin 12 is intentionally heavier than an ordinary scheduled scan.

Normal signs include:

  • sustained disk reads
  • elevated CPU for a while
  • metadata activity
  • changing item paths in logs
  • scan percentage or task state progressing
  • memory eventually stabilising

Warning signs include:

  • the same item or migration repeated indefinitely
  • memory rising continuously until swap or OOM pressure appears
  • one CPU core pinned for hours while the same migration line remains unchanged
  • the server repeatedly restarting at the same migration step
  • library scans repeatedly splitting or reprocessing the same merged versions

Do not repeatedly restart simply because resource use is high. A restart can make it harder to tell whether work was genuinely progressing.

Jellyfin 12.1 contains 47 server fixes across library, metadata, performance and playback areas.

That makes version checking part of troubleshooting.

If a server is on 12.0:

  1. take a fresh backup
  2. record the current logs and resource behaviour
  3. read the official 12.1 release notes
  4. update Jellyfin only
  5. compare scan progress, CPU and memory after the point update

Do not present 12.1 as a guaranteed cure for every high-memory or long-scan report. It contains relevant fixes, but open issues remain for some configurations.

Jellyfin 12.2 (5 October 2026) is a further minor bug-fix release. Its official notes list database, library-scanning and migration performance fixes. Do not assume it fixes your particular problem: read the release notes and follow the Jellyfin 12.2 update guide before and after updating.

6. Check whether hardware acceleration was disabled or reset

Unexpectedly high CPU during playback can be caused by software transcoding rather than the library scan itself.

Open:

Dashboard → Playback → Transcoding

Confirm the expected hardware acceleration method is still enabled.

For Intel systems this may be QSV or VA-API. NVIDIA systems may use NVENC. AMD systems commonly use VA-API where supported.

For Docker, also confirm the GPU device is still mapped:

docker inspect jellyfin --format '{{json .HostConfig.Devices}}'
docker exec jellyfin ls -la /dev/dri 2>/dev/null

For native Ubuntu:

ls -la /dev/dri 2>/dev/null
getent group render video

Jellyfin 12 ships with Jellyfin FFmpeg 8.1, so also record:

/usr/lib/jellyfin-ffmpeg/ffmpeg -version | head

or in Docker:

docker exec jellyfin /usr/lib/jellyfin-ffmpeg/ffmpeg -version | head

Use Jellyfin Hardware Transcoding on Ubuntu for the full hardware path.

7. Check whether playback is actually transcoding

A high-CPU server may be doing exactly what the client requested.

Open the active session in the Jellyfin dashboard and record:

Playback method:
Video codec:
Audio codec:
Subtitle format:
Transcoding reason:
Client:
Local or remote:

Then compare:

  1. the same file with subtitles off
  2. a known Direct Play file
  3. another maintained client
  4. the same client on the local network

Use How to Check Why Jellyfin Is Transcoding before changing codecs, FFmpeg or GPU drivers.

8. Inspect encoding and transcoding settings after migration

Some Jellyfin 12 upgrade reports describe encoding configuration not loading cleanly and transcoding settings returning to defaults.

That does not prove your server has the same issue.

Check the active configuration in the Jellyfin dashboard first.

Then inspect logs for encoding-related warnings:

Docker

docker logs jellyfin 2>&1 | grep -Ei 'encoding|ffmpeg|transcod|hardware|vaapi|qsv|nvenc'

Ubuntu

sudo journalctl -u jellyfin -b --no-pager | \
  grep -Ei 'encoding|ffmpeg|transcod|hardware|vaapi|qsv|nvenc'

If hardware acceleration is disabled after the upgrade, restore the intended supported setting through the UI and test one known transcode.

Do not copy an old encoding.xml over a running 12.x instance without understanding whether its schema is still compatible.

9. Migration fails or appears stuck

There are confirmed Jellyfin 12 issue reports involving migration failures from conditions such as:

  • SQLite constraint errors
  • malformed database data
  • duplicate item data
  • migration stages that appear not to complete

A current open Jellyfin 12.1 report documents the 20260113203012_ChangeOwnerIdToGuid migration remaining in startup for hours while one CPU core stayed near 100%. In that report the database integrity check passed, but the migration generated extraordinary logical SQLite reads and restarted from the same stage after a clean container restart. That is useful evidence of a specific failure pattern, not proof that every large Jellyfin database will behave this way.

The useful response is evidence collection, not blind database editing.

Capture the logs around the first failure.

Docker

docker logs jellyfin 2>&1 | \
  grep -Ei 'migration|sqlite|constraint|malformed|duplicate|fatal|error'

Ubuntu

sudo journalctl -u jellyfin -b --no-pager | \
  grep -Ei 'migration|sqlite|constraint|malformed|duplicate|fatal|error'

If the service restarts automatically and retries the same migration, stop the restart loop before collecting more evidence.

For systemd:

sudo systemctl stop jellyfin

For Docker Compose:

docker compose stop jellyfin

Do not delete rows from the Jellyfin database because a forum post mentions a similar constraint error. Different migration failures can have different causes.

10. Check database integrity before assuming the migration code is broken

If logs explicitly report a malformed SQLite database, preserve the data directory and backup before doing anything else.

Do not run destructive repair operations against the only copy.

Record:

exact SQLite error:
migration name:
Jellyfin source version:
Jellyfin target version:
database backup date:

A pre-existing database problem can surface during a migration because the upgrade touches rows that normal day-to-day use never reached.

If you have a tested pre-upgrade backup, keep it untouched while investigating.

11. Merged or alternate versions keep changing

Jellyfin 12 changed alternate-version handling, and there have been confirmed reports around manually merged versions being split again during scans in particular configurations.

If your problem is specifically merged versions:

  1. let the initial required Jellyfin 12 scan finish
  2. record one affected movie and its files
  3. record whether versions span one or multiple libraries
  4. check the Jellyfin version
  5. reproduce with one controlled scan
  6. preserve logs before manually merging everything again

Avoid repeatedly re-merging a large library until you know whether the next scan will undo it again.

This is a narrower problem than general media visibility. If files themselves are missing, use Jellyfin Library Not Showing Files.

12. New files do not appear after the upgrade

If the old library is present but new files are not detected, compare one working and one failing item.

Native Ubuntu:

stat -c '%A %U:%G %n' \
  "/mnt/media/tv/Working Show" \
  "/mnt/media/tv/New Show"

sudo -u jellyfin find "/mnt/media/tv/New Show" -maxdepth 3 -type f | head

Docker:

docker exec jellyfin find "/media/tv/New Show" -maxdepth 3 -type f | head

If Jellyfin cannot read the new path, the fault may be permissions or file creation rather than the 12.x scan engine.

Use Jellyfin Not Scanning New Files for the detailed workflow.

13. When to stop instead of restarting again

Stop and preserve the state when:

  • the same migration fails every startup
  • the same database error repeats
  • memory rises until the system begins swapping heavily or killing processes
  • one migration stays unchanged for hours with no evidence of progress
  • the same media items are processed in a clear loop
  • the server cannot remain up long enough to collect useful logs

At that point, another restart is not diagnosis.

Collect:

Jellyfin version
installation method
source version before upgrade
migration name/error
30–60 minutes of relevant logs
CPU/memory measurements
library size
filesystem/database location
plugin list
GPU and transcoding method

Then decide whether to update, repair, restore or report the issue.

14. When to restore the backup

Rollback is appropriate when you have evidence that the upgraded instance cannot be repaired safely within your maintenance window.

The rollback unit is:

previous Jellyfin version
+
matching pre-upgrade data/configuration

Do not start an older Jellyfin build against a database already migrated by Jellyfin 12.

Before restoring:

  • stop Jellyfin
  • preserve the failed 12.x logs
  • confirm the backup predates the migration
  • confirm the previous application version
  • verify the backup is complete
  • restore into the matching old application version

Follow How to Back Up and Restore Jellyfin Before an Upgrade rather than attempting a partial rollback.

Practical decision tree

High CPU or RAM after Jellyfin 12
        ↓
Check version
        ↓
12.0? → back up → review/update to 12.1
        ↓
Is a migration active?
        ├─ yes → follow logs → progressing or repeating?
        └─ no
        ↓
Is a library scan active?
        ├─ yes → measure progress and resource trend
        └─ no
        ↓
Is playback active?
        ├─ yes → check Direct Play vs transcode + hardware acceleration
        └─ no
        ↓
Logs show repeated migration / SQLite / duplicate-item error?
        ├─ yes → stop restart loop, preserve evidence, protect backup
        └─ no → investigate library task, plugins, filesystem and client behaviour

Official and primary sources

Individual GitHub issue reports are useful evidence of specific failures, but they should not be treated as proof that every Jellyfin 12 or 12.1 installation has the same defect.

Recap

High CPU, high memory and long scans after Jellyfin 12 can come from several very different things:

  • expected first-scan work
  • database migration work
  • a migration that is failing or looping
  • a scan that is repeatedly reprocessing items
  • hardware acceleration being disabled or reset
  • software transcoding
  • a configuration-specific Jellyfin 12.x bug

The safest approach is to identify which layer is active before changing anything.

Check the version first, because the 12.1 and 12.2 point releases include dozens of fixes. Then measure resource use, follow scan or migration progress, verify hardware acceleration, inspect the exact logs and preserve the pre-upgrade backup until the server has proved stable.

Jellyfin guide cluster

More Jellyfin fixes and setup guides

These guides link the main Jellyfin setup, permissions, remote access, direct play, and hardware topics together.