Jellyfin 12 Upgrade Problems: What to Check After Updating

Quick answer

If Jellyfin 12 starts after the upgrade but something looks wrong, do not immediately restore the backup or start changing several settings.

Update, 9 October 2026: Jellyfin 12.2 was released on 5 October 2026 as a minor bug-fix release. The steps in this guide still apply. For the 12.2 update procedure and troubleshooting, see Jellyfin 12.2 Update Guide: Fix Scanning, Crashes and Docker Problems.

Some post-upgrade behaviour is expected:

• database migrations run during the upgrade
• the first full library scan takes significantly longer than a normal scan
• some media can temporarily look different while Jellyfin checks every item against the files on disk
• third-party plugins built for Jellyfin 10.11 are not compatible unless their authors have released Jellyfin 12 versions
• stale browser assets can make the web interface look broken until you hard refresh or clear the Jellyfin site cache
• very old third-party clients can stop working because legacy API paths and sign-in behaviour were removed

Start by confirming the server is actually running Jellyfin 12.0, migrations have finished, the required library scan is progressing, and the logs do not show a repeating fatal error.

For Docker:

docker exec jellyfin jellyfin --version
docker logs --since 30m jellyfin
docker stats jellyfin

For a native Ubuntu installation:

jellyfin --version
systemctl status jellyfin --no-pager
sudo journalctl -u jellyfin --since "30 minutes ago" --no-pager

If you have not upgraded yet, use Jellyfin 12 Upgrade Guide: 10 Things to Check Before You Update first.

If the main symptom is a migration that appears stuck, sustained high CPU/RAM, a scan that will not settle or unexpected transcoding load, use Jellyfin 12 High CPU, Memory and Scan Problems for the deeper performance workflow.

If the server is already on Jellyfin 12, work through the checks below in order.

---

What is normal after upgrading to Jellyfin 12?

Jellyfin 12.0 is a major release, not a routine patch.

The official release notes warn that the first startup performs database migrations and that the first library scan afterward is deliberately more thorough than before.

That means these symptoms can be normal for a while:

What you see	Can this be expected?	What to do
First startup takes longer	Yes	Watch logs and let migrations finish
First library scan takes much longer	Yes	Leave the server running and monitor progress
Recently added ordering changes	Yes	Allow the first scan to complete
Some alternate versions appear missing temporarily	Yes	Wait for the full scan before diagnosing
Web UI looks visually wrong	Yes	Hard refresh or clear site cache
Third-party plugins disappear or fail	Yes	Remove incompatible plugins and wait for updated builds
Old client will not connect	Possibly	Update the client and check whether it used legacy API paths
Repeating crashes or migration errors	No	Stop making changes and preserve logs
Media path is empty inside Docker	No	Check the mount and permissions
Playback fails after the scan is complete	No	Diagnose codecs, clients and transcoding

The most important distinction is between temporary upgrade work and a persistent failure after that work has completed.

---

1. Confirm the upgrade actually completed

Open:

Dashboard → General

Confirm the server reports version 12.0.

For Docker:

docker exec jellyfin jellyfin --version
docker ps --filter name=jellyfin
docker logs --since 30m jellyfin

For native Ubuntu:

jellyfin --version
systemctl is-active jellyfin
systemctl status jellyfin --no-pager
sudo journalctl -u jellyfin --since "30 minutes ago" --no-pager

Look for a server that reaches a stable running state rather than repeatedly starting, crashing and restarting.

During database migration, avoid repeated manual restarts. Interrupting a migration because the web interface is slow can turn a recoverable wait into a more difficult recovery job.

If the service never reaches a running state, preserve the logs before changing packages, image tags or database files.

---

2. Let database migrations finish

Jellyfin 12 performs database migrations when moving from a supported 10.10.7 or 10.11.x server.

The release notes also provide an explicit migration mode:

--mode MigrateSystem

That is useful for administrators who deliberately want to run the migration separately, but most home servers will encounter the migration during the normal first start.

While migration is running:

• do not repeatedly restart Jellyfin
• do not restore individual database files over the active data directory
• do not start an older Jellyfin version against the migrated database
• do not run a second Jellyfin instance against the same data
• keep the pre-upgrade backup untouched

For Docker, follow the logs:

docker logs -f jellyfin

For Ubuntu:

sudo journalctl -u jellyfin -f

If the migration fails repeatedly, the recovery decision should be based on the error and your backup, not on trial-and-error database edits.

---

3. Expect the first library scan to take much longer

Jellyfin 12 performs a more complete post-upgrade library scan.

The server checks library items against the files on disk and cleans up data left from older versions. The official release notes specifically warn that this first scan will take significantly longer than a normal scan.

So this sequence can be healthy:

Jellyfin 12 starts
→ migrations complete
→ full library scan begins
→ CPU / disk activity increases
→ library ordering or counts change temporarily
→ scan gradually completes
→ activity settles

Monitor rather than restarting.

For Docker:

docker stats jellyfin
docker logs --since 30m jellyfin

For Ubuntu:

top
sudo journalctl -u jellyfin --since "30 minutes ago" --no-pager

A long scan is not by itself evidence that the upgrade failed.

---

4. Media appears missing after the upgrade

Do not assume Jellyfin deleted the files.

First prove whether the files still exist and whether Jellyfin can access them.

Native Ubuntu

findmnt
find /path/to/media -maxdepth 3 -type f | head -20
sudo -u jellyfin find /path/to/media -maxdepth 3 -type f | head -20

Docker

Check the host:

find /srv/media -maxdepth 3 -type f | head -20
findmnt -T /srv/media

Check the active container mapping:

docker inspect jellyfin \
  --format '{{range .Mounts}}{{println .Source "->" .Destination "RW=" .RW}}{{end}}'

Then test inside the container:

docker exec jellyfin find /media -maxdepth 3 -type f | head -20

Use your real host and container paths.

Interpret the result:

Evidence	Likely cause
Files exist on host and inside container	Let the Jellyfin 12 scan complete, then check library settings and logs
Files exist on host but not in container	Docker mount problem
Container returns permission denied	UID/GID, group, ACL or mount permission problem
Host path is empty	Storage mount problem
Only some versions look missing during scan	Allow the post-upgrade scan to complete before repairing metadata

Use Jellyfin Library Not Showing Files for the full decision tree.

---

5. Alternate versions or items look different

Jellyfin 12 changes how it validates and organises some library data.

The release notes warn that automatically grouped alternate versions can temporarily appear missing while the full scan is working through the library.

Do not immediately:

• rename the entire library
• split or merge every version manually
• delete metadata
• remove and recreate the whole library

First let the required post-upgrade scan finish.

After it completes, compare the filesystem with what Jellyfin shows. If files are still absent, use the normal storage, permission, path and naming checks.

---

6. Third-party plugins disappeared or stopped working

Jellyfin explicitly told users to remove third-party plugins before upgrading to 12.0.

Plugins built for 10.11 do not automatically work on 12.0.

Official plugins have been updated, but third-party plugin authors need to release compatible versions independently.

Open:

Dashboard → Plugins → My Plugins

Then:

1. identify every third-party plugin
2. check the plugin author’s repository or documentation for Jellyfin 12 support
3. do not reinstall an old incompatible package just to make the entry return
4. restart Jellyfin only after making one deliberate plugin change
5. check logs after the restart

If Jellyfin becomes stable with third-party plugins absent, treat plugin recovery as a separate task from the server upgrade.

Do not downgrade the whole server purely because one non-essential plugin has not been updated yet.

---

7. The Jellyfin web interface looks broken

After upgrading, stale browser assets can produce incorrect layouts, missing controls or other UI anomalies.

Jellyfin’s official release notes say cached assets are a common cause.

Start with a hard refresh:

Windows / Linux: Ctrl + Shift + R
macOS: Command + Shift + R

If that does not work, clear the stored site data/cache for your Jellyfin address and reload.

Also test:

• a private/incognito browser window
• another maintained browser
• the server locally rather than through a reverse proxy
• the interface without custom CSS

If the clean browser session works, the server migration itself may be healthy.

Do not restore a database backup because one browser still has old web assets cached.

---

8. Custom CSS looks wrong

A major web-client release can invalidate selectors or assumptions used by custom themes and CSS.

In Jellyfin 12, the Modern layout is now the default non-TV layout, and bundled themes now share a CSS-variable base. Custom themes or CSS written against older markup or theme assumptions may therefore need adjustment even when the server itself upgraded correctly.

Temporarily disable custom CSS and reload the interface.

If the stock Jellyfin interface works correctly:

Jellyfin server: healthy
Jellyfin web client: healthy
Custom CSS: needs updating

Treat theme repair as a separate task.

This is especially important when troubleshooting because CSS can hide or reposition controls and make a healthy server look broken.

---

9. Old clients no longer connect

Jellyfin 12 removes some legacy compatibility behaviour.

The official release notes specifically warn that very old third-party clients relying on legacy /emby/ or /mediabrowser/ API paths, or deprecated sign-in behaviour, can stop working.

Before changing the server:

1. update the client
2. confirm the client is still maintained
3. remove and re-add the server connection if appropriate
4. test the official web client
5. test another maintained Jellyfin client

If the official web client works but an old third-party client does not, the server upgrade may be successful.

---

10. Playback broke after Jellyfin 12

Wait until migrations and the first library scan have finished before treating playback as an isolated fault.

Then test one known file that worked before the upgrade.

While it is playing, record:

Client:
Local or remote:
Playback mode:
Video codec:
Audio codec:
Subtitle format:
Conversion reason:

Open the active session in the Jellyfin dashboard.

Then compare:

1. Direct Play with subtitles off
2. the same file with subtitles on
3. another audio track
4. another maintained client
5. one intentional hardware transcode

For Docker, confirm the GPU devices are 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

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

---

11. CPU or memory usage is high

A major upgrade can legitimately create temporary load from:

• database migration
• the required full library scan
• metadata work
• image processing
• playback transcoding

Record whether the load is falling as the scan progresses.

Docker:

docker stats jellyfin
docker logs --since 30m jellyfin

Ubuntu:

ps aux --sort=-%cpu | head -15
free -h
sudo journalctl -u jellyfin --since "30 minutes ago" --no-pager

High resource use becomes more suspicious when:

• the first scan has completed
• no playback is active
• resource use continues climbing rather than settling
• the service is repeatedly killed or restarted
• the logs show recurring failures

Do not assume a community report of high memory use proves your server has the same defect. Capture your own measurements and logs first.

---

12. New files are not appearing

If the existing library is present but newly imported files do not appear, compare one working item with one new 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 the new path fails but existing media works, the problem is more likely to be file creation, ownership, ACL inheritance or automation than the Jellyfin 12 database migration.

Use Jellyfin Not Scanning New Files for the detailed workflow.

---

13. Check logs before changing anything else

Logs tell you which layer is failing.

Docker

docker logs --since 30m jellyfin

Filter likely problems:

docker logs jellyfin 2>&1 | \
  grep -Ei 'error|fail|migration|permission|denied|database|ffmpeg|plugin'

Native Ubuntu

sudo journalctl -u jellyfin --since "30 minutes ago" --no-pager

Filter:

sudo journalctl -u jellyfin --since "30 minutes ago" --no-pager | \
  grep -Ei 'error|fail|migration|permission|denied|database|ffmpeg|plugin'

Capture the exact error before reinstalling packages, changing image tags or deleting cache/database files.

---

14. When should you restore the backup?

Restore is appropriate when you have evidence that the upgraded instance cannot be repaired safely and you need to return to the previous version.

The rollback unit is:

previous Jellyfin application version
+
matching pre-upgrade data and configuration

Do not simply start Jellyfin 10.11 against a database that Jellyfin 12 has migrated.

The official Jellyfin release notes warn that the upgrade rewrites data and that the backup is the route back.

Before restoring:

• stop Jellyfin
• preserve the failed Jellyfin 12 logs
• confirm the backup predates the upgrade
• confirm the previous server version
• verify the backup archive or filesystem copy
• make sure no other Jellyfin instance is using the same data

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

---

Post-upgrade verification checklist

Do not call the upgrade complete until these checks pass:

• Dashboard reports Jellyfin 12.0.
• Database migrations complete without repeating fatal errors.
• The first full library scan completes.
• Library counts look credible after the scan.
• A known film or episode is present.
• A newly added item can be detected.
• The web UI works after a hard refresh.
• Required plugins have Jellyfin 12-compatible builds.
• One known Direct Play file works.
• One required transcode works.
• Hardware acceleration uses the expected device.
• Remote access works through the intended route.
• CPU and memory settle after upgrade work finishes.
• The server survives a controlled restart or reboot.
• The pre-upgrade backup is retained.

---

Official source

• Jellyfin Server 12.2 release notes
• Jellyfin 12.0 release notes

---

Related SmallGrid guides

• Jellyfin 12.2 Update Guide: Fix Scanning, Crashes and Docker Problems
• Jellyfin 12 High CPU, Memory and Scan Problems: What to Check
• Jellyfin 12 Upgrade Guide: 10 Things to Check Before You Update
• How to Back Up and Restore Jellyfin Before an Upgrade
• Jellyfin Troubleshooting Hub
• Jellyfin Library Not Showing Files
• Jellyfin Not Scanning New Files
• Give Jellyfin Access to Media Folders on Ubuntu
• Jellyfin Docker Permissions
• How to Check Why Jellyfin Is Transcoding
• Jellyfin on Ubuntu Hub

---

Recap

After a Jellyfin 12 upgrade, a slow first start, long first library scan, temporary library changes, incompatible third-party plugins and stale browser assets can all look alarming without proving the upgrade failed.

Work in order:

confirm version
→ allow migrations to finish
→ allow the full scan to finish
→ prove media paths and permissions
→ remove incompatible plugins
→ hard refresh the web client
→ test playback
→ inspect resource use and logs
→ restore only when the evidence justifies rollback

The safest response is evidence first, one change at a time, and a preserved pre-upgrade backup until Jellyfin 12 has proved stable on your server.