@torrent-tv/proxy 2.9.9 → 2.9.11

package/CHANGELOG.md

@@ -1,4 +1,12 @@
-## 2.9.8
+## 2.9.11
+
+- **New**: Seek-aware torrent piece prioritization. On every `/stream` range request the proxy now marks the torrent pieces at the read position **critical** (`TorrentPool.prioritizeByteRange` → `torrent.critical`, ~8 MB window). After a seek, ffmpeg opens the input at a new byte offset; previously those pieces waited behind the sequential download backlog, so seeking into an undownloaded region stalled ~15-18 s while the proxy fetched data. Now the seek position jumps the download queue.
+
+## 2.9.10
+
+- **Fix**: Raised the adaptive-preset speed margin (`PRESET_SPEED_MARGIN` 1.3 → 1.8). The preset benchmark runs at startup with an idle CPU, but during playback ffmpeg competes with in-process WebTorrent (download + SHA1 hashing) and delivery, so real throughput is lower than benchmarked. A 1.3× margin picked a preset that ran near/below realtime under load (e.g. `faster` at ~1.3×) and stalled; 1.8× picks a preset with genuine headroom (e.g. `veryfast`), keeping playback above 1× under real load.
+
+## 2.9.9
 
 - **Fix**: Software (libx264) video transcode is much faster on weak ARM hosts, so playback keeps up with realtime: encode uses all CPU cores (`-threads`), and the scaler **never upscales** — the target box is capped to the source size via `min(W,iw)`/`min(H,ih)`, so a small source (e.g. 720x400) is encoded at its own resolution instead of being scaled up to the viewport (far fewer pixels).
 - **New**: Adaptive software preset (preset auto-benchmark). At startup the proxy benchmarks libx264 presets (`fast`→`ultrafast`) on this host and records encode throughput (pixels/sec). Per stream, `hls-session-manager` picks the **highest-quality preset that still encodes the actual (source-capped) output resolution faster than realtime** with a safety margin, falling back to `ultrafast`. This maximises quality without dropping below 1× (which causes stalls). Logged as `video=libx264/<preset>` at session start.

package/package.json

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

package/routes/stream/get.js

@@ -64,6 +64,11 @@ export async function handleStreamGet(req, reply, { sourceRegistry, torrentPool
   const releaseFile = torrentPool.acquireFile(torrent, fileIndex);
 
   const range = parseRange(req.headers.range, file.length);
+  // Prioritize the pieces at this read position so a seek (a request at a new
+  // byte offset) downloads first instead of waiting behind the sequential
+  // backlog — this is what caused ~15-18 s stalls when seeking into an
+  // undownloaded region.
+  torrentPool.prioritizeByteRange(torrent, fileIndex, range ? range.start : 0);
   reply.header("Accept-Ranges", "bytes");
   reply.header("Content-Type", "application/octet-stream");
   reply.header("Content-Disposition", `inline; filename*=UTF-8''${encodeURIComponent(file.name)}`);

package/services/hwaccel.js

@@ -37,8 +37,11 @@ const BENCHMARK_REF_W = 640;
 const BENCHMARK_REF_H = 360;
 const BENCHMARK_DURATION_SEC = 3;
 // Require the encoder to be this much faster than realtime for the target
-// resolution, leaving headroom for complex scenes and delivery.
-const PRESET_SPEED_MARGIN = 1.3;
+// resolution. The benchmark runs at startup with an idle CPU; during playback
+// ffmpeg competes with in-process WebTorrent (download + hashing) and delivery,
+// so real throughput is lower. A generous margin keeps playback above 1× under
+// that real load and absorbs complex scenes.
+const PRESET_SPEED_MARGIN = 1.8;
 
 /**
  * @param {number} targetWidth

package/services/torrent-pool.js

@@ -10,6 +10,11 @@ import crypto from "node:crypto";
 import WebTorrent from "webtorrent";
 import { logger } from "../utils/logger.js";
 
+// Bytes ahead of a read position to mark CRITICAL (download-first) on each
+// range request. Big enough to unstick a seek into an undownloaded region,
+// small enough not to make "everything critical" (which defeats prioritization).
+const PRIORITY_WINDOW_BYTES = 8 * 1024 * 1024;
+
 /**
  * Decode a raw torrent source value into the format expected by WebTorrent.
  *
@@ -318,4 +323,45 @@ export class TorrentPool {
       }
     }
   }
+
+  /**
+   * Mark the torrent pieces covering a byte window of a file as CRITICAL, so
+   * WebTorrent downloads them before the rest of the selected file. Called on
+   * every range request: after a seek, the new read position jumps the download
+   * queue instead of waiting behind the sequential backlog (which caused
+   * ~15-18 s stalls when seeking into an undownloaded region).
+   *
+   * @param {import("webtorrent").Torrent} torrent
+   * @param {number} fileIndex
+   * @param {number} byteStart - Start offset within the file.
+   * @param {number} [windowBytes] - Bytes ahead of `byteStart` to prioritize.
+   * @returns {void}
+   */
+  prioritizeByteRange(torrent, fileIndex, byteStart, windowBytes = PRIORITY_WINDOW_BYTES) {
+    if (!torrent || typeof torrent.critical !== "function" || !Array.isArray(torrent.files)) {
+      return;
+    }
+    const pieceLength = Number(torrent.pieceLength);
+    if (!Number.isFinite(pieceLength) || pieceLength <= 0) {
+      return;
+    }
+    const file = torrent.files[fileIndex];
+    if (!file) {
+      return;
+    }
+    const fileOffset = Number.isFinite(file.offset) ? file.offset : 0;
+    const safeStart = Math.max(0, Number(byteStart) || 0);
+    const absStart = fileOffset + safeStart;
+    const absEnd = Math.min(fileOffset + file.length - 1, absStart + Math.max(1, windowBytes) - 1);
+    const startPiece = Math.floor(absStart / pieceLength);
+    const endPiece = Math.floor(absEnd / pieceLength);
+    if (endPiece < startPiece) {
+      return;
+    }
+    try {
+      torrent.critical(startPiece, endPiece);
+    } catch {
+      // Best effort — never break streaming because prioritization failed.
+    }
+  }
 }