fix(plex): subtitles stop blocking the request, and stop re-reading the file

Bug hunt 2026-09, items 8 and 12 — the two things the Plex player was measurably
lying about.

Item 8: picking a subtitle track showed nothing for a long time, and the reported
workaround was to stop/start until it suddenly worked. Measured on prod against a
17.06 GB MKV with two embedded SubRip tracks:

  full pass, one track                154 s
  full pass, both tracks in ONE run   111 s
  -c:s copy (no WebVTT conversion)    143 s
  from 1:00:00 to the end of file      66 s
  a 630 s window at 1:00:00, both       8 s

So the conversion was never the cost: ffmpeg streams every byte of the container
between its seek point and its stop point, and the array delivers ~140 MB/s. The
only lever is reading less. Three changes follow from that:

  * a window around the playhead is extracted and published FIRST (seconds), and
    the full pass completes behind it;
  * every embedded text track rides that same single read — picking Hungarian used
    to cost a full pass and then switching to English cost another one;
  * none of it happens inside a request any more. The endpoint answers 202 while a
    background worker extracts, the player polls /status (carrying its position, so
    the window follows the viewer), and one ffmpeg run finally has a timeout.

-copyts is deliberately absent from a windowed pass: with it ffmpeg ignores -t and
reads the whole container anyway (measured — a [0, 600 s] window still took the
full 145 s), so a window comes back on a zero-based clock and is shifted to
absolute time here. Cached tracks written by older builds have no coverage sidecar
and count as complete, so nothing is re-extracted after the upgrade.

The <track> is no longer mounted before the server has something to put in it; a
"Preparing subtitles: …" notice stands in, and a track that can never be shown says
why instead of leaving the viewer to conclude the picker does nothing.

Item 12: "Bitrate" read a constant 211 kbps on every remux, because it was the
master playlist's BANDWIDTH — which ffmpeg derives from the one stream whose rate
it knows, the -b:a 192k AAC track, plus 10%. It is a measurement now: bytes per
second of MEDIA from hls.js FRAG_LOADED, accumulated per fragment type and summed
(a multi-audio session's video and audio renditions cover the same media seconds,
so pooling them would report half the truth), and an honest dash until the first
fragment lands. The panel also finally names the audio and subtitle track in play.

Verified in the browser against the real Plex library, and every new test
mutation-checked.

frontend/src/lib/api/plex.ts

@@ -633,8 +633,32 @@ export const plexApi = {
   // WebVTT URL for a text subtitle track (used directly as a <track src>). Same-origin → cookie-authed.
   // `offset` = the session's real media start (0 for direct-play); the backend shifts the absolute
   // cue times onto the HLS session's zero-based clock so subtitles line up with speech after a seek.
-  plexSubtitleUrl: (id: string, ord: number, offset = 0): string =>
-    `/api/plex/subtitle/${encodeURIComponent(id)}/${ord}${offset ? `?offset=${offset}` : ""}`,
+  // `gen` is the cached track's generation: extraction publishes a window around the playhead first
+  // and widens it in the background, so the URL has to change when it grows or the browser would keep
+  // serving the first, short VTT from its own cache.
+  plexSubtitleUrl: (id: string, ord: number, offset = 0, gen = 0): string => {
+    const p = new URLSearchParams();
+    if (offset) p.set("offset", String(offset));
+    if (gen) p.set("gen", String(gen));
+    const q = p.toString();
+    return `/api/plex/subtitle/${encodeURIComponent(id)}/${ord}${q ? `?${q}` : ""}`;
+  },
+  // Whether a subtitle track can be shown yet. Extracting one out of a big MKV costs a full read of
+  // the container (measured: 154 s for a 17 GB film), so the server does it in the background — around
+  // `at`, the viewer's position, first — and the player polls this instead of mounting a <track> that
+  // would sit empty for minutes. `partial` = a window around `at` is ready and still growing.
+  plexSubtitleStatus: (
+    id: string,
+    ord: number,
+    at = 0,
+  ): Promise<{
+    state: "ready" | "partial" | "preparing" | "failed";
+    code: string | null;
+    gen: number;
+  }> =>
+    req(
+      `/api/plex/subtitle/${encodeURIComponent(id)}/${ord}/status?at=${Math.max(0, Math.floor(at))}`,
+    ),
   // `final` marks a settled checkpoint (pause / page-hide / leaving the player) as opposed to the
   // periodic 10s tick — the backend mirrors the resume position to a linked Plex account only on a
   // final checkpoint, so a single watch doesn't spray Plex with timeline updates.