@torrent-tv/proxy 2.9.67 → 2.9.68

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,3 +1,7 @@
1
+ ## 2.9.68
2
+
3
+ - **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.
4
+
1
5
  ## 2.9.67
2
6
 
3
7
  - **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.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@torrent-tv/proxy",
3
- "version": "2.9.67",
3
+ "version": "2.9.68",
4
4
  "description": "Torrent proxy client that exposes webseed-like HTTP stream endpoint.",
5
5
  "license": "GPL-3.0-or-later",
6
6
  "publishConfig": {
@@ -2244,18 +2244,15 @@ export class HlsSessionManager {
2244
2244
  : producedThisRun >= this.segmentDurationSec
2245
2245
  ? `run produced ${producedThisRun.toFixed(1)}s (first segment done)`
2246
2246
  : `grace of ${RUN_FIRST_SEGMENT_GRACE_MS / 1000}s expired`;
2247
- // The player may be waiting on something below our fixed backoff — its own
2248
- // requests say exactly how far back it needs the keyframe, so honour that
2249
- // rather than a guess. Only ever pulls the start EARLIER, never later.
2250
- const awaited = session.lowestAwaitedIndex;
2251
- const pullFloor = Math.max(0, target - SEEK_PULL_LIMIT_SEGMENTS);
2252
- const effectiveTarget = awaited >= pullFloor && awaited < target ? awaited : target;
2253
- if (effectiveTarget !== target) {
2254
- logger.info(
2255
- `transcode ${session.id} pulling encode start #${target} → #${effectiveTarget} ` +
2256
- `(lowest segment the player is waiting on)`
2257
- );
2258
- }
2247
+ // Deliberately NOT pulled towards the lowest segment the player is waiting
2248
+ // on. That was a stand-in for not knowing how far back the preceding
2249
+ // keyframe lay, and it is now both unnecessary and harmful: boundaries are
2250
+ // real keyframes (2.9.65), so exactly one segment back always suffices,
2251
+ // while the player's outstanding requests at seek time still describe where
2252
+ // it was PLAYING, not where it is going. Field 2026-08-02: a seek to #135
2253
+ // was dragged back to #82 — the position the viewer had just left — because
2254
+ // the player was still fetching around it.
2255
+ const effectiveTarget = target;
2259
2256
  session.seekTarget = null;
2260
2257
  session.seekFirstFarAt = 0;
2261
2258
  session.lowestAwaitedIndex = -1;