@torrent-tv/proxy 2.83.4 → 2.83.5

package/CHANGELOG.md

@@ -1,3 +1,16 @@
+## 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.5",
   "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

package/services/orchestrators/EncodeOrchestrator.js

@@ -33,6 +33,20 @@ import { contentionPenalty } from "../encode/contention.js";
 import { waits } from "../priority/WaitLedger.js";
 import { SegmentDemand } from "../encode/SegmentDemand.js";
 
+/**
+ * How long nothing is placed on an output whose input has just gone, and the
+ * ceiling that doubling reaches.
+ *
+ * Both are chosen, and are named here as chosen rather than dressed as
+ * measurements: what they bound is not how long the data takes to come back —
+ * that is the swarm's business and nobody here can know it — but how often it
+ * is worth asking. They replace the same two figures, with the same values,
+ * that lived in the session manager and governed only the dead run's own retry
+ * while the plan placed fresh runs beside it every half second.
+ */
+const INPUT_QUIET_BASE_MS = 2_000;
+const INPUT_QUIET_MAX_MS = 15_000;
+
 export class EncodeOrchestrator {
   /** Output address to what has been made of it. @type {Map<string, CoverageMap>} */
   #coverage = new Map();
@@ -47,6 +61,20 @@ export class EncodeOrchestrator {
   /** How runs have ended, by cause. @type {Map<string, number>} */
   #endings = new Map();
 
+  /**
+   * How many times in a row an output's run has died because its input was not
+   * there. Cleared by any other ending, which is the input answering.
+   *
+   * @type {Map<string, number>}
+   */
+  #inputLostAttempts = new Map();
+
+  /** Output address to the time before which nothing is placed on it. @type {Map<string, number>} */
+  #quietUntil = new Map();
+
+  /** The wake-up per output, so a quiet output is reconsidered. @type {Map<string, NodeJS.Timeout>} */
+  #quietTimers = new Map();
+
   /** The last state said out loud, so an unchanged state is not repeated. */
   #lastDescribed = "";
 
@@ -97,6 +125,7 @@ export class EncodeOrchestrator {
     refetchSecPerFilmSecond = () => 0,
     startingSpeedFor = () => 0,
     segmentStore = null,
+    planSoon = null,
     logger,
     now
   }) {
@@ -124,6 +153,9 @@ export class EncodeOrchestrator {
     this.segmentSeconds = segmentSeconds;
     this.logger = logger;
     this.now = typeof now === "function" ? now : Date.now;
+    // Asked for, not commanded: this class decides, and something else owns the
+    // loop that calls it. Absent in a test, where the clock is the test's own.
+    this.planSoon = typeof planSoon === "function" ? planSoon : () => undefined;
   }
 
   /**
@@ -366,6 +398,20 @@ export class EncodeOrchestrator {
         });
       }
     }
+    // ITS INPUT WAS NOT THERE A MOMENT AGO, so nothing is placed yet. The sweep
+    // above still runs — a claim left by a dead run must be released whatever
+    // the reason — and only the placing waits. This is the one thing that makes
+    // the delay bind: it used to be timed against the dead run, which the plan
+    // does not consult, so a fresh run went to the same place as fast as ffmpeg
+    // could fail there.
+    //
+    // AND ONLY WHILE NOTHING IS PRODUCING THERE. A run still alive on this
+    // output is proof the input can be read, whatever a run beside it met, so
+    // the wait must not silence an output that is working.
+    const quietMs = this.#quietFor(address);
+    if (quietMs > 0 && this.runsOn(address).every((run) => !run.isAlive)) {
+      return;
+    }
     // ONE MAP, NOT ONE WINDOW PER VIEWER PER ZONE.
     //
     // Two viewers a few seconds apart state stretches that overlap, and the plan
@@ -696,6 +742,93 @@ export class EncodeOrchestrator {
       this.#runs.set(ended.address, remaining);
     }
     this.#endings.set(ended.ending, (this.#endings.get(ended.ending) ?? 0) + 1);
+    this.#noteInputAvailability(ended);
+  }
+
+  /**
+   * Remember, per output, that its input was not there — and until when nothing
+   * is to be placed on it.
+   *
+   * **Why the plan has to hold this.** A run whose input has gone is not alive,
+   * so the plan sees the stretch it held as free and places another run there at
+   * once — and the next one dies the same way, because nothing about the state
+   * has changed. There WAS a delay for exactly this, doubling from 2 s to 15 s,
+   * and it governed only the dead run's own retry while the plan went on placing
+   * fresh ones beside it. The comment beside that timer predicted this in as
+   * many words and the code did not prevent it. Field 2026-09-12: 2432 ffmpeg
+   * starts in 23 minutes, one every 0.57 s, for 61 minutes, against a delay that
+   * had long since reached its 15 s cap.
+   *
+   * So the delay lives where the decision is taken. It is not a cure for the
+   * input being away — that is the store's claim being withdrawn and the piece
+   * being fetched again — it is what stops one absent input from costing a
+   * thousand processes and a quarter of a million log lines while it is away.
+   *
+   * @param {{ address: string, ending: string }} ended
+   * @returns {void}
+   */
+  #noteInputAvailability(ended) {
+    if (ended.ending !== ENCODE_EXIT.INPUT_LOST) {
+      // CLEARED ONLY BY PROOF THAT THE INPUT WAS THERE, which is a segment
+      // having come out of it. Any other ending was nearly the rule here and is
+      // wrong: at the moment of failure several runs end at once, and one of
+      // them ending `gone` or `stopped` without producing a thing says nothing
+      // about the input — it would have lifted the wait the one beside it had
+      // just set, which is the storm again with an extra step.
+      const produced =
+        ended.firstOutputMs !== null && ended.firstOutputMs !== undefined
+          ? true
+          : Number.isFinite(ended.reached) && Number.isFinite(ended.from) && ended.reached >= ended.from;
+      if (produced) {
+        this.#inputLostAttempts.delete(ended.address);
+        this.#quietUntil.delete(ended.address);
+      }
+      return;
+    }
+    const attempts = (this.#inputLostAttempts.get(ended.address) ?? 0) + 1;
+    this.#inputLostAttempts.set(ended.address, attempts);
+    const delayMs = Math.min(
+      INPUT_QUIET_MAX_MS,
+      INPUT_QUIET_BASE_MS * 2 ** Math.min(attempts - 1, 6)
+    );
+    this.#quietUntil.set(ended.address, this.now() + delayMs);
+    this.logger.info(
+      `encode-plan on ${ended.address}: its input was not there (attempt ${attempts}) — ` +
+      `placing nothing for ${Math.round(delayMs / 1000)}s`
+    );
+    // THE WAKE-UP, because a plan that refuses to act needs something to ask it
+    // again: nothing about the state changes while the data is away, so no event
+    // would arrive to reconsider it.
+    const timer = setTimeout(() => {
+      this.#quietTimers.delete(ended.address);
+      this.planSoon();
+    }, delayMs);
+    timer.unref?.();
+    const previous = this.#quietTimers.get(ended.address);
+    if (previous) {
+      clearTimeout(previous);
+    }
+    this.#quietTimers.set(ended.address, timer);
+  }
+
+  /**
+   * How long this output still has to wait before anything is placed on it, in
+   * milliseconds; zero when it may be planned now.
+   *
+   * @param {string} address
+   * @returns {number}
+   */
+  #quietFor(address) {
+    const until = this.#quietUntil.get(address);
+    if (!Number.isFinite(until)) {
+      return 0;
+    }
+    const left = until - this.now();
+    if (left <= 0) {
+      this.#quietUntil.delete(address);
+      return 0;
+    }
+    return left;
   }
 
   /**