@torrent-tv/proxy 2.76.0 → 2.76.1

package/CHANGELOG.md

@@ -1,3 +1,8 @@
+## 2.76.1
+
+- **New**: How long it takes to read a file's keyframe table is recorded, once per file, with the container that answered and how many times it found. That read decides which branch a picture takes — with the table it is copied, without it the whole picture is re-encoded — and nothing measured it. The one figure printed until now, `keyframes=` on the session-create line, is what the SESSION waited for, which is the remainder of a read the playback plan had already started, and reads zero whenever the plan finished first.
+- **Chore**: The comment promising this read a short timeout and "never more than ~6 s to session start" is gone. Nothing in that path has ever had a timeout: the fall back to re-encoding fires when the table is ABSENT, which is a statement about the file, not about how long a read ran. The file comes off a torrent, so the bytes the table lives in may still be arriving and the read waits for them, without a bound.
+
 ## 2.76.0
 
 - **Fix**: A viewer who changed quality twice lost the soundtrack they had chosen. The three link fields between sessions were replaced by a relation indexed both ways — an output holds its viewers, a viewer holds its outputs — and leaving an output was written as "delete the viewer from the one they came off". The one they came off can be the picture itself, which happens whenever somebody goes down a step, back to the picture's own height and down again: the picture then forgot them entirely, and with them their language, their position and their link. What followed was not a lost setting but silence — the soundtrack they were listening to was the one nobody was listening to any more, so its encoder was stopped as unwanted. A viewer is never dropped from the picture: it is the only id the browser holds, and everything a viewer has chosen is recorded there. Reproduced through the public path before the fix and pinned by a check that fails without it.

package/package.json

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

package/services/hls-session-manager.js

@@ -2281,10 +2281,17 @@ export class HlsSessionManager {
     } else if (hasDuration && !transcodeVideo && !audioOnly) {
       // Video-COPY path: keyframeTimes are REQUIRED to build correct segment
       // boundaries (the playlist itself), so this MUST block session creation —
-      // an incorrect playlist is worse than a slower start. Short timeout: mp4
-      // keyframes come from the moov index (fast); containers that force a full
-      // packet scan time out and fall back to a uniform grid, so this never adds
-      // more than ~6 s to session start.
+      // an incorrect playlist is worse than a slower start.
+      //
+      // There is NO bound on this wait. A comment here used to promise a short
+      // timeout and "never more than ~6 s to session start"; nothing in this
+      // path has ever had a timeout, and the fallback below fires when the
+      // index is ABSENT, which is a statement about the file and not about how
+      // long a read ran. The file comes off a torrent, so the bytes the table
+      // lives in may still be arriving and the read waits for them. What the
+      // bound should be has to come from what this read costs on real hosts —
+      // roadmap item 74, and the reading it needs is the line printed by
+      // #readContainerKeyframes.
       const keyframeStartMs = Date.now();
       // Read the container's OWN keyframe table (Cues/stss) rather than
       // scanning the media. On the copy path ffmpeg can only cut at the
@@ -3130,11 +3137,31 @@ export class HlsSessionManager {
     if (running) {
       return running;
     }
+    // What this read costs is what decides whether a picture can be copied, and
+    // until now nothing recorded it: the one figure printed — `keyframes=` on
+    // the session-create line — is what the SESSION waited for, which is the
+    // remainder of a read the plan had already started, and is zero whenever
+    // the plan finished first. The read itself is a fact of the file and is
+    // timed here, where it is made exactly once per file.
+    const startedMs = Date.now();
     const work = this.#readContainerKeyframesOnce({ sourceKey, fileIndex, inputUrl, logName })
       .then((result) => {
         this.keyframeIndexCache.set(cacheKey, result);
+        const tookMs = Date.now() - startedMs;
+        const found = Array.isArray(result?.times) ? result.times.length : 0;
+        logger.info(
+          `keyframe index "${logName}": ${found > 0 ? `${found} times` : "none"} from the ` +
+            `${result?.format ?? "unrecognised"} container in ${tookMs}ms`
+        );
         return result;
       })
+      .catch((error) => {
+        logger.warn(
+          `keyframe index "${logName}": the read failed after ${Date.now() - startedMs}ms — ` +
+            `${error?.message ?? error}`
+        );
+        throw error;
+      })
       .finally(() => {
         this.keyframeIndexPending.delete(cacheKey);
       });