@torrent-tv/proxy 2.9.109 → 2.9.111

package/CHANGELOG.md

@@ -1,3 +1,12 @@
+## 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.
+
 ## 2.9.109
 
 - **Chore**: A session now outlives a vanished browser by thirty minutes instead of ten. The number means something different since server 0.8.103: a browser that holds a session re-asserts it every 30 s, so an open tab never consumes this at all — not while paused, not across a three-hour film. What is left is the case where the browser has genuinely gone, and keeping the session means such a viewer returns to a warm encoder rather than a cold start. While nobody is there the encoder is suspended and burns no CPU; the cost is disk for the produced segments, already bounded by the pool's 10 GB cap with eviction. Thirty minutes covers a meal, a phone call or a lift ride.

package/package.json

@@ -1,12 +1,15 @@
 {
   "name": "@torrent-tv/proxy",
-  "version": "2.9.109",
+  "version": "2.9.111",
   "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

@@ -935,7 +935,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 +1323,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 +1792,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)
@@ -3206,6 +3239,23 @@ 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) {

package/services/torrent-worker/handle-state.js

@@ -0,0 +1,23 @@
+/**
+ * @file Whether a torrent handle can still be read from.
+ *
+ * Its own module so it can be tested: importing the worker starts a torrent
+ * client and a piece pool, which a unit test has no business doing.
+ */
+
+/**
+ * Whether a torrent handle can still be read from.
+ *
+ * `destroyed` is WebTorrent's own flag and the earliest signal. The empty file
+ * list is the symptom that actually reaches a reader — it is what produced
+ * `File 0 not found` in the field — and it is also true of a handle whose
+ * metadata has not arrived yet, in which case adding the source again is
+ * equally right: the add de-duplicates and yields the same torrent once it is
+ * ready.
+ *
+ * @param {{ destroyed?: boolean, files?: unknown[] } | null | undefined} torrent
+ * @returns {boolean}
+ */
+export function isUsableTorrentHandle(torrent) {
+  return Boolean(torrent) && torrent.destroyed !== true && (torrent.files?.length ?? 0) > 0;
+}

package/services/torrent-worker/worker.js

@@ -21,6 +21,7 @@
 // before WebTorrent can reach the native one. Two isolates using
 // node-datachannel at once abort the process, and the torrent's wss trackers
 // create peer connections of their own.
+import { isUsableTorrentHandle } from "./handle-state.js";
 import "./install-webrtc-shim.js";
 import { parentPort, workerData } from "node:worker_threads";
 import { createSendStream } from "./channel.js";
@@ -43,6 +44,15 @@ const pool = new TorrentPool({
 
 /** Torrents by sourceKey — the main thread names them, this thread owns them. */
 const torrentsByKey = new Map();
+
+/**
+ * How each source was named when it was added, so a torrent that has since been
+ * destroyed can be added again. Kept separately from {@link torrentsByKey}
+ * because that map holds the promise, not the recipe.
+ *
+ * @type {Map<string, { sourceType: string, source: string }>}
+ */
+const sourceRecipes = new Map();
 /** File claims, each with its own identity — see `file-claims.js`. */
 const fileClaims = createFileClaims();
 /** In-flight reads, so a cancel can stop one mid-body. */
@@ -82,9 +92,36 @@ async function requireTorrent(sourceKey) {
   if (!pending) {
     throw new Error(`Unknown source ${sourceKey}.`);
   }
-  return pending;
+  const torrent = await pending;
+  if (isUsableTorrentHandle(torrent)) {
+    return torrent;
+  }
+  // The pool destroys a torrent that has gone unread for a quarter of an hour,
+  // and under disk pressure. It clears its OWN map when it does; this one it
+  // knows nothing about, so the promise here went on resolving to a corpse: a
+  // destroyed torrent keeps its object but loses its files. Every later session
+  // for that source then failed the same way — the plan and the codec probe
+  // answered from cache in milliseconds, nothing waited for metadata because
+  // everything believed the torrent was known, and ffmpeg's first read died on
+  // `File N not found` 130 ms in, after which the session answered 500 for
+  // ever. Measured 2026-08-06 on two sessions in a row, both from a phone,
+  // which is what made it look like a mobile problem.
+  const recipe = sourceRecipes.get(sourceKey);
+  if (!recipe) {
+    torrentsByKey.delete(sourceKey);
+    throw new Error(`Source ${sourceKey} is gone and cannot be re-added.`);
+  }
+  const revived = pool.getTorrent(recipe.sourceType, recipe.source);
+  torrentsByKey.set(sourceKey, revived);
+  revived.catch(() => {
+    if (torrentsByKey.get(sourceKey) === revived) {
+      torrentsByKey.delete(sourceKey);
+    }
+  });
+  return revived;
 }
 
+
 /**
  * Fragments waiting for the main thread to say it has finished reading them,
  * keyed by request id. One per read, because only one fragment is in flight.
@@ -237,6 +274,10 @@ async function runCommand(command, params, id) {
       // is being added waits for it instead of being told it does not exist.
       // Reusing the same promise for a repeated add also collapses two callers
       // racing to open the same torrent into one.
+      sourceRecipes.set(params.sourceKey, {
+        sourceType: params.sourceType,
+        source: params.source
+      });
       let pending = torrentsByKey.get(params.sourceKey);
       if (!pending) {
         pending = pool.getTorrent(params.sourceType, params.source);
@@ -344,6 +385,7 @@ async function runCommand(command, params, id) {
     case Command.DESTROY_ALL: {
       fileClaims.closeAll();
       torrentsByKey.clear();
+      sourceRecipes.clear();
       await pool.destroyAll();
       return true;
     }

package/test/dead-torrent-handle.test.js

@@ -0,0 +1,52 @@
+/**
+ * @file A torrent that was destroyed must not be handed to a reader.
+ *
+ * The worker 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, not this
+ * one. The promise then went on resolving to a corpse: a destroyed torrent
+ * keeps its object and loses its files.
+ *
+ * What that did to a viewer, measured 2026-08-06 on two sessions in a row: the
+ * plan answered from cache in 23 ms, the session was created from cache in
+ * 2 ms, nothing waited for metadata because everything believed the torrent was
+ * known, and ffmpeg's first read died 130 ms in with `File 0 not found`. Every
+ * request for the playlist then answered 500 until the viewer gave up.
+ *
+ * The rule under test is the whole fix: a handle that cannot be read from is
+ * not returned, it is replaced.
+ */
+
+import test from "node:test";
+import assert from "node:assert/strict";
+import { isUsableTorrentHandle } from "../services/torrent-worker/handle-state.js";
+
+test("a live torrent is usable", () => {
+  assert.equal(isUsableTorrentHandle({ destroyed: false, files: [{ name: "a.mkv" }] }), true);
+});
+
+test("a destroyed torrent is not, even while it still lists files", () => {
+  assert.equal(
+    isUsableTorrentHandle({ destroyed: true, files: [{ name: "a.mkv" }] }),
+    false,
+    "WebTorrent's own flag is the earliest signal that a handle is finished"
+  );
+});
+
+test("a torrent with no files is not — that is what the reader actually hits", () => {
+  assert.equal(
+    isUsableTorrentHandle({ destroyed: false, files: [] }),
+    false,
+    "an empty file list is what produced `File 0 not found` in the field"
+  );
+  assert.equal(
+    isUsableTorrentHandle({ destroyed: false }),
+    false,
+    "and a handle with no file list at all is the same case"
+  );
+});
+
+test("nothing at all is not usable", () => {
+  assert.equal(isUsableTorrentHandle(null), false);
+  assert.equal(isUsableTorrentHandle(undefined), false);
+});