diff --git a/docs/architecture.md b/docs/architecture.md
index 275978f..698001b 100644
--- a/docs/architecture.md
+++ b/docs/architecture.md
@@ -510,6 +510,29 @@ real `Hls` instance from the exact pinned CDN build
 `hls.config.fragLoadingTimeOut` etc. - all four came back as set, not as
 hls.js's own defaults.
 
+**Round 4: a real 500, once the timeout was no longer masking it - traced
+to Emby, not this app.** Exactly what Round 2 said would happen "if
+subtitles still don't show once this log line confirms `subtitleMethod=
+Encode` really was sent": with Round 3's timeout fix giving Emby enough
+rope to actually answer instead of hls.js giving up first, the segment
+request came back with a real, fast 500 - and Emby's own server log
+(shared directly, not this app's) shows exactly why: `[subtitles@f2] Failed
+to load fontconfig fonts!`, thrown out of `StartFfMpeg`/
+`GetDynamicSegment` before a response body ever exists. That's ffmpeg's
+`subtitles` filter (burning text into the video via `libass`) failing to
+find usable fonts/a fontconfig cache in whatever environment Emby's
+transcoder runs in - a deployment/environment issue on the Emby side
+(commonly a container image missing font packages, or a fontconfig cache
+directory that isn't writable), with nothing in this app's request that
+could cause or fix it. Confirmed not a regression to work around here:
+this app deliberately forces `SubtitleMethod=Encode` (see
+`applyPlaybackOverrides`'s own comment) specifically because it never
+wires up `hls.js`'s rendition-based subtitle API - dropping that override
+to dodge this 500 would silently bring back the very first version of
+this bug (a subtitle picked, never shown) instead of fixing anything.
+Nothing to change in this app for this one; it needs fonts/fontconfig
+fixed wherever Emby's own container/host runs.
+
 ## Assumptions to verify
 
 **Confirmed against the real server** (not a guess — actually exercised,