@torrent-tv/proxy 2.9.108 → 2.9.110

package/CHANGELOG.md

@@ -1,3 +1,11 @@
+## 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.
+
 ## 2.9.108
 
 - **New**: A send queue that stops draining now says WHY, instead of leaving the cause to be guessed at. Field 2026-08-06: a channel stayed open, kept accepting requests and delivered nothing for eleven minutes — the queue grew from 214 049 to 239 731 bytes in fourteen seconds and never fell, while the route reported answering in 15 ms and the channel reported itself open. `bufferedAmount` alone cannot distinguish the possible causes; it only proves the bytes are still ours. Each channel is now sampled every second, and once its queue has failed to fall for five seconds the transport itself is asked: bytes sent, bytes received, round-trip time, connection and ICE state, and the candidate pair in use — then again every second, so the trend of each counter is in the log rather than one snapshot. The reading is decided in advance and written beside the code: bytes-sent rising with the queue means packets leave and nothing acknowledges them (the return path is broken); bytes-sent flat with the queue rising means SCTP is not transmitting at all (the peer's receive window is shut, or congestion control has collapsed); bytes-received still rising in either case proves the peer is alive and the failure is one-directional.

package/package.json

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

package/services/hls-session-manager.js

@@ -137,7 +137,17 @@ const MAX_SEEK_FAILURES = 3;
 // look-ahead cap when idle, so a lingering session costs retained segments on
 // disk, not sustained CPU. Active playback refreshes the timer on every segment
 // fetch, so it never expires mid-watch.
-const DEFAULT_SESSION_TTL_MS = 10 * 60 * 1000;
+// How long a session outlives the BROWSER, not the viewing. 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: the tab
+// was killed without releasing, the phone slept, the network dropped. Keeping
+// the session means such a viewer comes back to a warm encoder instead of
+// waiting out a cold start; the cost while nobody is there is disk for the
+// produced segments, since the encoder is suspended and burns no CPU, and that
+// disk is already bounded by the pool's 10 GB cap with eviction. Thirty minutes
+// covers a meal, a phone call or a lift ride.
+const DEFAULT_SESSION_TTL_MS = 30 * 60 * 1000;
 const DEFAULT_STARTUP_WAIT_MS = 5_000;
 // Realtime budget — runtime downswitch (software encoder only). Periodically
 // check each active software-transcode session's ffmpeg `speed`; when it stays

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);
+});