@torrent-tv/proxy 2.9.59 → 2.9.60

package/CHANGELOG.md

@@ -1,3 +1,7 @@
+## 2.9.60
+
+- **Fix**: Seeking restarted the encoder at the position it was **already encoding**, destroying the very work being waited for — visible in the field log 2026-08-02 as `restart at #865` twice within ten seconds, each killing a run that was encoding #865. While the target segment is being produced the player keeps re-requesting it, and every such request looks "far" from where the encoder USED to be, so each one re-triggered a restart at the position we had only just moved to; playback data kept appearing and vanishing, and a seek only completed when a segment happened to reach the player before the next restart. A settled seek whose target equals the current runs start index is now ignored outright. This is distinct from the 2.9.58 guard, which only decides whether to let the current run finish its first segment — not whether a new run is needed at all; that guard behaved correctly here (it logged `run produced 4.5s (first segment done)`) and still let the pointless restart through.
+
 ## 2.9.59
 
 - **Chore**: Diagnostics for seek handling. The session-start line now carries the proxy version (`transcode <id> start (proxy 2.9.59) "<file>"`), so a field report answers "is the host running the build I published?" by itself. And the seek restart guard added in 2.9.58 now states its decision: either `seek #N HELD — current run has produced Xs of the Ys first segment` or, on the restart line, why it was allowed (`run is dead` / `run produced Xs (first segment done)` / `grace expired`). Previously a permitted restart was indistinguishable in the log from the runaway ping-pong the guard exists to stop, which made diagnosing "seek still did not work" guesswork.

package/package.json

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

package/services/hls-session-manager.js

@@ -2013,6 +2013,23 @@ export class HlsSessionManager {
       session.seekFirstFarAt = 0;
       return;
     }
+    // Already encoding exactly this position — there is nothing to seek TO, so
+    // restarting can only destroy the very work being waited for. The player
+    // keeps re-requesting the target segment while it is still being produced,
+    // and every such request looks "far" from where the encoder USED to be, so
+    // without this check each one re-triggered a restart at the position we had
+    // only just moved to: field log 2026-08-02 shows `restart at #865` twice in
+    // ten seconds, each killing a run that was encoding #865. The guard below
+    // did not catch it — it only decides whether to let the current run finish,
+    // not whether a new run is needed at all.
+    if (target === session.encodeStartIndex && session.ffmpeg != null && !hasChildExited(session.ffmpeg)) {
+      logger.info(
+        `transcode ${session.id} seek #${target} ignored — the current run already starts there`
+      );
+      session.seekTarget = null;
+      session.seekFirstFarAt = 0;
+      return;
+    }
     // Minimum gap between actual restarts (the settle already collapses bursts;
     // this only guards back-to-back seeks). If still cooling down, re-arm once
     // for the remaining cooldown instead of restarting now.