@torrent-tv/proxy 2.9.52 → 2.9.53

package/CHANGELOG.md

@@ -1,3 +1,7 @@
+## 2.9.53
+
+- **Fix**: On the video RE-ENCODE path, `processedSeconds` silently switched reference frame partway through every encode run — absolute (matching `startPositionSeconds`) for the placeholder set at restart, then RELATIVE-to-the-run (counting from ~0) the moment ffmpeg's own `-progress out_time`/`out_time_ms` started overwriting it — because `-output_ts_offset` (used to relabel the MUXED output's timestamps onto the absolute grid) does NOT affect what `-progress` reports; verified empirically (a 5s clip encoded with `-output_ts_offset 100` still reports `out_time` counting 0→5, not 100→105). Every consumer of `session.progress.processedSeconds` assumes it is absolute: `computeProgressMetrics` (percent/remaining), `#applyBudgetDownshift`'s mid-run restart point, and — the field-diagnosed symptom — `#ensureEncodingFor`'s look-ahead window, which anchors on `Math.max(head, segmentIndexForTime(processed))`; with `processed` wrongly near-zero this floor pins the window's advancing edge at the run's OWN start segment for its entire lifetime instead of tracking real progress, so any segment request more than `MAX_LOOKAHEAD_SEGMENTS` (8, ≈32s) past the SEEK TARGET reads as "far" and triggers ANOTHER restart — even while the encoder is happily producing well past that point. Field example (verified with a pure-math replay of the exact logged values): seek to 1824s, window pinned at segments 456–464 for the whole run regardless of real progress reaching segment 465+ within seconds, at 6x realtime. This is the mechanism behind "buffering pill stuck at 0% until playback finally starts" and very likely a contributor to the broader "seek gets stuck" class of reports this cycle. Fixed by rebasing `out_time`/`out_time_ms` onto the absolute timeline (`+ session.progress.startPositionSeconds`) for the re-encode branch only — the copy branch already reports absolute time via `-copyts`, unaffected. Verified: a standalone replay of the field's `processed`/`startPos` sequence through the actual `#segmentIndexForTime` algorithm shows the window frozen at the run's start before the fix, correctly advancing with real progress after.
+
 ## 2.9.52
 
 - **Chore**: `npm audit` fixes. `@fastify/static` 9.1.3 → 10.1.2 (fixes GHSA-83w8-p2f5-377r route-guard path-traversal bypass and GHSA-8pvw-jcv7-9cmj non-canonical-path authorization bypass — no API change to our usage, verified with a live smoke test: healthz, tunnel connect, and static registration all still work). `brace-expansion`/`fast-uri`/`find-my-way` bumped via `npm audit fix` (transitive, no direct dependency change). Residual: `ip` (via `webtorrent@2.8.5` → `torrent-discovery` → `bittorrent-tracker`) stays flagged high (GHSA-2p57-rm9w-gvfp / CVE-2024-29415, SSRF via `isPublic()` misclassification) — investigated and left as an accepted risk, not an oversight: the advisory has no upstream fix (`first_patched_version: null`, every published version of `ip` is flagged) and `npm audit fix --force`'s only offered fix is downgrading `webtorrent` to 0.7.3, which would reintroduce the exact download-freeze regressions 2.9.44 rolled back from 3.x to avoid. The only actual call site in our dependency tree (`bittorrent-tracker/lib/server/parse-udp.js`) uses `ip.toString()` for UDP-integer→string formatting in the tracker-SERVER's request parser — code we never execute (WebTorrent only uses `bittorrent-tracker` as a tracker CLIENT) — and the vulnerable function itself, `isPublic()`, is not called anywhere in the chain. Revisit if/when a maintained `ip` replacement lands upstream in `bittorrent-tracker`.

package/package.json

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

package/services/hls-session-manager.js

@@ -1720,6 +1720,42 @@ export class HlsSessionManager {
     this.#wireEncodeProcess(session, ffmpeg);
   }
 
+  /**
+   * Rebase ffmpeg's `-progress` `out_time`/`out_time_ms` onto the SOURCE
+   * (absolute) timeline, so `session.progress.processedSeconds` is always
+   * comparable to `session.progress.startPositionSeconds` — which
+   * `computeProgressMetrics` and the client's own cushion-percent/ETA math
+   * both assume.
+   *
+   * Branch B (video copy, `-copyts`) already reports `out_time` on the
+   * source's absolute timeline — no rebase needed. Branch A (video re-encode)
+   * does NOT: `-output_ts_offset` (used there to relabel the MUXED output's
+   * timestamps onto the absolute grid) does not affect what `-progress`
+   * reports — verified empirically (a 5s clip encoded with
+   * `-output_ts_offset 100` still reports `out_time` counting 0→5, not
+   * 100→105). Left unrebased, `processedSeconds` jumps from the post-restart
+   * placeholder (`session.progress.startPositionSeconds`, absolute) down to a
+   * near-zero RELATIVE value the moment real ffmpeg progress starts flowing —
+   * `processedSeconds - startPositionSeconds` then goes deeply negative,
+   * clamps to 0, and the client's cushion percent/ETA reads as permanently
+   * stuck at 0% for the whole run even while the encode is actively
+   * producing (field-diagnosed 2026-08-01: a re-encode session logged
+   * `processed=39.5 startPos=1824` at a healthy 6x realtime speed).
+   *
+   * @param {HlsSession} session
+   * @param {number} rawSeconds - As parsed from `out_time`/`out_time_ms`.
+   * @returns {number}
+   */
+  #toAbsoluteProcessedSeconds(session, rawSeconds) {
+    if (!session.transcodeVideo) {
+      return rawSeconds;
+    }
+    const offset = Number.isFinite(session.progress?.startPositionSeconds)
+      ? session.progress.startPositionSeconds
+      : 0;
+    return rawSeconds + offset;
+  }
+
   /**
    * Wire stdout (progress), stderr (errors) and exit handlers for an ffmpeg
    * encode process.  Handlers no-op when the process has been superseded by a
@@ -1747,12 +1783,12 @@ export class HlsSessionManager {
         if (key === "out_time_ms") {
           const numeric = Number(value);
           if (Number.isFinite(numeric) && numeric >= 0) {
-            session.progress.processedSeconds = numeric / MICROSECONDS_PER_SECOND;
+            session.progress.processedSeconds = this.#toAbsoluteProcessedSeconds(session, numeric / MICROSECONDS_PER_SECOND);
           }
         } else if (key === "out_time") {
           const parsed = parseFfmpegTimestamp(value);
           if (parsed != null) {
-            session.progress.processedSeconds = parsed;
+            session.progress.processedSeconds = this.#toAbsoluteProcessedSeconds(session, parsed);
           }
         } else if (key === "speed") {
           session.progress.speed = value;