@torrent-tv/proxy 2.9.110 → 2.9.112

package/CHANGELOG.md

@@ -1,3 +1,12 @@
+## 2.9.112
+
+- **New**: A session whose data went away now waits for it to come back instead of dying. Losing the input is not the session failing — the torrent can be added again and the pieces downloaded again — but a run that died that way marked the session terminal, and every request for the playlist answered 500 from then on, although the swarm was right there and the data would have returned in seconds. Such a run is now retried at the position the viewer is waiting at, backing off from 2 s to at most 15 s so a source that is genuinely unavailable costs a process every few seconds rather than continuously, and the requests being held are simply held: nothing is broken and there is nothing for the viewer to retry. The circuit breaker stays for what it was built for — a target that truly cannot be encoded — and no longer condemns a session that merely lost its data. Which of the two happened is decided by the message, tested against the exact ones the field produced.
+
+## 2.9.111
+
+- **Fix**: The film being watched could be deleted mid-seek. A torrent's data is protected only by a claim that READS take, and a seek leaves a gap with no read at all — the old encoder is dead, the new one has not started. The thirty-second disk sweep met that gap on 2026-08-06: with the cap exceeded it evicted "the idle torrent" that a viewer was in the middle of, deleted six gigabytes, and the new encoder found nothing to read. The session's own thirty minutes never governed the data underneath it, because the pool was never told a session existed. A session now holds its source for as long as it lives, and lets go when it is disposed.
+- **Fix**: The encoder is no longer suspended on ffmpeg's word alone. How far it has run ahead was taken from the position ffmpeg reports for itself, and that is not evidence: field 2026-08-06, it claimed 6012 s processed at `speed=1.18e+03x` on a file one percent downloaded with exactly one segment on disk. The limiter believed it, suspended the encoder twelve seconds into the session, and segment #1 — which nobody was now producing — was held for 45.7 s until the viewer gave up and seeked. It is now measured by the segments that exist, which is what the viewer can actually be served, and a wide disagreement between the two is logged, since that is the only trace of whatever made ffmpeg report a position it had not reached.
+
 ## 2.9.110
 
 - **Fix**: A torrent the pool had destroyed was still being handed to readers, which killed every later session for that source. The torrent thread remembers each source as a promise and only ever forgot one when the ADD failed — but the pool destroys a torrent that has gone unread for a quarter of an hour, and under disk pressure, clearing its own map and knowing nothing about this one. The promise then resolved to a corpse: a destroyed torrent keeps its object and loses its files. Nothing noticed, because by then everything else answers from cache — measured 2026-08-06 on two sessions in a row, the plan came back in 23 ms and the session was created in 2 ms, so no step waited for metadata, and ffmpeg's first read died 130 ms in with `File 0 not found in torrent:…`; every request for the playlist then answered 500 until the viewer gave up. Both sessions were from a phone on a cellular link, which is what made it look like a connectivity problem — ICE had in fact connected in 0.84 s over reflexive addresses and both data channels were open. A handle that cannot be read from is now replaced rather than returned: the source is added again, using the recipe the thread now keeps for exactly this. Covered by tests.

package/package.json

@@ -1,12 +1,15 @@
 {
   "name": "@torrent-tv/proxy",
-  "version": "2.9.110",
+  "version": "2.9.112",
   "description": "Torrent proxy client that exposes webseed-like HTTP stream endpoint.",
   "license": "GPL-3.0-or-later",
   "publishConfig": {
     "access": "public"
   },
   "type": "module",
+  "engines": {
+    "node": ">=24 <25"
+  },
   "bin": {
     "torrent-tv-proxy": "./bin/cli.js"
   },

package/routes/api/transcode-sessions/post.js

@@ -5,7 +5,7 @@
  *
  * @param {import("fastify").FastifyRequest} req
  * @param {import("fastify").FastifyReply} reply
- * @param {{ hlsSessionManager: import("../../../services/hls-session-manager.js").HlsSessionManager }} deps
+ * @param {{ hlsSessionManager: import("../../../services/hls-session-manager.js").HlsSessionManager, sourceRegistry: object, torrentPool: object }} deps
  * @returns {Promise<void>}
  */
 
@@ -25,7 +25,41 @@ function getPayload(body) {
   return {};
 }
 
-export async function handleApiTranscodeSessionsPost(req, reply, { hlsSessionManager }) {
+/**
+ * Claim the source's file so the pool cannot clean it up under a live session.
+ *
+ * Asynchronous underneath — the torrent lives on another thread — but the
+ * caller needs a release function immediately, so the claim is chased and the
+ * release waits for it.
+ *
+ * @param {{ sourceRegistry: object, torrentPool: object, sourceKey: string, fileIndex: number }} params
+ * @returns {() => void}
+ */
+function holdSource({ sourceRegistry, torrentPool, sourceKey, fileIndex }) {
+  let release = null;
+  let releasedEarly = false;
+  const record = sourceRegistry?.get?.(sourceKey);
+  if (!record) {
+    return () => {};
+  }
+  void Promise.resolve(torrentPool.getTorrent(record.sourceType, record.source))
+    .then((torrent) => {
+      release = torrentPool.acquireFile(torrent, fileIndex);
+      if (releasedEarly) {
+        release();
+      }
+    })
+    .catch(() => {});
+  return () => {
+    releasedEarly = true;
+    if (typeof release === "function") {
+      release();
+      release = null;
+    }
+  };
+}
+
+export async function handleApiTranscodeSessionsPost(req, reply, { hlsSessionManager, sourceRegistry, torrentPool }) {
   const payload = getPayload(req.body);
   const sourceKey = typeof payload.sourceKey === "string" ? payload.sourceKey.trim() : "";
   const fileIndex = Number(payload.fileIndex);
@@ -68,7 +102,12 @@ export async function handleApiTranscodeSessionsPost(req, reply, { hlsSessionMan
           : 0,
       audioTrackIndex:
         Number.isInteger(audioTrackIndex) && audioTrackIndex > 0 ? audioTrackIndex : 0,
-      segmentFormatId
+      segmentFormatId,
+      // Hold the torrent for as long as this session lives. Reads take a claim
+      // only while they run, and a seek leaves a gap with no read at all — the
+      // disk sweep caught that gap on 2026-08-06 and deleted the film being
+      // watched.
+      acquireSource: () => holdSource({ sourceRegistry, torrentPool, sourceKey, fileIndex })
     });
     return reply.send({
       sessionId: session.id,

package/server.js

@@ -198,7 +198,7 @@ export async function startProxyServer({ host, port, transcodeAudio, ffmpegBin,
     handleStreamGet(req, reply, { sourceRegistry, torrentPool })
   );
   app.post("/api/transcode-sessions", async (req, reply) =>
-    handleApiTranscodeSessionsPost(req, reply, { hlsSessionManager })
+    handleApiTranscodeSessionsPost(req, reply, { hlsSessionManager, sourceRegistry, torrentPool })
   );
   app.post("/api/transcode-sessions/:sessionId/release", async (req, reply) =>
     handleApiTranscodeSessionReleasePost(req, reply, { hlsSessionManager })

package/services/hls-session-manager.js

@@ -36,6 +36,33 @@ import {
 } from "./ffmpeg-banner.js";
 import { resolveSegmentFormat, SEGMENT_FORMAT_IDS } from "./segment-formats/index.js";
 
+/**
+ * Whether an encoder run died because its INPUT went away, rather than because
+ * of anything about the encode itself.
+ *
+ * These are the messages the read path and ffmpeg's HTTP client produce when
+ * the torrent is gone, being re-added, or has no data for the range yet — all
+ * of them temporary by nature: the source can be added again and the pieces
+ * fetched again.
+ *
+ * @param {string} message
+ * @returns {boolean}
+ */
+export function isInputUnavailable(message) {
+  const text = typeof message === "string" ? message : "";
+  return (
+    /Error reading HTTP response/i.test(text) ||
+    /not found in (?:magnet|torrent):/i.test(text) ||
+    /Unknown source/i.test(text) ||
+    /is gone and cannot be re-added/i.test(text) ||
+    /Read error at pos/i.test(text) ||
+    /Server returned 5\d\d/i.test(text) ||
+    /Input\/output error/i.test(text) ||
+    /Connection reset by peer/i.test(text) ||
+    /End of file/i.test(text)
+  );
+}
+
 const PLAYLIST_FILE_NAME = "index.m3u8";
 const CLEANUP_INTERVAL_MS = 30_000;
 const DEFAULT_SEGMENT_DURATION_SEC = 4;
@@ -130,6 +157,13 @@ const SEEK_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_SEEK_FAILURES = 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
@@ -935,7 +969,12 @@ export class HlsSessionManager {
     startPositionSeconds = 0,
     audioTrackIndex = 0,
     manualQuality = false,
-    segmentFormatId = ""
+    segmentFormatId = "",
+    // Called once for a session that is actually created, and expected to
+    // return a function that lets the source go. It is what keeps the torrent's
+    // data alive for as long as a viewer has a session on it — see
+    // disposeSession.
+    acquireSource = null
   }) {
     if (!this.enabled) {
       const error = new Error("Audio transcoding is disabled on this proxy.");
@@ -1318,6 +1357,13 @@ export class HlsSessionManager {
         lastLoggedAt: 0
       }
     };
+    if (typeof acquireSource === "function") {
+      try {
+        session.releaseSource = acquireSource();
+      } catch {
+        session.releaseSource = null;
+      }
+    }
     this.sessionsById.set(sessionId, session);
     this.sessionIdBySource.set(sourceMapKey, sessionId);
 
@@ -1780,10 +1826,31 @@ export class HlsSessionManager {
     if (!session || session.state === "disposed" || !session.ffmpeg) {
       return;
     }
-    const encodedTo = Number(session.progress?.processedSeconds);
+    // How far the encoder has got, measured by what EXISTS. ffmpeg's own
+    // report of its timeline position is not evidence: field 2026-08-06, it
+    // claimed 6012 s at `speed=1.18e+03x` on a file that was one percent
+    // downloaded and had produced exactly one segment. The limiter believed it,
+    // suspended the encoder twelve seconds into the session, and segment #1 —
+    // which nobody was now making — was held for 45.7 s until the viewer gave
+    // up and seeked. A segment on disk is something the viewer can be served;
+    // a number from ffmpeg is not.
+    const producedThrough = this.#latestProducedSegment(session);
+    if (producedThrough === null) {
+      return;
+    }
+    const encodedTo = this.#segmentStartTime(session, producedThrough + 1);
     if (!Number.isFinite(encodedTo)) {
       return;
     }
+    // Worth knowing when the two disagree wildly — it is the only trace of
+    // whatever made ffmpeg report a position it had not reached.
+    const claimed = Number(session.progress?.processedSeconds);
+    if (Number.isFinite(claimed) && Math.abs(claimed - encodedTo) > LOOKAHEAD_PAUSE_SECONDS) {
+      logger.info(
+        `transcode ${session.id} ffmpeg claims ${Math.round(claimed)}s processed ` +
+          `but has produced through ${Math.round(encodedTo)}s (segment #${producedThrough})`
+      );
+    }
     // Where the viewer is. Before the first segment request, the position the
     // run started at — so a session nobody has read from yet is bounded too.
     const viewerAt = Number.isInteger(session.lastRequestedSegment)
@@ -2473,6 +2540,45 @@ export class HlsSessionManager {
         session.seekFailureTarget = -1;
         session.seekFailureCount = 0;
       }
+      // Losing the INPUT is not the session failing — it is the data not being
+      // there YET. The torrent can be re-added and re-downloaded, so the
+      // honest answer to the viewer is "still working", not an error screen.
+      // Field 2026-08-06: a torrent evicted mid-seek took the film with it, the
+      // run died on `File 0 not found`, the session went terminal and answered
+      // 500 to every request from then on — although the swarm was there and
+      // the data would have come back in seconds. The circuit breaker below
+      // stays for what it was built for, a target that genuinely cannot be
+      // encoded; it must not condemn a session whose data merely went away.
+      if (isInputUnavailable(session.lastError)) {
+        session.state = "recovering";
+        // On the wire it is simply "not ready yet" — a state the browser has
+        // always known how to wait through. Only the proxy needs the
+        // distinction between waiting for data and having given up.
+        session.progress.state = "starting";
+        session.progress.updatedAt = Date.now();
+        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} ${session.runLabel ?? "run#?"} lost its input ` +
+            `(${session.lastError}); retrying in ${Math.round(delayMs / 1000)}s ` +
+            `(attempt ${session.inputRetryCount})`
+        );
+        session.inputRetryTimer = setTimeout(() => {
+          session.inputRetryTimer = null;
+          if (session.state !== "recovering") {
+            return;
+          }
+          const at = Number.isInteger(session.lastRequestedSegment)
+            ? session.lastRequestedSegment
+            : (session.encodeStartIndex ?? 0);
+          this.#startEncodeRun(session, at).catch(() => {});
+        }, delayMs);
+        session.inputRetryTimer.unref?.();
+        return;
+      }
       session.state = "failed";
       session.progress.state = "failed";
       session.progress.updatedAt = Date.now();
@@ -2916,6 +3022,12 @@ export class HlsSessionManager {
     if (!session || !isSafeFileName(fileName, session.segmentFormat)) {
       return { kind: "not-found" };
     }
+    if (session.state === "recovering") {
+      // The data went away and is being fetched again. Holding the request is
+      // the truthful answer: nothing is broken and there is nothing for the
+      // viewer to retry.
+      return { kind: "warming-up" };
+    }
     if (session.state === "failed") {
       return {
         kind: "failed",
@@ -3031,6 +3143,9 @@ export class HlsSessionManager {
       // — the time from session-create entry to a playable first segment.
       if (!isPlaylist && !session.firstSegmentLogged) {
         session.firstSegmentLogged = true;
+        // Data is flowing again, so the next loss starts its backoff afresh
+        // rather than inheriting the delay of the last one.
+        session.inputRetryCount = 0;
         this.#rememberFirstSegmentLatency(Date.now() - session.createEntryMs);
         logger.info(
           `cold-start ${sessionId.slice(0, 8)}: first-segment ready +${Date.now() - session.createEntryMs}ms`
@@ -3206,12 +3321,33 @@ export class HlsSessionManager {
     this.sessionsById.delete(sessionId);
     this.sessionIdBySource.delete(session.sourceMapKey);
 
+    // Let go of the source. While a session exists its torrent must survive
+    // both cleanups the pool runs, and until now neither knew about it: the
+    // only claim on a file is taken by a READ, and during a seek there is no
+    // read at all — the old encoder is dead and the new one has not started.
+    // Field 2026-08-06, that window met the thirty-second disk sweep and the
+    // film being watched was evicted mid-seek, six gigabytes deleted, after
+    // which the new encoder had nothing to read. The session's own thirty
+    // minutes governed the session, never the data under it.
+    if (typeof session.releaseSource === "function") {
+      try {
+        session.releaseSource();
+      } catch {
+        // Best effort — a session must always finish being disposed.
+      }
+      session.releaseSource = null;
+    }
+
     // Clear any pending seek-settle timer so it cannot fire and restart a
     // disposed session.
     if (session.seekSettleTimer) {
       clearTimeout(session.seekSettleTimer);
       session.seekSettleTimer = null;
     }
+    if (session.inputRetryTimer) {
+      clearTimeout(session.inputRetryTimer);
+      session.inputRetryTimer = null;
+    }
 
     this.#resumeEncoder(session, "session disposed");
     if (session.ffmpeg && !session.ffmpeg.killed) {

package/test/input-unavailable.test.js

@@ -0,0 +1,48 @@
+/**
+ * @file Telling "the data is not here yet" from "this cannot be encoded".
+ *
+ * A run that dies because its input went away used to condemn the whole
+ * session: state `failed`, and every request for the playlist answered 500
+ * from then on. But the torrent can be added again and the pieces downloaded
+ * again, so the data being gone is a wait, not a verdict — measured 2026-08-06,
+ * a torrent evicted mid-seek killed a session whose swarm was right there and
+ * whose data would have come back in seconds.
+ *
+ * The classification is what decides which of the two happened, so it is tested
+ * on the exact messages the field produced.
+ */
+
+import test from "node:test";
+import assert from "node:assert/strict";
+import { isInputUnavailable } from "../services/hls-session-manager.js";
+
+test("the messages the field produced when data went away are all temporary", () => {
+  for (const message of [
+    "[http @ 0x7f99b19f00] Error reading HTTP response: End of file",
+    "File 0 not found in torrent:17c46f5c36b94865858bfeaa412693c097328a50.",
+    "File 5 not found in magnet:8d3b6c2e74df473e3649521f927ae33b20cd9e67.",
+    "Unknown source 9711bbde2debdcd0d1fbd8cf88d68fd9612e5d31.",
+    "[in#0/matroska,webm @ 0x7f9005f340] Read error at pos. 138556 (0x21d3c)",
+    "Server returned 503 Service Unavailable",
+    "Input/output error"
+  ]) {
+    assert.equal(isInputUnavailable(message), true, `should be retried: ${message}`);
+  }
+});
+
+test("a real encoding failure is not mistaken for one", () => {
+  for (const message of [
+    "Cannot write moov atom before AC3 packets. Set the delay_moov flag to fix this.",
+    "Could not write header (incorrect codec parameters ?): Invalid argument",
+    "Unknown encoder 'h264_v4l2m2m'",
+    "ffmpeg exited with code 1"
+  ]) {
+    assert.equal(isInputUnavailable(message), false, `should stay terminal: ${message}`);
+  }
+});
+
+test("nothing at all is not a reason to retry for ever", () => {
+  assert.equal(isInputUnavailable(""), false);
+  assert.equal(isInputUnavailable(undefined), false);
+  assert.equal(isInputUnavailable(null), false);
+});