@torrent-tv/proxy 2.9.121 → 2.9.123

package/CHANGELOG.md

@@ -1,3 +1,11 @@
+## 2.9.123
+
+- **Fix**: The check added in 2.9.121 was deleting the file an encoder was writing into. A segment short of a track means one of two very different things — left behind by a run that was killed, or simply not finished yet — and treating them alike removed the file mid-write, after which ffmpeg went on writing to something nobody could open and the segment never appeared. Measured 2026-08-06: segment #225 was deleted 14 s into the run producing it and answered 404 thirty-three seconds later. The readiness rule could not prevent it, because it waves a segment through once the NEXT one exists and that next one had been left by an older run. Ownership decides it now: the current run writes from its start index upwards, so a file at or above that index while the run is alive is unfinished and is waited for, and only a file below it, or any file once no run is producing, is a leftover worth removing.
+
+## 2.9.122
+
+- **Fix**: A session created with a start position begins encoding there, instead of at the top of the file. The position was honoured everywhere except the one place that mattered: it went into the session key and into the log line, and then the first run started at index 0 regardless. Measured 2026-08-06 on a Retry after the proxy had restarted — the session was created with `start=1580s`, the encoder began at #0, the player asked for #152, and 45 s later the browser gave up with "no data arrived from the proxy" while the transcode ran happily at 9.9x through the opening credits.
+
 ## 2.9.121
 
 - **Fix**: A segment that is short of a track is no longer served, which is what left a seek hanging with the proxy answering every request in 98 ms. A run that is terminated closes its current output file properly — trailing index and all — but the file holds only what had been muxed by then, and after a seek-restart that is routinely one track of two. Nothing about such a file looks unfinished: it exists, the next one exists, so the readiness rule called it done. Measured 2026-08-06 on a stuck session: segment #133 carried one `tfdt` where #131 and #134 carried two, and #132 was zero bytes. The fragments are already walked to stamp their timestamps, so counting the tracks in them costs nothing; a segment missing one is deleted and produced again.

package/package.json

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

package/services/hls-session-manager.js

@@ -1454,7 +1454,18 @@ export class HlsSessionManager {
         `duration=${hasDuration ? formatSeconds(durationSeconds) : "unknown"} segments=${segmentCount}`
     );
 
-    await this.#startEncodeRun(session, 0);
+    // Begin where the viewer asked, not at the top of the file. The position
+    // was already honoured everywhere EXCEPT here: it went into the session key
+    // and into the log line, and then the first run started at index 0 anyway.
+    // Measured 2026-08-06 on a Retry after the proxy restarted — the session
+    // was created with `start=1580s`, the encoder began at #0, the player
+    // asked for #152, and 45 s later the browser gave up with "no data arrived
+    // from the proxy" while the transcode ran happily at 9.9x through the
+    // opening credits.
+    const firstIndex = normalizedStartPosition > 0
+      ? this.#segmentIndexForTime(session, normalizedStartPosition)
+      : 0;
+    await this.#startEncodeRun(session, firstIndex);
 
     try {
       await this.waitUntilReady(session);
@@ -3407,14 +3418,38 @@ export class HlsSessionManager {
           typeof session.segmentFormat.hasEveryTrack === "function" &&
           !session.segmentFormat.hasEveryTrack(bytes, session.initBytes ?? null)
         ) {
+          // Short of a track means one of two very different things, and the
+          // first version of this check treated them alike — deleting the file
+          // an encoder was writing INTO, so it went on writing to something
+          // nobody could open and the segment never appeared. Measured
+          // 2026-08-06: segment #225 was deleted 14 s into the run producing
+          // it, and answered 404 thirty-three seconds later.
+          //
+          // The run that is producing this segment right now has simply not
+          // finished it: wait, exactly as for a segment that does not exist
+          // yet. Only a segment the CURRENT run has already moved past — the
+          // next one exists, or no run is producing at all — is a leftover, and
+          // only that one is worth removing so it can be made again.
+          // Whose file is this? The current run writes from
+          // `encodeStartIndex` upwards, so anything at or above that index
+          // while the run is alive may simply be unfinished — the readiness
+          // rule can wave it through on the strength of a NEXT segment left by
+          // an older run, which is exactly how the file being written came to
+          // be read. Anything below it, or any file at all once no run is
+          // producing, belongs to a run that has ended.
+          const stale = session.ffmpeg === null || index < (session.encodeStartIndex ?? 0);
           logger.warn(
             `transcode ${session.id} segment #${index} is short of a track — ` +
-            "left behind by a run that was terminated; producing it again"
+            (stale
+              ? "left behind by a run that was terminated; producing it again"
+              : "still being written; waiting for it")
           );
-          try {
-            await unlink(filePath);
-          } catch {
-            // Already gone, or being rewritten: either way nothing to do.
+          if (stale) {
+            try {
+              await unlink(filePath);
+            } catch {
+              // Already gone, or being rewritten: either way nothing to do.
+            }
           }
           return { kind: "warming-up" };
         }