Jellyfin Hotcache & Hardened Jellyfin Docker Images

I’m pleased to announce the release of Jellyfin Hotcache. This is a helper for Jellyfin that I built to address a fairly simple problem: my kids love to watch the same media over and over, but I’d rather they not spin up the NAS drives every time they want to watch the same episode again.

Jellyfin Hotcache identifies frequently and recently played media and stages a copy on a specified cache drive—ideally an SSD or NVMe device. It preserves the original media on the slower storage, renames that copy for safekeeping, and replaces Jellyfin’s original media path with a symlink pointing to the cached copy.

This helps reduce unnecessary spin-ups of the media drives and can improve playback startup and access times for frequently watched content.

https://github.com/thystra/hotcache-for-jellyfin

Version 1.0.3 has now been released, including several reporting and operator-visibility improvements:

https://github.com/thystra/hotcache-for-jellyfin/releases/tag/v1.0.3

Hotcache is packaged for Debian/Ubuntu-compatible Linux systems. It supports Jellyfin playback history stored in both SQLite and PostgreSQL, and works with both bare-metal and containerized Jellyfin installations. Container installations require the cache directory to be mounted into Jellyfin at the same absolute path so that Jellyfin can follow the cache symlinks.

Hardened Jellyfin Docker Images

Along with Hotcache, I’ve also put together some updated and hardened Jellyfin 10.11.11 Docker images.

These images address CVE-2026-8461, an FFmpeg MagicYUV decoder vulnerability that can result in an out-of-bounds write and potentially remote code execution when a malicious media file is processed.

https://nvd.nist.gov/vuln/detail/cve-2026-8461

The hardened Jellyfin 10.11.11 images use a custom Jellyfin FFmpeg 7.1.4 build with the affected MagicYUV decoder disabled. This mitigates CVE-2026-8461 while retaining Jellyfin’s expected hardware-acceleration support.

I’ve also repackaged the Jellyfin PostgreSQL images with separate PostgreSQL 17 and PostgreSQL 18 client-tool variants. Jellyfin’s PostgreSQL backup functionality relies on tools such as pg_dump, and pg_dump cannot back up a PostgreSQL server running a newer major version than the client itself. After I upgraded my database server to PostgreSQL 18, the older client tools in the Jellyfin image could no longer perform the backup.

The resulting images provide explicit PG17 and PG18 variants and are available for both amd64 and arm64:

https://github.com/thystra/jellyfin-security-images

Jellyfin 12.0 and later currently use Jellyfin FFmpeg 8.1.2 or newer, which contains the upstream fix for CVE-2026-8461, so these hardened FFmpeg images are primarily intended for users remaining on Jellyfin 10.11.11.

If you find any of this useful, I appreciate any tips at my Ko-fi!!

https://ko-fi.com/thewolfandtheraven

Wacky Wednesday

2 Sep 2026

We tried a little experiment, well two actually. One was cutting back the feed for the chickens, and two was using the Tractor Supply delivery service.

Cutting the feed back wasn’t that great. It caused a slow down in their eggs, and I’m not sure if it is related or not, but seemed to trigger a molt. Egg production pretty much stopped (writing this a couple weeks in the future..) and took a while to recover.

Tractor Supply also took their time delivering, missing the original promise date and stretched out the delivery over a few days. That was a little annoying as well.

Read more