@torrent-tv/proxy 2.83.4 → 2.83.6

package/CHANGELOG.md

@@ -1,3 +1,24 @@
+## 2.83.6
+- **Fix**: A line forwarded from the torrent thread is no longer judged twice. That thread holds the same repeat rule and applies it before forwarding, and the main thread ran it again on a different history. It does not lose lines today — a re-printed line carries its held-back count, which makes the text unique — but that is an accident of the wording, against a promise this module states outright: a line cannot reach the console and miss the file. It also filled the main thread's bounded map with keys that can never repeat.
+- **Fix**: The LEVEL travels with a forwarded line. It was dropped at the send, so every warning and every error the torrent thread has ever written arrived on the other side as information, and was coloured and recorded as such.
+- **Fix**: The wait after a lost input is cleared only by a run that PRODUCED something, and the field documenting it said "cleared by any other ending" — the rule it replaced, two screens above the code that contradicted it.
+- **New**: `torrent-pool: N piece claim(s) withdrawn` is printed. The pool counted them and nothing read the count, which is the state this project's own rule calls indistinguishable from having noticed once. The gap between it and the stores' `withdrawn=` is the reading: announcements far above withdrawals mean the stores are mostly dropping pieces that were never completed, and a withdrawal count stuck at zero while announcements climb means the mechanism is not reaching the torrent at all.
+- **Chore**: What the plan remembers about an output's input is forgotten when the priority map says nobody is coming there. Three maps keyed by address would otherwise keep an entry for the life of the process, and the wait they describe would greet whoever opened that output next.
+- **Chore**: The suffix saying how many repeats were held back was built in two branches with the same expression; one function now. The quiet check returned milliseconds that its only reader compared against zero; a boolean now.
+
+## 2.83.5
+- **Fix**: ONE OWNER OF THE FACT "THIS PROXY HAS PIECE N", AND IT IS THE STORE. The disk tier drops a piece once every reader is past it — correctly, and that is what bounds the spill — while the library kept a second copy of the same fact in its completion bitfield and nothing reconciled them. A read then concluded the piece was had, asked for it, was told it was absent, and failed; nor was it ever fetched again, because the library does not download what it believes it owns. Field 2026-09-12: a film played 80 seconds (1920 frames, and the picture never moved again); the encoder ran on to 725 s, so some 565 spilled pieces fell behind every read head and were dropped, piece 0 among them; the encoder lost its input and restarted, which re-opens the input at byte 0; and `/stream` answered `0 of 2363497962 bytes: Piece 0 is verified but absent from the store` to every read for the next 92 minutes while the browser retried one segment against a healthy transport at 4 ms.
+- **Fix**: So the store announces when it can no longer produce a piece AT ALL — not resident, not on disk, not inside a file held whole — and the pool withdraws the library's claim. The eviction's own bargain, written in its comment as "a seek back re-downloads it", is true for the first time. The three cases are one rule rather than a list of call sites: the disk tier says only that IT has lost a piece, and the store decides whether that is a loss at all, so a piece dropped as a duplicate of an assembled file says nothing and a piece still resident says nothing.
+- **Chore**: The withdrawal is a plain function over plain values (`services/download/withdraw-claim.js`) and holds no pool, no store and no client, so it can be exercised with an object literal. It deliberately does not re-select the piece: every torrent is added with `deselect: true`, which makes the library skip that, and the download set keeps its one owner.
+- **Chore**: `withdrawn=` joins the piece store's own line, so the bargain is checkable by number instead of by belief.
+- **Fix**: A READ NOW SURVIVES A PIECE WITHDRAWN UNDER IT. An empty answer is a wait, not a failure: the claim has just gone, so the piece is being fetched again, and the read goes back one step and takes the whole ordinary path for it — declare it, steer it onto the fastest holders, wait. Once per piece; a second emptiness says the bytes are not coming and is reported as that rather than as "verified but absent", which was never true.
+- **Fix**: THE DELAY AFTER A LOST INPUT NOW BINDS. It existed — doubling from 2 s to 15 s — and it was timed against the DEAD RUN, which the plan never consults: a run whose input has gone is not alive, so the plan read the stretch it held as free and placed another there at once, which died the same way. Field: 2432 ffmpeg starts in 23 minutes, one every 0.57 s, for 61 minutes, against a delay that had reached its ceiling long before. The wait lives beside the decision it governs now, per output, and the plan places nothing there until it is over — unless something on that output is still producing, which is proof the input can be read.
+- **Fix**: The wait is lifted only by proof that the input was there, which is a segment having come out of it. Any other ending nearly did it, and that is wrong: at the moment of failure several runs end at once, and one ending `gone` with nothing produced would have lifted the wait the one beside it had just set.
+- **Chore**: The two figures and the timer leave `hls-session-manager.js` for the encoding layer; the file is 28 lines shorter.
+- **Fix**: AN ESTABLISHED FACT IS SAID ONCE, THEN WITH DECREASING FREQUENCY. One absent piece produced about 55 log lines a second: 235 000 lines in 92 minutes, of which 68.8 % were byte-identical repeats — measured, not estimated. Repeats are matched verbatim, the whole line, which catches nearly all of that and cannot merge two different statements; normalising numbers would catch a little more and would also merge the memory series, which exists precisely to catch a runaway. A held-back line is said again at doubling intervals up to a minute, and says how many were held back and over what span, because the rate is the fact.
+- **Fix**: The log file may now grow to 1 GB before it turns over, from 32 MB. At the old size that one failure turned the file over twice inside the session it belonged to — 159 000 lines covering 38 minutes, then 76 385 covering 23 — so 61 minutes of 92 survived and the second rotation overwrote the turn holding the onset. The disk it was bounded for had 91.4 GB free.
+- **Chore**: KNOWN CONSEQUENCE, stated rather than discovered later: a torrent whose pieces have been dropped is no longer `done`, so a film watched to the end is not assembled into a whole file. That is the honest state — we do not have those bytes — and the previous behaviour was worse than it looked: the assembly reads the file through the store, so it would have waited for pieces the library wrongly believed it had.
+
 ## 2.83.4
 - **Chore**: WHAT IS IN A TORRENT IS NOW A THING RATHER THAN A RECOMPUTATION. `services/torrent/Contents.js` holds one torrent's list of files, its pictures with the sound, subtitles and images that belong to each, the order a person reads them in, and what belongs to nothing. The pairing rules were already there as functions; what did not exist was anywhere to keep their answer, so the warm-up on one path and the playback plan on another worked out the same grouping over the same list several times per opened film. Checked against the survey collection: 134 torrents, 44 of them with more than one picture, 1357 pictures and 421 files paired to one, not a single file paired to two — and all 1357 groupings agree with the per-picture call they replace, so nothing about the pairing changes.
 - **Chore**: It holds only what the torrent says about itself. Nothing about a FILM: a poster or a title is an answer from a third party about an identity read from a file's own bytes, keyed by the picture's file, and it must never delay playback. No reference to another layer either — not a container, not a priority map, not a viewer; what leaves is plain indices into the torrent's own list.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@torrent-tv/proxy",
-  "version": "2.83.4",
+  "version": "2.83.6",
   "description": "Torrent proxy client that exposes webseed-like HTTP stream endpoint.",
   "license": "GPL-3.0-or-later",
   "publishConfig": {

package/research/piece-withdrawn-but-still-claimed-2026-09-12.md

@@ -0,0 +1,175 @@
+# A film played 80 seconds and then stood still for 92 minutes — 2026-09-12
+
+Proxy 2.83.4, addon 0.74.1, one viewer, `Reacher.S04E07.1080p.rus.LostFilm.TV.mkv`
+(2 363 497 962 bytes). Reported by the user as "the film only managed to play
+one minute nineteen seconds".
+
+Every claim below is tagged by where it comes from: **[log]** read out of a
+captured log, **[code]** read out of the source, **[measured]** computed from
+the captured logs, **[derived]** reasoned from two of the above.
+
+## 1. What the viewer saw
+
+**[log, browser]** Every one of the 1112 `decode` readings in the captured
+window is identical: `t=80.0s size=1920x1080 frames=1920 dropped=0
+readyState=2`. 1920 frames at 24 fps is 80.0 s, so the picture advanced 80
+seconds and then never moved again. The page stayed open until 18:52.
+
+**[log, browser]** From then on the player asked for one segment and was
+refused, about once a minute for 92 minutes:
+
+```
+18:30:47 non-fatal: fragLoadError currentTime=79.97 msReadyState=open
+         frag=segment-00008.mp4 sn=8 action=5 error=Error: HTTP Error 503 …
+18:41:15 fatal:     fragLoadError … sn=8 … HTTP Error 503
+18:41:17 recovered fatal networkError, resuming at 80.0s
+```
+
+`msReadyState=open` throughout, so this is **not** the closed-MediaSource
+failure of item 86. **[log]** The transport was healthy the whole time —
+`rtt=4ms`, `state=connected ice=connected`, every counter advancing — so it is
+not item 10 either.
+
+## 2. What the proxy answered, and why
+
+**[code]** 503 in `routes/transcode/session-file/get.js:143` is the
+`warming-up` branch: the segment is still being produced. It was never produced.
+
+**[log]** 239 times:
+
+```
+transcode 17ec5953 holding segment-00008.mp4: the file is not on disk
+  (runs from #8, viewer at #8, encoder alive, index #8, produced 0.0s at 2.23x
+   — the encoder has not made it)
+[hold] segment-00008.mp4 warming-up after 60400ms (the map wants it now, rank 69 of 69)
+```
+
+**[log]** The encoder could not open its input, 5712 times:
+
+```
+encode-run #8..#247 lost its input ([http @ …] Error reading HTTP response: End of file)
+Error opening input file http://127.0.0.1:9090/stream?sourceKey=94dda59f…   (8514×)
+Error opening input files: End of file                                       (5712×)
+```
+
+**[log]** And `/stream` said exactly what was wrong, 2884 times:
+
+```
+stream: read of "Reacher.S04E07.1080p.rus.LostFilm.TV.mkv" bytes 0-2363497961
+  ended after 0 of 2363497962 bytes: Piece 0 is verified but absent from the store.
+```
+
+Zero bytes of 2.36 GB. ffmpeg reads an empty body as the end of the file.
+
+## 3. The cause
+
+**[log]** The torrent believed it had the whole file:
+
+```
+[stats] 94dda59f 5d276be5 peers=54 connected … file=100.0% header=8388608/8388608B
+```
+
+**[log]** The store did not:
+
+```
+piece-store "Reacher.S04E07…": resident=27/42 (108MB of 168MB allowed)
+  committed=108MB blocks=27 on-disk=26MB pinned=0 spilled=7
+  reads=5932 (73.8% from memory) spills=571 revivals=41
+```
+
+**[measured]** 571 spills at a 4 MB piece is about 2284 MB written to disk;
+26 MB remained. So roughly 565 pieces had been removed. **[log]** It was not
+the disk cap: `disk: 93634MB free; spilled pieces 26MB of 46656MB` — the
+ceiling never came near binding, and 93 GB were free.
+
+**[code]** That leaves exactly one remover: `PieceDiskStore.forgetBehind`,
+called from `SharedPieceStore.reviseSpillCeiling`, which drops every piece
+lying behind the earliest read head. **[log]** The encoder had reached
+`proxyProcessed=725.643`, twelve minutes of film, so piece 0 — the start of the
+file and its Matroska header — was far behind every reader and was dropped.
+That is the rule working as designed.
+
+**[code]** `piece-reader.js:151` then asks `torrent.bitfield.get(index)`. The
+library still answered yes, because it had downloaded and hashed that piece
+once. **Nothing ever told it otherwise:** `bitfield.set` does not occur
+anywhere in `services/piece-store/`, `services/torrent-pool.js` or
+`services/torrent-worker/`. So the read concluded the piece was had, asked the
+store, was told it was absent, and threw.
+
+**[derived]** And it was never fetched again, because the library does not
+download a piece it believes it owns. The comment on `forgetBehind` states the
+bargain in as many words — "a seek back re-downloads it, which is the same
+bargain this tier makes whenever it drops a piece for room" — and that bargain
+had never once been honoured.
+
+**[derived]** The trigger is ordinary: an encoder restart re-opens its input at
+byte 0 (`bytes 0-2363497961` in the log), which is precisely the region
+`forgetBehind` removes first.
+
+This is the "un-have problem" the parent `CLAUDE.md` names in the Level 2 disk
+design — "mark the piece incomplete in the completion store → it re-downloads on
+the next read". The eviction shipped; the un-have did not.
+
+## 4. Two amplifiers, each a defect of its own
+
+### The delay after a lost input did not bind
+
+**[code]** `hls-session-manager.js` timed a retry against the DEAD RUN, doubling
+2 s → 15 s. **[code]** `EncodeRun.isAlive` is false in `RETRY_WAIT`, and the
+orchestrator plans from live runs only — so the plan saw the stretch as free and
+placed a new run at once, on every event.
+
+**[measured]** 2432 `restart for` lines in 23 minutes: one every 0.57 s, for 61
+minutes, while the delay printed `retrying in 15s`. The comment beside that
+timer predicted this exactly and the code did not prevent it.
+
+### The log destroyed the record of its own failure
+
+**[measured]** 76 385 lines in 23 minutes and 159 000 in the previous 38 — about
+55 lines a second, of which **52 567 of 76 385 (68.8 %) are byte-identical
+repeats**. **[code]** `MAX_FILE_BYTES` was 32 MiB with one previous turn kept, so
+the file turned over twice inside the session: 61 minutes of 92 survived, and the
+onset — everything before 17:51 — was overwritten by the second rotation and is
+gone. **[log]** `/data` had 91.4 GB free.
+
+## 5. What was built (proxy 2.83.5)
+
+1. the store announces when it can no longer produce a piece at all — not
+   resident, not on disk, not in a file held whole — and the pool withdraws the
+   library's claim with `_markUnverified`. The disk tier states only its own
+   loss; the store decides whether that is a loss;
+2. a read whose piece is withdrawn under it goes back one step and takes the
+   whole ordinary path again instead of throwing. Once per piece;
+3. the delay lives in the orchestrator, per output, and the plan places nothing
+   there until it is over — unless something on that output is still producing.
+   It is lifted only by a run that actually produced;
+4. an established fact is logged once, then at doubling intervals to a minute,
+   saying how many were held back. Matched verbatim; digits are deliberately not
+   normalised, because that would merge the memory series;
+5. the log file may reach 1 GB before turning over.
+
+## 6. What this does NOT establish
+
+1. **Nothing here has been seen in the field.** The next session is the proof.
+   What should appear: `withdrawn=` climbing on the piece-store line while reads
+   keep succeeding, `its input was not there (attempt N) — placing nothing for
+   Xs`, and `[said N more time(s) …]` instead of a flood. What should disappear:
+   `Piece N is verified but absent from the store`.
+2. **The onset was not read.** Both log turns begin with the failure already
+   established, so which piece failed FIRST, and whether the encoder's first
+   input loss had the same cause, is not known. The mechanism is established;
+   its first instance is not.
+3. **A consequence, stated rather than discovered later:** a torrent whose
+   pieces have been withdrawn is no longer `done`, so a film watched to the end
+   is not assembled into a whole file. That is the honest state — those bytes
+   are not here — and the previous behaviour was worse than it looked, since the
+   assembly reads the file through the store and would have waited for pieces
+   the library wrongly believed it had. What is NOT measured is how often a film
+   now fails to be assembled, and whether keeping the pieces of a nearly-finished
+   file would be worth the disk.
+4. **The re-download cost is not measured.** A seek back past the read heads now
+   waits for pieces to be fetched again instead of failing. How long that takes
+   on a real swarm, and whether the viewer notices, needs a session.
+5. **`peers=54 connected of -4599 known (…, -1128 queued)`** — the negative
+   figures come from WebTorrent's own `_peersLength`/`_numQueued`, read for the
+   log only. Not investigated, not touched.

package/research/priority-map-is-the-truth-2026-09-12.md

@@ -188,20 +188,38 @@ both fixed with a check apiece.
    the moment of the departure and then never re-examined: in its swarm, with no
    idle clock running. The pass acts on what it just said now.
 
-## The shape of the shared statement — DECIDED
-
-The classification is a PACKAGE rather than an answer the proxy returns, and the
-reason is timing: the browser shows the list of episodes the instant a
-`.torrent` is opened, before a proxy has been chosen, let alone connected.
-Making it wait for an answer would trade one defect for a slower first screen.
-
-`@torrent-tv/torrent-contents` is published from the proxy's own
-`services/torrent`, and the browser imports it by the same bare name: Node
-resolves it out of `node_modules`, and an import map in the page points that
-name at `/vendor/torrent-contents/`, which the server serves straight from the
-installed package. Nothing is bundled and nothing is copied.
-
-Verified in a browser 2026-09-12: the page fetched `Contents.js`, `files.js` and
-`naming.js` from that prefix with 200 each, `classifyMediaFiles` ran through the
-package, and the episodes came back in reading order — `ep2` before `ep10` — with
-a paired subtitle on its own episode and an unpaired soundtrack still offered.
+## Where the shared statement lives — DECIDED, then REVERSED the same day
+
+It was first published as a package, `@torrent-tv/torrent-contents`, so that
+both runtimes could read the same three files: the proxy states what to fetch
+from them, and the browser showed the list of episodes the instant a `.torrent`
+was dropped, before a proxy had been chosen.
+
+**Withdrawn within the hour, on the user's question: is the package better than
+moving it all to the proxy, when the torrent has to go there after the choice
+anyway.** It is not. The package bought one property — the instant list — with
+three permanent costs: a third artifact to version and publish, two copies at
+runtime that drift by version (a test was written for that drift, which is an
+admission the risk is real), and three wiring points that break the page at load
+with no error anybody sees (a second test was written for those).
+
+The answer is the route that already lists a source's files. For a magnet
+nothing changes at all — that is the path it has always taken — and the dropped
+`.torrent` now takes the same one. What leaves the browser with it is not only
+the classification but the whole notion of deciding anything from a name; what
+stays is what only the browser can see (the trackers and the web seeds in the
+file it holds) and how a name is SHOWN.
+
+**The cost is answered by connecting earlier, which is the user's own point.**
+Everything a viewer does needs a proxy, and choosing one and connecting to it
+used to begin only after a file had been picked. It begins when the page loads
+now, silently and with its failure swallowed, and `#acquireTransport` is
+joinable — so whatever the viewer does next joins that attempt instead of
+starting a second. Verified in a browser 2026-09-12: the page opens, the connect
+runs on its own (`public-only connect failed …; trying local path` on a dev
+server with no proxies registered), nothing is shown for it, and the page's own
+adapter turns the proxy's answer into the three lists with the order preserved,
+the torrent's own numbers kept and the release's repeated part taken off the
+names.
+
+`@torrent-tv/torrent-contents@1.0.0` is deprecated on npm with the reason.

package/services/download/withdraw-claim.js

@@ -0,0 +1,80 @@
+/**
+ * @file Withdrawing the claim that this proxy has a piece.
+ *
+ * **The fact has one owner and it is the store.** The store holds the bytes, so
+ * it says what this proxy has. The library keeps a second copy of that fact in
+ * its completion bitfield, and until 2026-09-12 nothing reconciled the two: the
+ * disk tier drops a piece once every reader is past it — correctly, and that is
+ * what bounds the spill — while the bitfield went on saying the piece was
+ * verified. A read then concluded the piece was had, asked for it, was told it
+ * was absent, and failed. Nor was it ever fetched again, because the library
+ * does not download what it believes it already owns.
+ *
+ * Field 2026-09-12: a film played 80 seconds; the encoder ran on to 725 s, so
+ * some 565 spilled pieces fell behind every read head and were dropped,
+ * including piece 0; the encoder then lost its input and restarted, which
+ * re-opens the input at byte 0; and `/stream` answered `0 of 2363497962 bytes:
+ * Piece 0 is verified but absent from the store` to every read for the next 92
+ * minutes while the browser retried one segment and the picture stood still.
+ *
+ * So the eviction's own bargain — "a seek back re-downloads it" — is made true
+ * here, and the bitfield becomes a projection of what the store holds.
+ *
+ * **Why it is a plain function.** It takes the values it needs and holds
+ * nothing: no pool, no store, no client. That is what lets it be exercised with
+ * an object literal, and it is the rule the layers are checked against — a layer
+ * must be usable with plain values alone, with no process, no disk and no clock.
+ */
+
+/**
+ * Tell the library it no longer has a piece, so the next read of it waits for a
+ * download instead of failing.
+ *
+ * **What it deliberately does not do.** The library's `_markUnverified` would
+ * also re-select the piece; it does not here, because every torrent is added
+ * with `deselect: true`, which sets the library's own `_startAsDeselected` and
+ * makes it skip that call. The download set has exactly one owner —
+ * `SwarmSelection`, from the priority map — and a withdrawn piece is fetched
+ * again when a read states it, which is the same statement every other piece
+ * waits on.
+ *
+ * @param {object} what
+ * @param {number} what.index - The piece the store can no longer produce.
+ * @param {object[]} [what.files] - The store's own files; the torrent that owns
+ *   them is found through one of them, because the store has no idea what a
+ *   torrent is.
+ * @param {object} [what.torrent] - Given directly instead of through `files`.
+ * @param {(line: string) => void} [what.warn] - Said when the library refuses.
+ * @returns {"withdrawn" | "nothing-to-withdraw" | "no-torrent" | "refused"}
+ */
+export function withdrawClaim({ index, files, torrent, warn = () => undefined }) {
+  if (!Number.isInteger(index) || index < 0) {
+    return "nothing-to-withdraw";
+  }
+  const owner = torrent ?? files?.[0]?._torrent ?? null;
+  // A torrent being destroyed is the ordinary case at the end of a session, and
+  // it has no claim left to withdraw: the store is going with it.
+  if (!owner || owner.destroyed || typeof owner._markUnverified !== "function") {
+    return "no-torrent";
+  }
+  // NOTHING TO WITHDRAW, which is most of the time: the store also drops pieces
+  // it never completed, and marking one unverified that the library already
+  // knows is missing would re-create the piece and discard whatever blocks are
+  // in flight for it.
+  if (!owner.bitfield?.get?.(index)) {
+    return "nothing-to-withdraw";
+  }
+  try {
+    owner._markUnverified(index);
+  } catch (error) {
+    // This reaches into the library's own bookkeeping. If a later version
+    // changes it, the honest result is a line saying so rather than an eviction
+    // that fails.
+    warn(
+      `could not withdraw the claim on piece ${index} of ${owner.name ?? "?"}: ` +
+      `${error?.message ?? error}`
+    );
+    return "refused";
+  }
+  return "withdrawn";
+}

package/services/hls-session-manager.js

@@ -441,13 +441,6 @@ const START_FAST_FAIL_MS = 2_000;
 // for whatever residual case still fails — not a second competing "fix" that
 // blindly retries the identical command hoping for a different result.
 const MAX_FAILED_STARTS = 3;
-// A run that lost its INPUT is retried rather than condemned: the torrent can
-// be added again and the pieces downloaded again, so the data being gone is a
-// wait, not a verdict. Backed off so a source that is truly unavailable costs a
-// process every few seconds rather than continuously, and never given up on —
-// the session's own idle TTL is what ends it if the viewer leaves.
-const INPUT_RETRY_BASE_MS = 2_000;
-const INPUT_RETRY_MAX_MS = 15_000;
 // Idle TTL: a session is disposed this long after the last segment/playlist
 // access. Long enough that a viewer who pauses, backgrounds the tab, or briefly
 // turns the phone off can resume WITHOUT a cold ffmpeg restart (the warm session
@@ -1577,6 +1570,11 @@ export class HlsSessionManager {
       contentionPenalties: this.contentionPenalties,
       startingSpeedFor: (address) => this.encodeCost.speedForOutput(address),
       segmentStore: this.segmentStore,
+      // HOW IT ASKS TO DECIDE AGAIN. A plan that refuses to place anything
+      // because an output's input is away needs something to bring it back:
+      // nothing about the state changes while the data is missing, so no event
+      // arrives on its own.
+      planSoon: () => this.planEncodersSoon(),
       logger
     });
     // What a start and a stop were measured to cost here, before any viewer
@@ -5709,33 +5707,19 @@ export class HlsSessionManager {
     // condemn a session whose data merely went away.
     if (ended.ending === ENCODE_EXIT.INPUT_LOST) {
       session.inputRetryCount = (session.inputRetryCount ?? 0) + 1;
-      const delayMs = Math.min(
-        INPUT_RETRY_MAX_MS,
-        INPUT_RETRY_BASE_MS * 2 ** Math.min(session.inputRetryCount - 1, 6)
-      );
       logger.warn(
         `transcode ${session.id} encode-run #${ended.from}..#${ended.to} lost its input ` +
-          `(${session.lastError}); retrying in ${Math.round(delayMs / 1000)}s ` +
-          `(attempt ${session.inputRetryCount})`
+          `(${session.lastError}) (attempt ${session.inputRetryCount})`
       );
-      session.inputRetryTimer = setTimeout(() => {
-        session.inputRetryTimer = null;
-        if (run.state !== ENCODE_RUN_STATE.RETRY_WAIT) {
-          return;
-        }
+      // HOW LONG TO WAIT IS THE PLAN'S, and this says only what happened. The
+      // delay used to be timed here, against the dead run, which the plan never
+      // consults — so it placed a fresh run at the same spot as fast as ffmpeg
+      // could fail there: 2432 starts in 23 minutes in the field 2026-09-12,
+      // against a delay that had reached its 15 s ceiling long before. The
+      // orchestrator holds it now, beside the decision it governs.
+      if (run.state === ENCODE_RUN_STATE.RETRY_WAIT) {
         run.retryDue();
-        // The data may be back, which is a reason to DECIDE again and not a
-        // decision. Where to start is the plan's, from where the viewers are;
-        // this used to start one at the segment last requested, which is the
-        // player's read head rather than anybody's position, and is a number
-        // requests are explicitly not allowed to steer an encoder by.
-        //
-        // What the delay is for stays: the plan is a function of the state, and
-        // nothing about the state changes while the torrent is away, so it would
-        // command the same start as fast as ffmpeg could fail.
-        this.planEncodersSoon();
-      }, delayMs);
-      session.inputRetryTimer.unref?.();
+      }
       return;
     }
     // A run that exits THIS fast never did real work: it failed at the start
@@ -7647,14 +7631,6 @@ export class HlsSessionManager {
    * @returns {void}
    */
   #stopEncodeRun(session, reason) {
-    // Everything armed to re-decide on this session's behalf. A stop that
-    // leaves the input-retry timer running is not a stop: it fires seconds
-    // later and has the plan asked again for a session nobody is watching, and
-    // torrent starvation, which is what arms it, is routine here.
-    if (session.inputRetryTimer) {
-      clearTimeout(session.inputRetryTimer);
-      session.inputRetryTimer = null;
-    }
     const running = liveRunsOf(session);
     if (running.length === 0) {
       return;
@@ -9969,10 +9945,6 @@ export class HlsSessionManager {
       }
     }
 
-    if (session.inputRetryTimer) {
-      clearTimeout(session.inputRetryTimer);
-      session.inputRetryTimer = null;
-    }
 
     // Whether the process is still RUNNING, not whether anyone has called kill
     // on it: `.killed` means only that a signal was sent, and a run that ended