@torrent-tv/proxy 2.9.140 → 2.9.141

package/CHANGELOG.md

@@ -1,3 +1,7 @@
+## 2.9.141
+
+- **New**: A held segment says whether the encoder is actually moving. The line already reported that the run was alive and at the right index and stopped there, which left the two possible causes indistinguishable: an encoder waiting on torrent pieces looks exactly like one that is encoding and has not finished. It now reports how much media the run has produced since it started and at what speed, and says outright when the position has not moved at all — which means the input is what is being waited for. Measured 2026-08-11: segment #675 was held with the run started at #675 and the encoder alive, nothing in the log could say why, and the browser then abandoned the session and built another — which is where the "second session after a seek" came from.
+
 ## 2.9.140
 
 - **New**: What this host takes to produce a first segment is now derived from the startup benchmark, so a machine answers correctly on its very first run. Encoder detection already encodes `testsrc2` through the real HLS pipeline and records each preset's throughput in pixels per second; one segment is a known quantity of pixels, so the time follows by division. No coefficient is involved — it is a measurement of this machine taken minutes earlier, applied to a known amount of work. Until now there was no answer at all before the first session finished, and the browser filled the gap with an assumed rate of exactly one, which was wrong by a factor of four in both directions.

package/host-timings.json

@@ -1 +1 @@
-{"firstSegment":[3,1,4,11],"sessionCreate":[]}
+{"firstSegment":[3,1,4,11,3,1,3,17],"sessionCreate":[]}

package/package.json

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

package/services/hls-session-manager.js

@@ -3890,10 +3890,21 @@ export class HlsSessionManager {
     }
     session.holdExplainedAt.set(fileName, now);
     const index = session.segmentFormat.segmentIndexFromName(fileName);
+    // What the encoder has actually DONE since it restarted. "Alive at the right
+    // index" was as far as the old line went, and it left the two possible
+    // causes indistinguishable: an encoder waiting for torrent pieces looks
+    // exactly like one that is encoding and simply has not finished. The
+    // difference is whether its position has moved at all.
+    const runStartSeconds = this.#segmentStartTime(session, session.encodeStartIndex ?? 0);
+    const position = Number(session.progress?.processedSeconds);
+    const produced = Number.isFinite(position) ? position - runStartSeconds : null;
+    const speed = session.progress?.speed ?? "n/a";
     logger.warn(
       `transcode ${session.id} holding ${fileName}: ${reason} ` +
       `(run from #${session.encodeStartIndex ?? "?"}, viewer at #${session.lastRequestedSegment ?? "?"}, ` +
-      `encoder ${session.ffmpeg ? "alive" : "stopped"}, index #${index})`
+      `encoder ${session.ffmpeg ? "alive" : "stopped"}, index #${index}, ` +
+      `produced ${produced === null ? "nothing yet — no position reported" : `${produced.toFixed(1)}s`} ` +
+      `at ${speed}${produced !== null && produced <= 0 ? " — the encoder has not moved, so it is waiting on its input" : ""})`
     );
   }