@torrent-tv/proxy 2.9.96 → 2.9.98

package/CHANGELOG.md

@@ -1,3 +1,13 @@
+## 2.9.98
+
+- **Fix**: The upload is no longer raised at moments when nobody wants a byte. A torrent with no reader was counted as starving whenever its download read low — which it always does while the encoder is held back for running ahead of the viewer. Measured: four cycles of 512 KB/s and back in three minutes, each reported as `earn unchoke … down=0KB/s`. Starvation now requires somebody to be waiting.
+- **Fix**: A session start no longer looks like a burst of seeks. The codec probe and the keyframe index read through the same route as the encoder and visit the first bytes and the last ones, which from byte offsets alone is indistinguishable from a viewer dragging the slider — two spurious "the viewer moved" per start, and more on every encoder restart. The encoder's input URL now says that it is the read that follows the viewer, and only that read counts.
+- **Chore**: The per-run ffmpeg log line abbreviates the list of cut times to its count and its two ends. There is one cut per segment — 830 on a two-hour film, about 7 KB of log per run — and the list is only ever consulted for whether cutting was explicit, where it starts and how far it reaches.
+
+## 2.9.97
+
+- **Fix**: The generous upload of 2.9.96 did not actually reach the moment it was written for. Only torrents with a registered reader were shown to the upload policy, and the first thing done with a new torrent — fetching the file's head and tail for the codec probe — reads through `createReadStream` without registering one. So for the whole of that wait, 8.36 s of the 11.46 s before playback in the measured session, the torrent looked unused and the upload stayed at the near-silent idle floor, during the exact seconds peers decide whether to serve us. A torrent in a hurry now counts whether or not anything is reading it. The selection is a named function of its own so it can be tested without a live swarm — the fault was in which torrents were considered, not in what was decided about them.
+
 ## 2.9.96
 
 - **New**: The proxy uploads generously at the two moments a viewer is provably waiting — when a torrent is added, and when the viewer seeks — for 25 s, which is two of BitTorrent's unchoke cycles. Peers serve those who serve them: each re-ranks its takers about every 10 s and opens a few slots to whoever uploaded most, plus one at random, so uploading a token 8-50 KB/s means being picked at random, one slot per cycle. Measured on a session where 96 peers were already connected within 2 s: 64 KB/s after 2 s, 1.6 MB/s after 4 s, 4.8 MB/s after 8 s — and the 16 MB the codec probe needs took **8.36 s of the 11.46 s** before playback could start. The existing reciprocity boost could not help, because it waits for the download to be all but dead (below 200 KB/s) with peers visibly choking us, and a ramp is neither: in that same session it first moved the limit 13.3 s after the torrent was added and reached the generous rate at 43.7 s, both after the wait they were meant to shorten. Seeding policy is otherwise unchanged — near-silence when nothing is being watched, a token upload while reading.

package/package.json

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

package/routes/stream/get.js

@@ -144,8 +144,14 @@ export async function handleStreamGet(req, reply, { sourceRegistry, torrentPool
   // 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.
+  // Only the encoder's own input read tracks where the viewer is. Everything
+  // else that comes through here — the codec probe, the keyframe index, a
+  // subtitle fetch — reads the file's edges, and treating those as a viewer
+  // position made every session start and every encoder restart look like a
+  // burst of seeks (measured: two spurious "the viewer moved" per start).
   torrentPool.prioritizeByteRange(torrent, fileIndex, range ? range.start : 0, undefined, {
-    wholeFileRead: range === null
+    wholeFileRead: range === null,
+    isPlaybackRead: req.query.reader === "playback"
   });
 
   const start = range ? range.start : 0;

package/services/hls-session-manager.js

@@ -672,6 +672,33 @@ function computeSegmentBoundaries({ transcodeVideo, durationSeconds, segDur, key
  * @returns {number[] | null} Times relative to the run start, or null when the
  *   boundaries cannot serve (missing, or the index is outside them).
  */
+/**
+ * The ffmpeg command as one readable line.
+ *
+ * Everything is shown as passed except the list of cut times, which is one
+ * value per segment — 830 of them on a two-hour film, about 7 KB of log for a
+ * single run, repeated on every restart. The count and the two ends say
+ * everything the list is ever consulted for: whether cutting was explicit at
+ * all, how far it reaches, and where it starts.
+ *
+ * @param {string[]} args
+ * @returns {string}
+ */
+export function describeFfmpegArgs(args) {
+  const parts = [];
+  for (let index = 0; index < args.length; index += 1) {
+    const value = args[index];
+    if (value === "-segment_times" && typeof args[index + 1] === "string") {
+      const times = args[index + 1].split(",");
+      parts.push(value, `<${times.length} cuts ${times[0]}..${times[times.length - 1]}>`);
+      index += 1;
+      continue;
+    }
+    parts.push(value);
+  }
+  return parts.join(" ");
+}
+
 export function segmentCutTimesFrom(boundaries, startIndex) {
   if (!Array.isArray(boundaries) || boundaries.length < 2) {
     return null;
@@ -999,6 +1026,12 @@ export class HlsSessionManager {
     const readWindowBytes = await this.#readWindowBytesFor(sourceKey, fileIndex, durationSeconds);
     if (readWindowBytes > 0) {
       inputUrl.searchParams.set("windowBytes", String(readWindowBytes));
+      // This read, and only this read, follows the viewer. The codec probe and
+      // the keyframe index also go through `/stream`, and they jump between the
+      // first bytes and the last ones — which is indistinguishable, from byte
+      // offsets alone, from someone dragging the slider. Saying so here is
+      // cheaper and more truthful than guessing from the offsets.
+      inputUrl.searchParams.set("reader", "playback");
     }
     if (!hasDuration) {
       logger.warn(
@@ -2132,7 +2165,7 @@ export class HlsSessionManager {
     // were verified to handle a copied AC-3 track on this very host, so the
     // arguments that run actually received are the missing evidence. One line
     // per run, and a run happens at most every few seconds.
-    logger.info(`transcode ${session.id} ffmpeg ${args.join(" ")}`);
+    logger.info(`transcode ${session.id} ffmpeg ${describeFfmpegArgs(args)}`);
 
     const ffmpeg = spawn(this.ffmpegBin, args, {
       cwd: session.dirPath,

package/services/torrent-pool.js

@@ -115,6 +115,38 @@ const UPLOAD_HURRY_MS = 25_000;
  * @param {{ floor?: number, idleFloor?: number, boost?: number, starvingSpeed?: number, chokedThreshold?: number, now?: number }} [opts]
  * @returns {{ bytesPerSec: number, reason: string }}
  */
+/**
+ * The torrents the upload policy is allowed to see.
+ *
+ * A torrent with a reader qualifies for the obvious reason. A torrent in a
+ * HURRY qualifies even without one, and that case is the important one: the
+ * first thing done with a new torrent is fetching the file's head and tail for
+ * the codec probe, and that read goes straight to `createReadStream` without
+ * registering a reader. Judged by readers alone the torrent looks unused for
+ * the whole of that wait — 8.36 s of the 11.46 s before playback in the session
+ * measured 2026-08-04 — so the upload stayed at the near-silent idle floor
+ * during the exact seconds peers were deciding whether to serve us.
+ *
+ * @param {Iterable<{ hurryUntil?: number }>} torrents
+ * @param {Map<object, { size: number }>} usageByTorrent - fileIndex sets, keyed by torrent.
+ * @param {number} now
+ * @returns {object[]}
+ */
+export function torrentsForUploadPolicy(torrents, usageByTorrent, now) {
+  const chosen = [];
+  for (const torrent of torrents) {
+    const usage = usageByTorrent?.get?.(torrent);
+    const hasReader = Boolean(usage && usage.size > 0);
+    if (hasReader || (torrent?.hurryUntil ?? 0) > now) {
+      // Recorded so the policy can tell "nothing is arriving and somebody is
+      // waiting" from "nothing is arriving because nobody asked".
+      torrent.hasActiveReader = hasReader;
+      chosen.push(torrent);
+    }
+  }
+  return chosen;
+}
+
 export function decideUploadLimit(activeTorrents, opts = {}) {
   const floor = opts.floor ?? UPLOAD_FLOOR_BYTES;
   const idleFloor = opts.idleFloor ?? UPLOAD_IDLE_FLOOR_BYTES;
@@ -148,7 +180,13 @@ export function decideUploadLimit(activeTorrents, opts = {}) {
     // iterate the piece array and throw on webtorrent 3.x when a piece is null
     // (deselected / mid-verify), which would crash this timer every cycle.
     const notDone = torrent?.done !== true;
-    const starving = notDone && downloadSpeed < starvingSpeed;
+    // A torrent nobody is reading is not starving, however still its download
+    // looks. The encoder is held back once it is far enough ahead of the
+    // viewer, and while it is held nothing is requested — measured
+    // 2026-08-04: four cycles of 512 -> 50 KB/s in three minutes, each
+    // reported as `earn unchoke ... down=0KB/s`, all of them raising the
+    // upload at moments when no byte was wanted by anyone.
+    const starving = notDone && torrent?.hasActiveReader !== false && downloadSpeed < starvingSpeed;
     if (starving && chokedInterested >= chokedThreshold) {
       const name = typeof torrent?.name === "string" ? torrent.name : "?";
       return {
@@ -465,10 +503,11 @@ export class TorrentPool {
     if (!this.client || this.client.destroyed || typeof this.client.throttleUpload !== "function") {
       return;
     }
-    const active = [...this.torrents.values()].filter((torrent) => {
-      const usage = this.fileUsageByTorrent.get(torrent);
-      return usage && usage.size > 0;
-    });
+    const active = torrentsForUploadPolicy(
+      this.torrents.values(),
+      this.fileUsageByTorrent,
+      Date.now()
+    );
     const { bytesPerSec, reason } = decideUploadLimit(active);
     if (bytesPerSec === this.#uploadLimit) {
       return;
@@ -1096,9 +1135,11 @@ export class TorrentPool {
    * @param {number} fileIndex
    * @param {number} byteStart - Start offset within the file.
    * @param {number} [windowBytes] - Unused; kept so callers need not change.
-   * @param {{ wholeFileRead?: boolean }} [options] - `wholeFileRead` marks a
-   *   request that carried no byte range, i.e. one that merely opens the file at
-   *   0 rather than asking to read from there. See the guard below.
+   * @param {{ wholeFileRead?: boolean, isPlaybackRead?: boolean }} [options] -
+   *   `wholeFileRead` marks a request that carried no byte range, i.e. one that
+   *   merely opens the file at 0 rather than asking to read from there.
+   *   `isPlaybackRead` marks the encoder's input read, the only one that
+   *   follows the viewer. See the guards below.
    * @returns {void}
    */
   prioritizeByteRange(
@@ -1153,10 +1194,15 @@ export class TorrentPool {
     const isJump =
       previousStart === undefined || Math.abs(safeStart - previousStart) > PRIORITY_WINDOW_BYTES;
     if (isJump) {
-      // A jump is a seek. Whatever the swarm was giving us was for somewhere
-      // else, and the pieces at the new position have to be earned from peers
-      // that are choking us — the same standing start as a fresh torrent.
-      this.#markHurry(torrent, "the viewer moved");
+      // A jump in the read that follows the viewer is a seek. Whatever the
+      // swarm was giving us was for somewhere else, and the pieces at the new
+      // position have to be earned from peers that are choking us — the same
+      // standing start as a fresh torrent. A jump in any OTHER read is the
+      // codec probe or the keyframe index visiting the ends of the file, and
+      // nobody is waiting on those the way a viewer waits on a seek.
+      if (options.isPlaybackRead) {
+        this.#markHurry(torrent, "the viewer moved");
+      }
       const percent = ((safeStart / fileLength) * 100).toFixed(1);
       logger.info(
         `torrent-pool: [${String(torrent.infoHash).slice(0, 8)}] read position -> ` +

package/test/upload-hurry.test.js

@@ -17,7 +17,7 @@
 
 import test from "node:test";
 import assert from "node:assert/strict";
-import { decideUploadLimit } from "../services/torrent-pool.js";
+import { decideUploadLimit, torrentsForUploadPolicy } from "../services/torrent-pool.js";
 
 const NOW = 1_000_000;
 const healthy = (extra = {}) => ({
@@ -64,3 +64,58 @@ test("the reciprocity boost still works when no hurry is on", () => {
   assert.equal(decision.bytesPerSec, 512 * 1024);
   assert.match(decision.reason, /earn unchoke/);
 });
+
+test("a torrent with no reader still reaches the policy while it is in a hurry", () => {
+  // The moment that matters: a torrent has just been added and its head and
+  // tail are being fetched for the codec probe. That read goes straight to
+  // `createReadStream`, so no reader is registered — and the selection only
+  // ever kept torrents that had one, which is where the gap was.
+  const hurrying = { name: "film.mkv", hurryUntil: NOW + 20_000 };
+  const idle = { name: "other.mkv" };
+  const usage = new Map();
+
+  assert.deepEqual(
+    torrentsForUploadPolicy([hurrying, idle], usage, NOW),
+    [hurrying],
+    "a torrent with no reader yet was ignored"
+  );
+
+  assert.deepEqual(
+    torrentsForUploadPolicy([{ ...hurrying, hurryUntil: NOW - 1 }, idle], usage, NOW),
+    [],
+    "and stops counting once the rush is over"
+  );
+
+  const read = { name: "watched.mkv" };
+  usage.set(read, new Set([0]));
+  assert.deepEqual(
+    torrentsForUploadPolicy([read], usage, NOW),
+    [read],
+    "a torrent being read still counts, hurry or not"
+  );
+});
+
+test("a torrent nobody is reading is not treated as starving", () => {
+  // The encoder is suspended once it is far enough ahead, and while it is
+  // suspended nothing is requested — so the download reads zero without anyone
+  // waiting. Measured before this guard: four cycles of 512 -> 50 KB/s in three
+  // minutes, every one of them reported as `earn unchoke ... down=0KB/s`.
+  const idleButChoked = {
+    name: "film.mkv",
+    hasActiveReader: false,
+    wires: [
+      { amInterested: true, peerChoking: true },
+      { amInterested: true, peerChoking: true }
+    ],
+    downloadSpeed: 0,
+    done: false
+  };
+  assert.equal(decideUploadLimit([idleButChoked], { now: NOW }).bytesPerSec, 50 * 1024);
+
+  const waiting = { ...idleButChoked, hasActiveReader: true };
+  assert.equal(
+    decideUploadLimit([waiting], { now: NOW }).bytesPerSec,
+    512 * 1024,
+    "a reader that IS waiting must still earn unchoke slots"
+  );
+});