@torrent-tv/proxy 2.24.1 → 2.25.0

package/CHANGELOG.md

@@ -1,3 +1,8 @@
+## 2.25.0
+
+- **Fix**: Picture and sound drifted apart after a seek, by exactly the amount the grid had been corrected. 2.24.1 made every segment stamp itself against the playlist its own session published — but each session froze that playlist at its own creation, and a soundtrack or a quality step is created later than the picture it accompanies, so it froze a table that had since been corrected. Two members of one family then stated the same moment differently, and the corrections measured on the field file are 0.6-2.9 s. A family now publishes ONE timeline: a session created inside a family takes its base's published table verbatim and writes its own playlist from it, while the live table goes on being corrected for cutting, which is what keeps a re-encoded step aligned with the copy it joins.
+- **New**: The read window grows into a lead instead of staying a fixed length. Every wait that cost time widens it by a piece; every piece already in hand gives one back, down to the size the caller sized from the file's own byte rate. The ceiling is this reader's share of the store's memory, so widening can never ask for more than the store can hold. Measured 2026-08-17, the swarm delivered 5.1-5.9 MB/s against a film consumed at about 1 MB/s while the reader still blocked 47 times in two minutes — a fivefold surplus that never became distance ahead of the head.
+
 ## 2.24.1
 
 - **Fix**: Seeking could leave a film dead. After a seek the encoder restarts at the segment before the target, and every segment it then produces states its own position, read out of the piece. On a file whose container index is wrong those positions disagree with the playlist the player is holding — measured 2026-08-17, a seek to 1590.4 s produced audio segments #292 and #293 carrying 1587.892 s and 1592.692 s against a playlist saying 1585.376 s and 1590.585 s. A fragment landing further from where the playlist put it than a player will bridge (hls.js bridges `maxBufferHole`, 0.5 s by default) is not recognised as buffered, so the browser asks for it again: those two segments were fetched **1908 times each over ten minutes**, every one served in 4 ms, with the picture frozen and nothing in either log saying why. A segment is now stamped where the playlist the player holds says it begins, whenever the piece's own figure is further away than that; within it the piece's own figure is kept, which is what keeps speech and subtitles together on a file whose index is slightly out. The boundary table goes on being corrected from produced segments — that is what lets a re-encoded step be cut like the copy it joins — but the correction no longer moves segments under a player holding the original playlist: the published table is frozen when the playlist text is written from it. Pinned by `test/published-timeline.test.js` with the field figures.

package/package.json

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

package/services/hls-session-manager.js

@@ -1741,6 +1741,14 @@ export class HlsSessionManager {
           })
         : []);
     const usingKeyframeBoundaries = useKeyframeGrid;
+    // What this session will PUBLISH. A member of a family takes its base's
+    // published table verbatim; a session with no base publishes what it cuts
+    // at. The two differ exactly by the corrections made since the family's
+    // first playlist was written, and that difference is what must never reach
+    // the player as two different timelines.
+    const publishedGrid = Array.isArray(inheritedGrid?.published) && inheritedGrid.published.length > 1
+      ? inheritedGrid.published
+      : (hasDuration ? [...segmentBoundaries] : null);
     const segmentCount = segmentBoundaries.length > 1 ? segmentBoundaries.length - 1 : 0;
 
     // Realtime budget (software encoder): pick the output resolution + libx264
@@ -1908,13 +1916,18 @@ export class HlsSessionManager {
       // spliced into the copy (roadmap item 28).
       containerFormat,
       indexCheck: newIndexCheck(),
-      playlistText: hasDuration ? this.#buildVodPlaylist(segmentBoundaries, segmentFormat) : "",
-      // The table AS PUBLISHED, frozen the moment the playlist text is written
-      // from it. `segmentBoundaries` keeps being corrected from produced
-      // segments — that is what makes a re-encoded rung cut like the copy it
-      // joins — but the player's own copy of the timeline never changes, and a
-      // segment must be stamped against the copy the player has.
-      publishedBoundaries: hasDuration ? [...segmentBoundaries] : null,
+      playlistText: hasDuration ? this.#buildVodPlaylist(publishedGrid, segmentFormat) : "",
+      // The table AS PUBLISHED — what every playlist of this family states, and
+      // what every segment of it is stamped against. Inherited whole from the
+      // base when there is one, so a rung or a soundtrack created later
+      // publishes the same timeline as the picture it plays with; only a family
+      // with no base freezes a copy of its own.
+      //
+      // `segmentBoundaries` keeps being corrected from produced segments — that
+      // is what makes a re-encoded rung cut like the copy it joins — and those
+      // corrections deliberately do NOT reach this copy: the player's timeline
+      // was sent once and cannot be revised.
+      publishedBoundaries: publishedGrid,
       // Segment index the current ffmpeg run started producing from.
       encodeStartIndex: 0,
       // Guards against repeatedly restarting to the same seek position.
@@ -6134,8 +6147,14 @@ export class HlsSessionManager {
       inheritedGrid: base.cutGrid === "keyframe"
         ? {
             // The table as it stands NOW, corrections included — not the index
-            // it was first built from.
+            // it was first built from. This is what the new session CUTS at.
             boundaries: base.segmentBoundaries,
+            // And this is what it must SAY, which is not the same thing: every
+            // member of a family has to publish one timeline, or two sessions
+            // stamp the same moment differently and the picture and the sound
+            // drift apart by exactly the corrections made between their two
+            // creations (field 2026-08-17, corrections of 0.6-2.9 s).
+            published: base.publishedBoundaries,
             keyframeTimes: base.keyframeTimes,
             containerFormat: base.containerFormat
           }
@@ -6670,6 +6689,7 @@ export class HlsSessionManager {
       inheritedGrid: base.cutGrid === "keyframe"
         ? {
             boundaries: base.segmentBoundaries,
+            published: base.publishedBoundaries,
             keyframeTimes: base.keyframeTimes,
             containerFormat: base.containerFormat
           }

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

@@ -60,6 +60,37 @@ export function readWindowFor({ pieceIndex, lastPiece, windowPieces }) {
   return { from: pieceIndex, to: Math.min(lastPiece, pieceIndex + span - 1) };
 }
 
+/**
+ * How wide the window should be after a piece that made the reader wait — or
+ * did not.
+ *
+ * The swarm's surplus is what pays for this. Measured 2026-08-17 on the field
+ * torrent: 5.1-5.9 MB/s delivered against a film consumed at about 1 MB/s, and
+ * the reader still blocked 47 times in two minutes, median 1.5 s, worst 4.5 s.
+ * A fivefold surplus never became distance ahead of the head, because the
+ * window is a fixed number of seconds of playback and everything past it is
+ * ordinary background fill at no priority.
+ *
+ * So the window follows the evidence: every wait that mattered widens it by a
+ * piece, every piece that was already there narrows it back toward the size the
+ * caller asked for. Nothing here is chosen — the wait is measured, the
+ * threshold is the one that already defines "a wait worth recording", and the
+ * ceiling is this reader's share of the store's memory, so widening can never
+ * cost more than the store can hold.
+ *
+ * @param {{ current: number, base: number, ceiling: number, waitedMs: number, waitThresholdMs: number }} params
+ * @returns {number}
+ */
+export function nextWindowPieces({ current, base, ceiling, waitedMs, waitThresholdMs }) {
+  const floor = Math.max(1, Math.floor(base));
+  const top = Math.max(floor, Math.floor(ceiling));
+  const now = Math.min(top, Math.max(floor, Math.floor(current)));
+  if (waitedMs >= waitThresholdMs) {
+    return Math.min(top, now + 1);
+  }
+  return Math.max(floor, now - 1);
+}
+
 /**
  * Add this reader's window to the download set as a stream selection.
  *
@@ -310,7 +341,26 @@ export async function* readFragments({
   // critical, and never deselected anything — so ffmpeg's opening
   // `bytes 0-<EOF>` left a permanent selection over the entire file, and no
   // later prioritisation could outrank it.
-  const windowPieces = Math.max(1, Math.ceil(Math.max(1, windowBytes) / pieceLength));
+  const basePieces = Math.max(1, Math.ceil(Math.max(1, windowBytes) / pieceLength));
+  // What the window is RIGHT NOW. It starts at what the caller sized in seconds
+  // of playback and grows while the reader keeps being made to wait — see
+  // `nextWindowPieces`.
+  let windowPieces = basePieces;
+  /**
+   * The widest this reader may go: its share of what the store can hold in
+   * memory. Measured rather than chosen — the capacity is the store's own, and
+   * the number of readers is how many windows are declared on it right now.
+   *
+   * @returns {number}
+   */
+  const ceilingPieces = () => {
+    const capacity = Number(store?.capacity);
+    if (!Number.isFinite(capacity) || capacity <= 0) {
+      return basePieces;
+    }
+    const readers = Math.max(1, store.protectedRanges?.().length ?? 1);
+    return Math.max(basePieces, Math.floor(capacity / readers));
+  };
   /** @type {{ from: number, to: number } | null} */
   let window = null;
   /** @type {{ from: number, to: number } | null} */
@@ -408,6 +458,20 @@ export async function* readFragments({
       // whether that is the swarm, the picker, or ffmpeg. Logged only when the
       // wait is long enough to matter, so ordinary sequential reading is silent.
       const waitedMs = Date.now() - waitStartedAt;
+      // The window answers to what just happened: a wait means the lead was too
+      // short, an immediate hit means it is longer than it needs to be. Applied
+      // before the logging below so the line reports the window the next piece
+      // will actually use.
+      const widened = nextWindowPieces({
+        current: windowPieces,
+        base: basePieces,
+        ceiling: ceilingPieces(),
+        waitedMs,
+        waitThresholdMs: PIECE_WAIT_LOG_MS
+      });
+      if (widened !== windowPieces) {
+        windowPieces = widened;
+      }
       if (waitedMs >= PIECE_WAIT_LOG_MS) {
         const rateKbps = Math.round(pieceLength / 1024 / (waitedMs / 1000));
         logger.info(

package/test/read-window.test.js

@@ -19,7 +19,11 @@ import { EventEmitter } from "node:events";
 import os from "node:os";
 import path from "node:path";
 import fs from "node:fs/promises";
-import { readFragments, readWindowFor } from "../services/torrent-worker/piece-reader.js";
+import {
+  nextWindowPieces,
+  readFragments,
+  readWindowFor
+} from "../services/torrent-worker/piece-reader.js";
 import { SharedPieceStore } from "../services/piece-store/shared-piece-store.js";
 
 const PIECE = 1024;
@@ -276,3 +280,50 @@ test("a reader that is abandoned mid-fragment does not keep the piece pinned", a
     await fs.rm(directory, { recursive: true, force: true });
   }
 });
+
+// ------------------------------------------ the window that grows into a lead
+
+test("a wait that mattered widens the window by a piece", () => {
+  // Field 2026-08-17: 5.1-5.9 MB/s delivered against ~1 MB/s consumed, and the
+  // reader still blocked 47 times in two minutes. The surplus never became
+  // distance ahead of the head.
+  assert.equal(
+    nextWindowPieces({ current: 4, base: 4, ceiling: 12, waitedMs: 1457, waitThresholdMs: 1000 }),
+    5
+  );
+});
+
+test("a piece that was already there gives a piece back", () => {
+  assert.equal(
+    nextWindowPieces({ current: 7, base: 4, ceiling: 12, waitedMs: 0, waitThresholdMs: 1000 }),
+    6
+  );
+});
+
+test("it never shrinks below what the caller asked for", () => {
+  assert.equal(
+    nextWindowPieces({ current: 4, base: 4, ceiling: 12, waitedMs: 0, waitThresholdMs: 1000 }),
+    4
+  );
+});
+
+test("it never grows past this reader's share of the store", () => {
+  assert.equal(
+    nextWindowPieces({ current: 12, base: 4, ceiling: 12, waitedMs: 4453, waitThresholdMs: 1000 }),
+    12
+  );
+  // A ceiling below the base cannot pull the window under it: the caller sized
+  // the base from the file's own byte rate, and a store too small to hold it is
+  // an argument about memory, not about what the reader needs next.
+  assert.equal(
+    nextWindowPieces({ current: 4, base: 4, ceiling: 1, waitedMs: 2000, waitThresholdMs: 1000 }),
+    4
+  );
+});
+
+test("a wait exactly at the threshold counts as a wait", () => {
+  assert.equal(
+    nextWindowPieces({ current: 4, base: 4, ceiling: 9, waitedMs: 1000, waitThresholdMs: 1000 }),
+    5
+  );
+});