ARRFLIX/docs/22-jellyfin-runtime-perf-audit.md

22 — Jellyfin Runtime Performance Audit (server scope)

Status: read-only audit, executed 2026-05-08 ~17:30–17:45 BST against https://arrflix.s8n.ru (Jellyfin 10.10.3 on nullstone, container jellyfin). Scope: server runtime — CPU, RAM, container limits, FFmpeg, scheduled tasks, plugins. Network/edge, storage, color/HDR are out of scope (sibling agents). Supplements doc 13 (2026-05-08, host-capacity scan); does not repeat findings already in 13 unless the data has materially changed. No fixes applied. No state mutated. No container restart.

---

1. Executive summary — top 3 perf culprits

#	Culprit	Severity	Evidence (one line)
1	4 concurrent ffmpeg processes for ONE viewer, each upscaling 1080p → 2160p with PGS subtitle burn-in, no throttling, no segment deletion	CRITICAL	ps: PIDs 1681949 (643 % CPU), 1685275 (135 %), 1685316 (133 %), 1685478 (132 %) — all transcoding Rick and Morty S01E01.mkv, all -vf scale=3840:2160 + [0:4]overlay subtitle burn. Container CPU 690–876 % across 3 samples
2	Forgejo BlueBuild CI container running uncapped on the same 12-core host (noisy neighbor)	HIGH	docker stats: FORGEJO-ACTIONS-TASK-202_..._Build-push-OCI 88–99 % CPU, 4.3 GiB RAM, 5 GB net-in. Both jellyfin and the build container have Memory=0 NanoCpus=0 CpuQuota=0 (no limits). Aggregate load 15.43 / 14.61 / 8.85 on 12 cores
3	GPU acceleration still off (already in doc 13 finding 02; quantified here) — every CPU transcode spawns one ffmpeg burning 6–8 cores per stream because of the 4K-upscale + sub-overlay filtergraph	HIGH	HardwareAccelerationType=none. Per-ffmpeg cost on this filtergraph: ~6.4 cores at preset=veryfast. 2 viewers transcoding = full host pegged

Biggest quick-win: turn on transcode throttling + segment deletion (doc 13 finding 03 already flags this; new evidence here makes it non-optional). The 4-stream pile-up in §3 is exactly what those two flags exist to prevent — without them, every client seek/reload spawns a fresh ffmpeg and the previous one keeps burning a core for up to 720 s (SegmentKeepSeconds=720). Two checkbox flips in Playback settings.

---

2. Resource snapshot (3 samples, 10 s apart)

Sample @time	jellyfin CPU%	jellyfin MEM	NET I/O	BLOCK I/O	PIDs
t=0	834.3 %	2.635 GiB / 31.27 GiB (8.42 %)	5.36 / 158 MB	1.14 / 855 MB	101
t=10s	690.5 %	2.637 GiB	5.37 / 158 MB	1.22 / 894 MB	102
t=20s	876.7 %	2.646 GiB	5.37 / 158 MB	1.32 / 942 MB	101

Container limits: Memory=0 NanoCpus=0 CpuQuota=0 CpuPeriod=0 PidsLimit=<none> RestartPolicy=unless-stopped. No CPU or RAM cap on the jellyfin container. Same for the Forgejo build container.

Host (nullstone, 12-core AMD Ryzen 5 2600X, 32 GiB RAM, 24 GiB swap):

• uptime: load avg 15.43 / 14.61 / 8.85 — 1-min load 28 % above core count. 5-min trend confirms sustained load. Doc 13 logged 11.40 / 9.59 / 6.19 ~13 h ago, so the host has been getting worse, not better.
• free -h: 31 GiB total, 10 GiB used, 8.2 GiB free, 13 GiB buff/cache; swap 7.8 GiB / 24 GiB used (32 %). SwapCached=771 MB (kernel is actively servicing swap-in from cache — i.e. swap-thrash signature).
• vmstat 1 5: r=3–27, cs=30 K–41 K/s (very high context switch rate), si≤24 KB/s so≈0 (paging-in but not out — recovering, not thrashing right this second), us=70–72 % sy=10–13 % id=16–18 % wa=0 %.
• iostat -x: nvme0n1 w/s ≈ 38–433, wkB/s ≈ 364–2 272, util 0.4 %– 0.9 %. Disk is not the bottleneck — CPU is.

All-container CPU% (sorted, top 5):

Container	CPU%	MEM	Notes
jellyfin	773–876	2.6 GiB	this audit's target
FORGEJO-ACTIONS-TASK-202_..._Build-push-OCI	88–99	4.3 GiB	uncapped CI build, see §3 culprit 2
traefik	9	48 MiB	routine reverse proxy
forgejo	9	207 MiB	git web
minecraft-mc	7	4 GiB	racked.ru server
(28 other containers)	< 5 % combined		none material

The two CPU monsters together (jellyfin + bluebuild) account for ~90 % of the 12-core host's user time during this audit window.

---

3. Active sessions + active transcodes

Sessions (within last 600 s): 1

User	Client	Device	RemoteIP	NowPlaying	PlayMethod	Pos
s8n	Jellyfin Web	Chrome	192.168.0.10	Rick and Morty S01E01 — Pilot	DirectPlay (claimed) / Transcoding (actual)	8 s

TranscodingInfo on the active session:

VideoCodec  → h264 (libx264, preset=veryfast, crf=23)
AudioCodec  → aac (libfdk_aac, 256 kbps stereo, +6 dB volume gain)
Resolution  → 3840 × 2160 (UPSCALE — source is 1080p)
Bitrate     → 13.8 Mbps
Container   → fmp4 / hls
HW          → none
Reasons     → VideoCodecNotSupported, AudioCodecNotSupported, SubtitleCodecNotSupported
Direct      → IsVideoDirect=False, IsAudioDirect=False
Completion  → 0 % (just started)

Active ffmpeg processes on host: 4 (all for the same viewer, same file — see §5).

The session reports PlayMethod=DirectPlay while also presenting a TranscodingInfo block — Jellyfin's TS DTO returns the last-set state, so this is the client navigating into the page; the actual decision was transcode (the 4 ffmpeg's confirm). The HLS player sometimes flips PlayMethod=Transcode only after the first segment downloads; pre-roll state matches the 4-process pile-up in §5.

---

4. Scheduled tasks

All tasks Idle. None in progress. Last-run durations are tiny — no scheduled task is the culprit. Library scan runs every 6 h (last 14:14:04, 0.3 s wall — only 187 items so it converges instantly).

Name	State	Last end (UTC+1)	Last duration	Trigger
Audio Normalization	Idle	2026-05-08T00:58	0.0 s	IntervalTrigger
Clean Cache Directory	Idle	2026-05-08T00:58	0.1 s	IntervalTrigger
Clean Log Directory	Idle	2026-05-08T00:58	0.0 s	IntervalTrigger
Clean Transcode Directory	Idle	2026-05-08T16:22	0.0 s	StartupTrigger
Clean up collections and playlists	Idle	2026-05-08T16:22	0.0 s	StartupTrigger
Download missing lyrics	Idle	2026-05-08T00:58	0.1 s	IntervalTrigger
Download missing subtitles	Idle	2026-05-08T00:58	0.0 s	IntervalTrigger
Extract Chapter Images	Idle	2026-05-08T01:00	0.0 s	DailyTrigger
Generate Trickplay Images	Idle	2026-05-08T02:00	0.1 s	DailyTrigger
Media Segment Scan	Idle	2026-05-08T14:14	0.0 s	IntervalTrigger
Optimize database	Idle	2026-05-08T00:58	0.2 s	IntervalTrigger
Refresh Guide	Idle	2026-05-08T00:58	3.2 s	IntervalTrigger
Refresh People	Idle	2026-05-08T00:58	0.3 s	IntervalTrigger
Scan Media Library	Idle	2026-05-08T14:14	0.3 s	IntervalTrigger
TasksRefreshChannels	Idle	2026-05-08T00:58	0.1 s	IntervalTrigger
Update Plugins	Idle	2026-05-08T16:22	1.2 s	StartupTrigger
Clean Activity Log / Keyframe Extractor / Migrate Trickplay Image Location	Idle	(never run)	—	—

Container restarted at 16:22:06 today (StartupTrigger task end-times imply a restart — last audit had StartedAt=02:13:01, doc 13 finding 30 expected 0 restarts). Operator likely restarted the container ~17 h ago, not material to perf but worth noting.

Verdict: culprit (a) "scheduled task hogging CPU" → ruled out.

---

5. FFmpeg processes on host (snapshot)

4 simultaneous ffmpeg processes, all transcoding the same source for the same viewer. This is the smoking gun. Process tree from the container shows just 1 jellyfin (parent) + 1579 ffmpeg + 1725 ffmpeg (the others are still spawning); host ps -ef shows 4 ffmpeg's owned by user uid 1000.

PID	%CPU	%MEM	RSS	etime	What	Subs filter
1681949	643	6.9	2.27 GB	53 s	-ss 33s HLS seek	yes — [0:4]scale,scale=3840:2160:fast_bilinear[sub] ; [0:0]scale=3840:2160 [main] ; overlay
1685275	135	4.4	1.45 GB	6 s	-ss 15s HLS seek	yes — same chain
1685316	133	4.4	1.45 GB	6 s	full transcode (no -ss)	no — plain setparams + scale + format=yuv420p
1685478	132	3.9	1.29 GB	4 s	full transcode -canvas_size 1920x1080	yes — same chain
1669243 (earlier sample, then died)	~759	7.0	2.30 GB	254 s	full transcode	no

What every ffmpeg is doing:

• Decoding source 1080p H.265 (or H.264 — Pilot is x264 Bluray rip).
• Upscaling video to 3840×2160 with scale=...:fast_bilinear.
• Burning PGS subtitle stream 0:4 ALSO upscaled to 3840×2160 onto the video. This is the heaviest overlay path the JF filtergraph produces.
• Re-encoding to H.264 libx264 preset=veryfast crf=23 high@L5.1 with maxrate=13.5 Mbps.
• -threads 0 (= use all cores), -max_muxing_queue_size 2048.
• HLS fmp4 segments to /cache/transcodes/<sessionId><n>.mp4.

Why 4 of them at once for one user: every time the client seeks or reloads, JF starts a new ffmpeg with a new sessionId and a new segment file prefix. Because EnableThrottling=false and EnableSegmentDeletion=false (doc 13 findings 03/05), the old ffmpeg keeps producing segments to its own cache prefix and does not exit until SegmentKeepSeconds=720 elapses. Three observed cache prefixes right now: 8e8a8538…, ef1caecc… (already produced segments 0–30 → ~73 MiB), 3ba3fce4…, b6f150cb…, fcc6137e… — five session-IDs across the last ~5 minutes for one viewer.

Why each ffmpeg is so expensive:

• 1080p → 4K upscale ≈ 4× pixel volume.
• PGS subtitle stream is also being scaled to 4K and overlaid (alpha blend) every frame.
• libfdk_aac 256 kbps is fine, the cost is essentially all video.
• On 12 logical cores at preset=veryfast, this filtergraph clocks 6.4 cores of headroom per ffmpeg (643 % observed). Two simultaneous transcodes = full host. Four = swap thrash + the load avg of 15.

Why is it upscaling to 4K at all? Likely the client requested a profile that picked the "max bitrate / max-resolution" capability of the device (a desktop Chrome will report 4K-capable). The Jellyfin ladder is either (a) "always pick highest profile" or (b) the user's client is set to "Auto" with no max-resolution cap. No client-side bitrate cap is set on this user (doc 13 reported RemoteClientBitrateLimit=0). Combine that with PGS subs the client can't render → forced burn-in → the 4K-overlay tax kicks in.

ffprobe storms: at 13:31 the log shows 7 simultaneous ffprobe calls (Mandalorian S2 episodes, all at once); at 17:37 another 7 simultaneous ffprobes (Mandalorian S3). Each ffprobe with -analyzeduration 200M -probesize 1G reads up to 1 GiB into RAM. Cause: operator clicked into the season 2/3 page → JF kicks subtitle-search for every episode at once because LibraryMetadataRefreshConcurrency=0 (= 12). Doc 13 finding 14 already calls the concurrency-cap fix; this audit confirms the symptom.

Verdict: the single biggest user-visible "loads kinda slow" is the 4K-upscale subtitle-burn pile-up.

---

6. Plugin status

All 6 plugins Active. None in Faulted/Restart. No exception loops in log from plugin assemblies.

Name	Version	Status
AudioDB	10.10.3.0	Active
MusicBrainz	10.10.3.0	Active
OMDb	10.10.3.0	Active
Open Subtitles	20.0.0.0	Active (but mis-configured — see §7)
Studio Images	10.10.3.0	Active
TMDb	10.10.3.0	Active

Verdict: culprit (e) "plugin throwing repeated exceptions in log spam loop" → partially confirmed for OpenSubtitles (it throws on every probe — 234 today already), but the cost is per-probe RTT not sustained CPU. Fix is doc 13 finding 04.

---

7. Log error / warning summary (last 24 h, today's log_20260508.log)

/config/log/log_20260508.log is 3 968 lines. Filtered tally:

Pattern	Count today	Notes
[ERR] total	266
[WRN] total	124
Error downloading subtitles from "Open Subtitles"	234	doc 13 finding 04 — Username/Password empty, throws AuthenticationException per file probed; 88 % of all errors today are this one cause
No space left on device : '/config/metadata/library/...'	2	at 13:53:10 — transient ENOSPC during a metadata write; disk now 62 % full (146 GiB free), so this is a moving-target burst (probably caused by 73 MiB+ of transcode segments accumulating in /cache/transcodes while a metadata write tried to extend a small file). Worth watching but not the current bottleneck
Invalid username or password entered (auth fail)	5	three distinct minutes — looks like a user retrying creds, not a brute-forcer
WS ... error receiving data (websocket abrupt close)	~25	normal: clients closing tabs / dropping carrier. Noise, not a defect
Compiling a query which loads related collections... (EF Core warning, slow query)	1	EF Core's QuerySplittingBehavior warning — Jellyfin upstream issue, harmless on this dataset
task was canceled on /videos/.../hls1/main/-1.mp4	1 (17:41)	client gave up mid-segment-init — same 499 family as doc 13's evidence
SQLITE_BUSY / database is locked	0	culprit (d) DB lock contention → ruled out

Verdict:

• culprit (e) "plugin log spam" → confirmed (234 OS errors / day = a scan or page-into-season triggers a loop of failures).
• culprit (d) "DB lock contention" → ruled out (0 SQLITE_BUSY).
• the 2 ENOSPC errors are NEW vs doc 13 and warrant tracking — see §9 culprit 4.

---

8. DB and cache sizes

/config/data/jellyfin.db        288 K   (was 208 K in doc 13 — fine)
/config/data/library.db        3.4 M   (was 3.3 M — fine)
/config/data/library.db-wal    6.2 M   (was 4.4 M — STILL LARGER THAN MAIN, see below)
/config/data/library.db-shm     32 K
/config/metadata                99 M   (was 92 M — fine)
/config/log                    4.2 M   (was 1.3 M — 3× growth in 14 h driven by §7 OS spam)
/cache/transcodes               84 M / 43 files (snapshot)
/cache total                  not measurable from in-container du (mount appears empty due to bind layout)

library.db-wal (6.2 MB) is now ~1.8× the main .db (3.4 MB). Doc 13 finding 08 already raised this — the situation is slightly worse now (WAL grew faster than main during 14 h). Cause: SQLite checkpoints on idle, but with continuous transcode + ffprobe activity from two viewers and library refreshes there is rarely an idle moment to checkpoint. Manual Optimize database will collapse the WAL into the main file.

/cache/transcodes 84 MB / 43 files is the residue of three+ abandoned ffmpeg sessions. Without EnableSegmentDeletion=true, this will grow unbounded for SegmentKeepSeconds=720 per session. Worst case at 1 viewer × 4 zombie sessions × 720 s × 13 Mbps = ~5.6 GiB transient cache per minute of pile-up. This is exactly how the 13:53 ENOSPC happened (cache + metadata fighting for the same 146-GiB free pool).

---

9. Concrete remediation list (ranked impact / effort)

9.1 Quick-wins (rank 1 → 4 — all are minutes of work, all read-only-safe to apply)

1. Cap two transcode flags (Settings → Playback):

   • EnableThrottling = true
   • EnableSegmentDeletion = true Effect: zombie ffmpeg from a stale session is killed instead of producing 720 s of segments after the client has moved on. This single change directly addresses §5's 4-process pile-up. Doc 13 already noted this; the new evidence escalates it from "S effort, cleanup" to "non-optional".

2. Cap concurrency knobs (Settings → Server / Library):

   • LibraryScanFanoutConcurrency = 4
   • LibraryMetadataRefreshConcurrency = 4
   • ParallelImageEncodingLimit = 4 Effect: 7-up ffprobe burst at 13:31 / 17:37 (§5) is capped to 4 parallel probes, not 12. Doc 13 already noted this as S effort.

3. Set RemoteClientBitrateLimit (Dashboard → Playback → Streaming → "Internet streaming bitrate limit"):

   • Suggest 8 Mbps (covers 1080p Bluray rips, kills 4K-upscale decisions on remote sessions). LAN clients that want full-bitrate can be flagged via per-user policy. Effect: the 13.8 Mbps maxrate-on-WAN session becomes a 8-Mbps session that doesn't need the 4K-upscale path — JF stops asking ffmpeg to produce 3840×2160. This is what makes §5's per-stream cost drop by ~70 %. Independent of GPU.

4. Disable Open Subtitles plugin OR populate creds (already in doc 13 finding 04). Removes 234 ERR/day, restores log signal, removes the per-probe RTT.

9.2 Investments (rank 5 → 7 — half-day to multi-day, structural)

5. Add CPU + memory limits to BOTH jellyfin and the Forgejo BlueBuild build container in compose — currently both are uncapped, fighting for the same 12 cores. Suggest:

   • jellyfin: cpus: 8.0, mem_limit: 12G, mem_reservation: 4G
   • forgejo-runner build pods: cpus: 4.0, mem_limit: 8G Effect: a noisy CI build cannot drag interactive playback latency to the floor; viewer always has 8 cores even when BlueBuild is hot. Note that the BlueBuild container is short-lived (forgejo-actions spawns it per job) so the limit goes on the runner's container_options in the runner config, not on a static compose service.

6. Re-enable GPU transcoding on host (doc 13 finding 02 — L effort). With H.264 NVENC at preset p4 the same filtergraph collapses from ~6.4 CPU cores to ~0.3 CPU cores + GPU. Without GPU, the §5 quick-wins are the cap; with GPU, the host can serve 4 simultaneous viewers comfortably.

7. Cap the maximum supported resolution in client policy (Dashboard → Users → each user → Playback → "Maximum allowed video bitrate" / "Maximum allowed video resolution"). Set non-admin users to 1080p max. Closes the foot-gun where any client says "I can do 4K" and Jellyfin obliges with a 4K-upscale CPU bomb.

9.3 Watch-list (no immediate action, monitor next audit)

• ENOSPC at 13:53 (only 2 occurrences, host has 146 GiB free now, so it was a transient pressure burst). Re-check post-quick-wins (1+2 remove the cache pile-up that caused it).
• library.db-wal 1.8× main db — manual Optimize database after the above tasks finish, or tighten its schedule from 24 h to 6 h.
• Container restart at 16:22 (was 02:13 in doc 13) — was this operator- initiated or did unless-stopped re-spin a crash? Check docker logs jellyfin --since 6h for panic/crash next time.

---

10. Quick-win vs investment summary

Bucket	Action	Effort	Expected impact
Quick-win	Throttling + SegmentDeletion ON	2 clicks	Kills §5 zombie ffmpegs immediately; expected load avg drop 40–50 % under one active viewer
Quick-win	Concurrency caps 12 → 4	3 fields	Removes the 7-up ffprobe bursts at season-page navigation
Quick-win	RemoteClientBitrateLimit = 8 Mbps	1 field	Stops Jellyfin choosing 4K-upscale paths for WAN clients; ~70 % drop in per-stream CPU
Quick-win	OpenSubs disable / cred	30 sec	234 ERR/day → 0; cleaner log; faster library scans
Investment	Compose CPU/MEM caps for jellyfin + bluebuild	30 min compose + 1 restart per container	Removes noisy-neighbor head-of-line blocking by the CI runner
Investment	GPU transcode reactivation	days (driver work, host)	20× per-stream CPU efficiency on the 1080p-and-up paths
Investment	Per-user max-resolution policy	5 min × N users	Prevents admin foot-gun and any future invitee from triggering the 4K-upscale path

---

Appendix — raw evidence

Container limits (the absence is the finding)

docker inspect jellyfin --format '{{.HostConfig.Memory}} {{.HostConfig.NanoCpus}}
                                  {{.HostConfig.CpuQuota}} {{.HostConfig.CpuPeriod}}
                                  {{.HostConfig.PidsLimit}} {{.HostConfig.RestartPolicy.Name}}'
→ 0 0 0 0 <no value> unless-stopped

Host CPU + load + memory

nproc:           12
lscpu Model:     AMD Ryzen 5 2600X Six-Core Processor (6c / 12t, NUMA0=0–11)
uptime:          17:42:14 up 4 days 17:59,  2 users,  load average: 15.43, 14.61, 8.85
free -h:         total 31Gi, used 10Gi, free 8.2Gi, buff/cache 13Gi
                 swap total 24Gi, used 7.8Gi (32 %), SwapCached 789 976 kB
vmstat 1 5 (us / sy / id / wa, last sample): 71 / 13 / 16 / 0
                 r=11, b=1, cs ≈ 30 K/s
iostat (nvme0n1): 38–433 w/s, 364–2 272 wkB/s, util 0.4–0.9 % — disk idle

Top hosts on host (snapshot)

ps -eo pid,user,pcpu,pmem,rss,etimes,args --sort=-pcpu | head:
1681949 user  643 %  6.9 %  2.30 GB   53 s  ffmpeg [Rick & Morty S01E01, 4K-upscale + sub burn]
1662267 root   52 %  0.1 %       —   426 s  fuse-overlayfs (BlueBuild rootfs mount)
1661952 root   36 %  0.1 %       —   431 s  fuse-overlayfs (BlueBuild rootfs)
1485847 git    8  %  0.8 %  266 MB     —    gitea web (forgejo)
 364785 user   8  %  2.6 %  867 MB     —    openclaw-gateway
1901802 java   8  % 12.7 %  4.2 GB     —    minecraft jvm (-Xmx14336M)
1660709 root   7  %  0.3 %  100 MB   442 s  buildah build (BlueBuild)
1626511 user   4  %  1.6 %  544 MB     —    /jellyfin/jellyfin (server proc)

All 4 active ffmpeg's (full filter chain shown for the heaviest one)

PID 1681949 (643 % CPU):
  -ss 33s -noaccurate_seek -canvas_size 1920x1080
  -i Rick.and.Morty.S01E01.mkv
  -threads 0 -map 0:0 -map 0:1 -map -0:0
  -codec:v libx264 -preset veryfast -crf 23 -maxrate 13546858 -bufsize 27093716
  -profile:v high -level 51
  -filter_complex
     [0:4]scale,scale=3840:2160:fast_bilinear[sub] ;
     [0:0]setparams=color_primaries=bt709:color_trc=bt709:colorspace=bt709,
          scale=trunc(min(max(iw,ih*a),min(3840,2160*a))/2)*2
                :trunc(min(max(iw/a,ih),min(3840/a,2160))/2)*2,
          format=yuv420p[main] ;
     [main][sub]overlay=eof_action=pass:repeatlast=0
  -codec:a libfdk_aac -ac 2 -ab 256000 -af volume=2
  -f hls -hls_time 3 -hls_segment_type fmp4 ...

Sessions API (exactly 1 user, mismatched PlayMethod vs TranscodingInfo)

GET /Sessions?activeWithinSeconds=600  →  1 session
  user=s8n  client=Jellyfin Web/Chrome  remote=192.168.0.10
  PlayMethod=DirectPlay (claimed)
  TranscodingInfo:
    VideoCodec=h264  AudioCodec=aac  Container=fmp4/hls
    3840x2160 @ 13.8 Mbps   HW=none   IsVideoDirect=False  IsAudioDirect=False
    Reasons = [VideoCodecNotSupported, AudioCodecNotSupported, SubtitleCodecNotSupported]
    Completion = 0.0 %

Scheduled tasks (none in progress)

(Full table in §4 — every task is Idle, last-run durations 0–3.2 s.)

Plugins (all 6 Active, no faulted)

AudioDB         10.10.3.0  Active
MusicBrainz     10.10.3.0  Active
OMDb            10.10.3.0  Active
Open Subtitles  20.0.0.0   Active   ← 234 ERR/day from auth-empty creds (doc 13 finding 04)
Studio Images   10.10.3.0  Active
TMDb            10.10.3.0  Active

Log tally (today's log_20260508.log, 3 968 lines)

[ERR] lines:                                        266
[WRN] lines:                                        124
"Error downloading subtitles from Open Subtitles":  234   ← 88 % of all ERR
"No space left on device":                            2   ← 13:53:10, transient
"Invalid username or password entered" (login):       5
"WS ... error receiving data":                       ~25  ← noise
"task was canceled" / 499:                            1   ← 17:41
"SQLITE_BUSY" / "database is locked":                 0
EF Core "QuerySplittingBehavior" warning:             1   ← upstream JF

Disk (host vs container view)

host df -h /home:    399G  233G  146G  62 %   (was 90 % in doc 13 — improved)
host df -i /home:     ~1.49M used / ~26.6M       6 %    inodes healthy
container df -h /config /cache /media: same FS, same 146G free

Items / counts

GET /Items/Counts → MovieCount=2  SeriesCount=6  EpisodeCount=181
                    ArtistCount=0  ProgramCount=0  TrailerCount=0
                    SongCount=0  AlbumCount=0  MusicVideoCount=0

Container restart (StartedAt today)

Implied from ScheduledTasks where Trigger=StartupTrigger:
  Clean Transcode Directory             → end 16:22:06   ← container start ≈ 16:22:05
  Clean up collections and playlists    → end 16:22:06
  Update Plugins                        → end 16:22:07
(doc 13 had StartedAt = 02:13:01)

Forgejo BlueBuild container (noisy neighbor, no limits)

docker stats:    CPU 88–99 %   MEM 4.3 GiB   NET in 5 GB   BLOCK in/out 296 MB / 35.3 GB
docker inspect:  Memory=0   NanoCpus=0   CpuQuota=0   ← uncapped

---

Sign-off

• Audit: 2026-05-08, read-only, ~15 min wall.
• No fixes applied. No state mutated. No container restart. No plugins reloaded. No tasks executed.
• Scope respected: server runtime only. Color/HDR, edge/network, and storage findings deferred to sibling agents.
• Next audit due: 2026-08-08 (quarterly, paired with doc 13).