@torrent-tv/proxy 2.9.112 → 2.9.114

package/CHANGELOG.md

@@ -1,3 +1,12 @@
+## 2.9.114
+
+- **Fix**: A seek leaked a pinned piece, and enough of them destroyed the torrent. A piece is pinned before its fragment is handed to the reader and released by whoever received it — but a consumer that ABANDONS the read never gets the chance, and a seek abandons it every time: the encoder is killed, the response is torn down, the loop is left between two fragments. Field 2026-08-06, one seek was enough: the store answered `Every resident piece is pinned; no slot can be freed`, and it answered it to the WebTorrent client, which closed the store and destroyed the torrent — after which every read failed with `File 0 not found`, the session went terminal, and the segment the viewer was waiting for returned an instant error. The pin of a fragment still in the consumer's hands is now dropped by the reader itself on every exit, abandonment included. Covered by a test that abandons a read mid-fragment and checks the store has nothing pinned.
+- **Chore**: The look-ahead's report that ffmpeg's position and the segments on disk disagree is limited to once a minute. It is a diagnostic, not an event, and it printed three hundred times a minute after a seek — for as long as a fresh run had not caught up with the segments an older one left behind.
+
+## 2.9.113
+
+- **New**: The transport's own counters are written to the log for as long as a channel is open, not only when its send queue backs up. The queue was the wrong thing to watch: field 2026-08-06, a 9.26 MB segment was accepted by the transport with `maxBuffered=0 bufferedAtEnd=0` and reported as sent at 274 Mbit/s, and it never arrived — after which everything the proxy sent vanished the same way while requests kept arriving in the other direction. With nothing ever queued the existing watcher never woke, so the one question that decides the cause — did those bytes leave the machine — had no answer in the log. Every five seconds it now records bytes sent and received by the transport itself, the queue depth, the round-trip time, and the path in use. The browser records the matching figures on the same cadence (server 0.8.110), so a recurrence is settled by subtracting one line from the other rather than by reasoning.
+
 ## 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.

package/package.json

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

package/services/data-channel-handler.js

@@ -107,8 +107,42 @@ function makeSendQueueWatcher({ log, getTransportSnapshot }) {
     let lowestSinceDrain = Number.POSITIVE_INFINITY;
     let stuckSince = 0;
     let previous = null;
+    // Independent of the queue: the transport's own counters, sampled for as
+    // long as the channel is open. The queue was the wrong thing to watch —
+    // field 2026-08-06, a 9.26 MB segment was accepted by the transport with
+    // `maxBuffered=0 bufferedAtEnd=0`, reported as sent at 274 Mbit/s, and
+    // never arrived; everything the proxy sent from that moment on was lost the
+    // same way while requests kept coming the other direction. With nothing
+    // queued this watcher never woke, so the one question that matters — did
+    // those bytes leave the machine — has no answer in the log. It does now.
+    let heartbeatPrevious = null;
+    let heartbeatAt = 0;
 
     const timer = setInterval(() => {
+      const sampledAt = Date.now();
+      if (sampledAt - heartbeatAt >= TRANSPORT_HEARTBEAT_MS) {
+        heartbeatAt = sampledAt;
+        const snapshot = getTransportSnapshot?.(sessionId) ?? null;
+        if (snapshot) {
+          const sent = heartbeatPrevious ? snapshot.bytesSent - heartbeatPrevious.bytesSent : null;
+          const received = heartbeatPrevious
+            ? snapshot.bytesReceived - heartbeatPrevious.bytesReceived
+            : null;
+          heartbeatPrevious = snapshot;
+          let depth = 0;
+          try {
+            depth = typeof channel.bufferedAmount === "function" ? channel.bufferedAmount() : 0;
+          } catch {
+            depth = -1;
+          }
+          log(
+            `[dc-transport] ${tag} "${label}" sent=${snapshot.bytesSent}` +
+            `${sent === null ? "" : ` (+${sent})`} received=${snapshot.bytesReceived}` +
+            `${received === null ? "" : ` (+${received})`} queued=${depth}B ` +
+            `rtt=${snapshot.rtt}ms pc=${snapshot.state} ice=${snapshot.iceState} pair=${snapshot.pair}`
+          );
+        }
+      }
       let queued = 0;
       try {
         queued = typeof channel.bufferedAmount === "function" ? channel.bufferedAmount() : 0;
@@ -630,6 +664,10 @@ const PARTIAL_REQUEST_TTL_MS = 60_000;
 // well under a second on the LAN — and short enough that a stuck channel is
 // named while the viewer is still looking at it.
 const SEND_QUEUE_SAMPLE_MS = 1_000;
+// How often the transport's own counters are written to the log, whatever the
+// send queue is doing. Frequent enough to place a loss within a few seconds,
+// sparse enough that a two-hour film costs a few hundred lines.
+const TRANSPORT_HEARTBEAT_MS = 5_000;
 const SEND_QUEUE_STUCK_MS = 5_000;
 const DC_BUFFER_HIGH_WATER = 8 * 1024 * 1024;
 /** Resume sending once the channel buffer drains to this many bytes. */

package/services/hls-session-manager.js

@@ -162,6 +162,9 @@ const MAX_SEEK_FAILURES = 3;
 // 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.
+// How often the look-ahead may report that ffmpeg's position and the segments
+// on disk disagree. It is a diagnostic, not an event.
+const LOOKAHEAD_DISAGREEMENT_LOG_MS = 60_000;
 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
@@ -1845,7 +1848,17 @@ export class HlsSessionManager {
     // 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) {
+    // Once a minute at most. The check runs on every segment request, and the
+    // two figures disagree for as long as a fresh run has not caught up with
+    // the segments an older one left on disk — which printed this line three
+    // hundred times a minute after one seek.
+    const now = Date.now();
+    if (
+      Number.isFinite(claimed) &&
+      Math.abs(claimed - encodedTo) > LOOKAHEAD_PAUSE_SECONDS &&
+      now - (session.lookAheadDisagreementLoggedAt ?? 0) > LOOKAHEAD_DISAGREEMENT_LOG_MS
+    ) {
+      session.lookAheadDisagreementLoggedAt = now;
       logger.info(
         `transcode ${session.id} ffmpeg claims ${Math.round(claimed)}s processed ` +
           `but has produced through ${Math.round(encodedTo)}s (segment #${producedThrough})`

package/services/torrent-worker/piece-reader.js

@@ -315,6 +315,13 @@ export async function* readFragments({
   let window = null;
   /** @type {{ from: number, to: number } | null} */
   let criticalMark = null;
+  /**
+   * Drops the pin of the fragment currently in the consumer's hands, if it
+   * still holds one. See where it is assigned.
+   *
+   * @type {(() => void) | null}
+   */
+  let releaseHeldPin = null;
   /**
    * The rest of the file, claimed at the lowest priority so it is fetched with
    * whatever capacity the near window does not need. Null whenever it must not
@@ -507,6 +514,21 @@ export async function* readFragments({
       }
 
       let releasedThisPiece = false;
+      // Remembered so the generator can drop it itself. The pin is taken here
+      // and the consumer is expected to release it — but a consumer that
+      // ABANDONS the iterator never gets the chance, and a seek abandons it
+      // every time: the encoder is killed, the response is torn down, and the
+      // loop is left between two fragments. Field 2026-08-06: after one seek
+      // every slot in the store was pinned, the store answered
+      // `Every resident piece is pinned; no slot can be freed` — to the
+      // WebTorrent client, which closed the store and destroyed the torrent —
+      // and the session died with `File 0 not found`.
+      releaseHeldPin = () => {
+        if (!releasedThisPiece) {
+          releasedThisPiece = true;
+          store.unpin(pieceIndex);
+        }
+      };
       yield {
         pieceIndex,
         offset: located.offset + fromWithinPiece,
@@ -519,8 +541,17 @@ export async function* readFragments({
           store.unpin(pieceIndex);
         }
       };
+      // Handed back, and released by the consumer or not at all — either way
+      // this reader no longer owes anything for it.
+      releaseHeldPin = null;
     }
   } finally {
+    // A fragment handed out and never released is a slot lost for the life of
+    // the process. Reached on every exit, including the consumer walking away.
+    if (releaseHeldPin) {
+      releaseHeldPin();
+      releaseHeldPin = null;
+    }
     // Reached on completion, on cancellation, on a throw, and when the consumer
     // stops iterating — a window left behind would keep the swarm fetching for
     // a reader that no longer exists.

package/test/read-window.test.js

@@ -245,3 +245,34 @@ test("criticality marks the window being waited for, not the whole range", async
     await fs.rm(directory, { recursive: true, force: true });
   }
 });
+
+test("a reader that is abandoned mid-fragment does not keep the piece pinned", async () => {
+  // The pin is taken before the fragment is handed out and released by the
+  // consumer — but a seek abandons the iterator between two fragments, and the
+  // consumer never gets the chance. Field 2026-08-06: after one seek every slot
+  // in the store was pinned, the store answered `Every resident piece is
+  // pinned; no slot can be freed` to the WebTorrent client, which closed the
+  // store and destroyed the torrent.
+  const { torrent, store, directory } = await recordingTorrent({ pieceCount: 40 });
+  try {
+    const iterator = readFragments({
+      torrent,
+      fileIndex: 0,
+      start: 0,
+      end: 40 * PIECE - 1,
+      cancellation: { isCancelled: () => false },
+      windowBytes: WINDOW_PIECES * PIECE
+    });
+    await iterator.next(); // held, deliberately NOT released
+    await iterator.return(); // what a seek does
+
+    assert.equal(
+      store.stats().pinned,
+      0,
+      "the abandoned fragment's piece is still pinned; slots leak one per seek"
+    );
+  } finally {
+    store.destroy(() => undefined);
+    await fs.rm(directory, { recursive: true, force: true });
+  }
+});