@torrent-tv/proxy 2.80.2 → 2.80.4

package/CHANGELOG.md

@@ -1,4 +1,19 @@
-## 2.81.0
+## 2.80.4
+
+- **Fix**: The piece an encoder writes out while it is being stopped is thrown away instead of served. `-segment_list pipe:3` was taken as proof that a piece is whole — ffmpeg names a file when it closes it, so a named file is closed. That is true of the FILE and false of the SPAN: on `SIGTERM` ffmpeg writes out the piece it had open and names it like any other, so what lands on disk is a valid, decodable piece holding film only up to the instant of the stop, under a name whose playlist entry promises the whole span. Field 2026-09-06, one session, both tracks: `segment-00010.mp4` held 3.92 s of its declared 5.589 s — 96 frames — and the picture jumped 1.5 s at 1:02, while the soundtrack's own stopped run left the same shape at 17.5 s, 2.8 s wide. Both were the viewer's report of the picture and the sound jerking.
+- **Fix**: Which piece that is comes from the run itself — the last name it wrote after being told to stop — so nothing is read, no span is measured and no tolerance is chosen. The cleanup already existed and already ran on every abnormal ending; it removed the piece only when the piece did not decode, and this one decodes.
+- **Chore**: A piece genuinely finished a moment before the stop can be named here too, and is then made a second time. That is the cheaper of the two errors by the rule this project already holds: the other one is a hole the viewer sees.
+
+## 2.80.3
+
+- **Fix**: A boundary carries the keyframe it IS, instead of being looked up by value in the container's list. A cut is kept on the player's clock — `keyframe - startTime`, rounded to six places — and the seek used to add the start time back and search the file's own keyframes for the result. That round trip is lossy: a keyframe at 26.234 s in a container starting at 0.083 s comes back as 26.233999999999998, and "the keyframe at or before that" is then the PREVIOUS one. Two parts in a quadrillion became 8.717 seconds. Where each cut is on the file's own clock is now carried by index (`output/cut-grid.js`, `Timeline.sourceTimes`) and asked for directly, so a boundary cannot fail to find itself.
+- **Fix**: A run on the source's keyframe grid is given no output-side trim. Beside `-copyts` that trim does the opposite of what it says: measured 2026-09-06 on a file with a 5 s keyframe interval, a run that landed at 15 s and was told to trim to the cut at 20 s produced its first piece starting at 10 s, and one told to trim to 17 s produced cuts at 13.129, 18.129, 23.129 — the whole grid moved back by the trim itself. The muxer's cut times are absolute under `-copyts` while the trim is not, so every cut of the run inherits the difference while the numbering, fixed when the process starts, does not.
+- **Fix**: Those two together are why a film would not start on 2026-09-05. The run was asked for segment #36 at 247.873 s, landed at 230.439 s — one keyframe from each fault — and its pieces were named #36, #37, #38 while carrying film 17.4 s earlier: the proxy's own log said `segment #41 carries 267.976s while the playlist the player holds says 283.283s`, six times over. The soundtrack's run did the same with its own numbers, and the two tracks ended up with different holes. The player's picture buffer covered the playhead at 251.7 s; its sound buffer read `230.465..245.398` and `262.827..308.289` — a 17.4 s hole exactly across it. What a player can play is the overlap of the two, so nothing was playable, the cushion stood at 0.0 s for two minutes, and the viewer was told the proxy had sent no video. Every segment had in fact been delivered.
+- **Chore**: Where a file is cut is decided in `services/output/cut-grid.js`, which is the layer that owns cutting; `hls-session-manager.js` is 48 lines shorter for it.
+
+## 2.80.2
+
+- **Chore**: The same code as 2.80.1, republished. The release command ran twice when the session it was started from was interrupted, so both versions carry exactly the change described below; 2.80.2 is what `latest` points at.
 
 - **Fix**: Three encoders were started on one track within 200 ms, each into the road another was already writing, and the film came apart. Field 2026-09-05: fifteen readers on a piece store that holds sixteen pieces, half of all evictions taking a piece a reader had declared it wanted, two thirds of reads coming back from disk — and then `/stream` handing out bytes that were not the file's, twenty-two source-parse errors from ffmpeg at scattered offsets, a segment the player could not append, and an empty picture for six minutes while the proxy went on encoding. The placement rule was the cause: an encoder was put at the first unmade piece of the most urgent band, which is always the piece the working encoder is about to write.
 - **Fix**: One encoder's work now ends where the next one's begins. A free stretch may run to the end of the track, and an encoder given all of it walks into every stretch behind it — two LIVE encoders then write the same file names at the same time, and the file belongs to neither. That is the thing being prevented, and only that: driving through material that is already made is a legitimate outcome of the comparison, taken when encoding it again costs less than the death of this encoder plus the start of another. Bounded at the next start, two live stretches cannot overlap however the bands move. Bounding them at a band's own end was tried and is worse: a band edge travels with the viewer, so every step forward leaves a sliver just past the previous encoder and buys an encoder for it.

package/package.json

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

package/services/encode/EncodeRun.js

@@ -61,6 +61,11 @@ const MICROSECONDS_PER_SECOND = 1_000_000;
  * @property {number} livedMs
  * @property {boolean} normal - Whether this ending is the expected one.
  * @property {string} lastError - The last thing ffmpeg said on stderr.
+ * @property {string | null} flushedName - The piece the encoder wrote out while
+ *   it was shutting down, if it wrote one. It is closed and it is SHORT: it
+ *   holds film only up to the instant the run was stopped, while its name
+ *   promises the whole span the playlist gives that number. Null where the run
+ *   was never told to stop.
  */
 
 /**
@@ -99,6 +104,26 @@ export class EncodeRun {
   /** Half a name left over from the last chunk of the encoder's own channel. */
   #closedTail = "";
 
+  /**
+   * The last piece named on the ready channel AFTER the run was told to stop.
+   *
+   * On SIGTERM ffmpeg writes out the piece it had open and names it like any
+   * other, so "the encoder closed it" stops meaning "it is whole". Field
+   * 2026-09-06: a run stopped mid-piece left `segment-00010.mp4` holding 3.92 s
+   * of the 5.589 s its name promises, and the viewer's picture jumped 1.5 s at
+   * 1:02. The soundtrack did the same at 17.5 s, 2.8 s wide, in the same
+   * session.
+   *
+   * Distinguished by WHEN the name arrives, which is exact and needs no reading
+   * of the file: a name that arrives after the stop was ordered is the flush.
+   * A piece genuinely closed a moment before the stop can land here too, and
+   * then it is made a second time — the cheaper of the two errors, since the
+   * other one is a hole the viewer sees.
+   *
+   * @type {string | null}
+   */
+  #flushedName = null;
+
   /**
    * When this run was told to stop, so the death itself can be priced.
    *
@@ -426,6 +451,9 @@ export class EncodeRun {
       if (name.length === 0) {
         continue;
       }
+      if (this.#stopping) {
+        this.#flushedName = name;
+      }
       this.onClosed(name);
     }
   }
@@ -615,6 +643,7 @@ export class EncodeRun {
       from: this.from,
       to: this.to,
       reached: this.reached,
+      flushedName: this.#flushedName,
       livedMs,
       // How long dying took, and how long the first output took to appear.
       // Null where the run was never told to stop, or never produced anything:

package/services/encode/SegmentStore.js

@@ -350,12 +350,12 @@ export class SegmentStore {
    * @param {((raw: Buffer) => boolean) | null} [judgeUsable]
    * @returns {Promise<number | null>} The segment number removed, or null.
    */
-  async discardOpenPieceOf(key, within, judgeUsable = null) {
+  async discardOpenPieceOf(key, within, judgeUsable = null, flushedName = null) {
     const format = this.#formats.get(key);
     if (!format) {
       return null;
     }
-    const removed = await discardOpenPiece(this.directoryFor(key), format, within, judgeUsable);
+    const removed = await discardOpenPiece(this.directoryFor(key), format, within, judgeUsable, flushedName);
     if (removed !== null) {
       this.#held.delete(key);
       this.#logger?.info?.(

package/services/encode/open-piece.js

@@ -23,17 +23,37 @@ import path from "node:path";
  * numbering and convinced the look-ahead to keep the encoder stopped for having
  * "produced" it.
  *
- * Only an unusable piece goes. A run stopped between two cuts leaves a finished
- * file behind, and deleting good output would mean making it a second time.
+ * Two kinds of file are removed, and the second is the one a viewer feels.
+ *
+ * The first is unreadable — a run that died mid-write. The second READS
+ * perfectly and is SHORT: on SIGTERM ffmpeg writes out the piece it had open
+ * and names it on the ready channel like any other, so it is a valid fMP4
+ * holding film only up to the instant of the stop, under a name that promises
+ * the whole span the playlist gives that number. Field 2026-09-06:
+ * `segment-00010.mp4` held 3.92 s of its declared 5.589 s — 96 frames — and the
+ * picture jumped 1.5 s at 1:02; the soundtrack did the same at 17.5 s, 2.8 s
+ * wide, in the same session. Judging such a file by whether it decodes says
+ * yes, which is how both survived.
+ *
+ * Which file that is comes from the run itself — the last name it wrote after
+ * being told to stop — and not from reading the pieces, so there is no span to
+ * measure and no tolerance to choose.
+ *
+ * A piece that was genuinely finished a moment before the stop can be named
+ * here too, and is then made a second time. That is the cheaper error: the
+ * other one is a hole the viewer sees.
  *
  * @param {string | null | undefined} runDirPath
  * @param {{ isSegmentFileName: (name: string) => boolean, segmentIndexFromName: (name: string) => number }} segmentFormat
  * @param {((raw: Buffer) => boolean) | null} judgeUsable - Whether a non-empty
  *   piece carries what it should. Null where nothing can say, and then only an
  *   empty file is removed.
+ * @param {string | null} [flushedName] - The piece the encoder wrote out while
+ *   shutting down. Removed whether or not it reads, because reading is not the
+ *   question about it.
  * @returns {Promise<number | null>} The segment number removed, or null.
  */
-export async function discardOpenPiece(runDirPath, segmentFormat, within, judgeUsable) {
+export async function discardOpenPiece(runDirPath, segmentFormat, within, judgeUsable, flushedName = null) {
   if (!runDirPath || typeof segmentFormat?.isSegmentFileName !== "function") {
     return null;
   }
@@ -65,12 +85,16 @@ export async function discardOpenPiece(runDirPath, segmentFormat, within, judgeU
     return null;
   }
   const filePath = path.join(runDirPath, highest.name);
-  let unusable = false;
+  // The encoder named this one on its way out, so it holds film up to the stop
+  // and no further. Nothing about its contents can say that — it decodes — so
+  // nothing about its contents is asked.
+  const wasFlushedOnTheWayOut = typeof flushedName === "string" && flushedName === highest.name;
+  let unusable = wasFlushedOnTheWayOut;
   try {
     const info = await stat(filePath);
     if (info.size === 0) {
       unusable = true;
-    } else if (typeof judgeUsable === "function") {
+    } else if (!unusable && typeof judgeUsable === "function") {
       unusable = !judgeUsable(await readFile(filePath));
     }
   } catch {