@torrent-tv/proxy 2.9.66 → 2.9.68

package/CHANGELOG.md

@@ -1,3 +1,11 @@
+## 2.9.68
+
+- **Fix**: A seek could be dragged back to the position the viewer had just left. The encoder start was pulled down to the lowest segment the player had outstanding — a stand-in from when the distance to the preceding keyframe was unknown — but at seek time those requests still describe where the player was PLAYING, not where it is going. Field 2026-08-02: a seek to 23:34 (#135) correctly resolved to a start of #134, then got pulled to **#82** (14:15, the position just left) and crawled forward from there. Removed: since boundaries became real keyframes (2.9.65), exactly one segment back always suffices, so the pull has nothing left to correct for.
+
+## 2.9.67
+
+- **Fix**: A seek waited far longer than it needed to — 56 s measured in the field, of which roughly 50 s was self-inflicted. `SEEK_BACKOFF_SEGMENTS` (how far before the requested segment the encoder starts) was **12**, chosen when segments were an invented 4 s apart and the distance to a usable keyframe was unknown. Since 2.9.65 every boundary IS a real keyframe read from the container index, so the single preceding segment is guaranteed to start on one — and with real 10.43 s segments the old value meant encoding **125 s of content** before reaching the viewer position. Lowered to **1**. Observed: the encoder started at #332 for a seek to #344 and the requested segment only arrived 56 s later, while every segment after it was served in ~100 ms.
+
 ## 2.9.66
 
 - **New**: The container keyframe index now covers **MP4/MOV and AVI** as well as Matroska. MP4 reads the sync-sample and time-to-sample tables from `moov` — found by stepping over top-level box headers, so it works whether `moov` sits at the file start or the end, without scanning the gigabytes of `mdat` between them (verified on a 2 GB field file: **1145 keyframes in 625 ms**). AVI reads the trailing `idx1` table, still worth having because older releases are largely XviD-in-AVI and are exactly the files served by copying rather than re-encoding. Formats left out are documented in the module with the reason: MPEG-TS/M2TS carry no index anywhere by design, fragmented MP4 spreads timing across fragments instead of one table, and FLV/ASF have tables but effectively never appear in these releases.

package/package.json

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

package/services/hls-session-manager.js

@@ -72,26 +72,18 @@ const ENCODER_STALL_MS = 12_000;
 // producing nothing.
 // How many segments BEFORE the requested position the encoder starts.
 //
-// Required by how HLS players seek, per Apple's HLS authoring guidance: given a
-// position, the player locates the nearest IDR (keyframe) *preceding* it,
-// decodes from there, and only then presents from the requested point. So it
-// always fetches segments BELOW the target — measured 2026-08-02 on iOS: a seek
-// to #1082 fetched from #1074 (8 back), one to #1358 fetched from #1301 (57
-// back), and in the latter case the player asked for NOTHING at or above the
-// target, so an encoder starting exactly on it produced only files nobody was
-// waiting for and playback hung indefinitely.
+// A player given a position decodes from the nearest keyframe PRECEDING it
+// (Apple HLS authoring guidance), so it fetches segments below the target and
+// an encoder starting exactly on it produces nothing anyone waits for.
 //
-// The observed backoff is not constant, so this is a floor, not the whole
-// answer: #fireSettledSeek also pulls the start down to the lowest segment the
-// player is actually waiting on when that is lower still. Costs a few seconds
-// of extra encoding per seek.
-const SEEK_BACKOFF_SEGMENTS = 12;
-// Hard limit on how far below the requested segment the start may be pulled by
-// `lowestAwaitedIndex`. Without it a stale request from earlier playback drags
-// the encoder across the whole file: field 2026-08-02, a seek to #1354 was
-// pulled to #123 — the start of the previous watch — because requests from
-// before the seek were still counted. Anything deeper than this is not the
-// preceding keyframe, it is a leftover.
+// ONE segment is now enough. Since 2.9.65 every boundary IS a real keyframe
+// (read from the container index), so the segment before the target is
+// guaranteed to start on one. The old value of 12 dates from the invented 4 s
+// grid, where the distance to a usable keyframe was unknown — and it became
+// actively harmful once boundaries turned real: with 10.43 s segments it meant
+// encoding 125 s of content before reaching the viewer's position. Field
+// 2026-08-02: a seek took 56 s, of which ~50 s was this backoff.
+const SEEK_BACKOFF_SEGMENTS = 1;
 const SEEK_PULL_LIMIT_SEGMENTS = 120;
 const SEEK_SETTLE_MS = 1_200;
 // Hard cap on the total settle wait, measured from the first far request of a
@@ -2252,18 +2244,15 @@ export class HlsSessionManager {
       : producedThisRun >= this.segmentDurationSec
         ? `run produced ${producedThisRun.toFixed(1)}s (first segment done)`
         : `grace of ${RUN_FIRST_SEGMENT_GRACE_MS / 1000}s expired`;
-    // The player may be waiting on something below our fixed backoff — its own
-    // requests say exactly how far back it needs the keyframe, so honour that
-    // rather than a guess. Only ever pulls the start EARLIER, never later.
-    const awaited = session.lowestAwaitedIndex;
-    const pullFloor = Math.max(0, target - SEEK_PULL_LIMIT_SEGMENTS);
-    const effectiveTarget = awaited >= pullFloor && awaited < target ? awaited : target;
-    if (effectiveTarget !== target) {
-      logger.info(
-        `transcode ${session.id} pulling encode start #${target} → #${effectiveTarget} ` +
-          `(lowest segment the player is waiting on)`
-      );
-    }
+    // Deliberately NOT pulled towards the lowest segment the player is waiting
+    // on. That was a stand-in for not knowing how far back the preceding
+    // keyframe lay, and it is now both unnecessary and harmful: boundaries are
+    // real keyframes (2.9.65), so exactly one segment back always suffices,
+    // while the player's outstanding requests at seek time still describe where
+    // it was PLAYING, not where it is going. Field 2026-08-02: a seek to #135
+    // was dragged back to #82 — the position the viewer had just left — because
+    // the player was still fetching around it.
+    const effectiveTarget = target;
     session.seekTarget = null;
     session.seekFirstFarAt = 0;
     session.lowestAwaitedIndex = -1;