@torrent-tv/proxy 2.9.45 → 2.9.47

package/CHANGELOG.md

@@ -1,3 +1,11 @@
+## 2.9.47
+
+- **Fix**: Playback could get permanently stuck (hls.js endlessly re-fetching the manifest and the first segment, buffer never advancing) even though the transcode itself was encoding fine, running ahead of realtime. Root cause: ffmpeg creates the fMP4 `init.mp4` file before it finishes writing the codec-header boxes into it (unlike segments, its write is not gated behind an atomic rename), so a request could race a moment where the file exists but is still empty. That empty read was then cached forever as the session's init segment — a zero-length `Buffer` is still a truthy object, so the `if (session.initBytes)` cache guard treated it as "already resolved" and kept serving the empty file for the rest of the session, which hls.js can never initialize a SourceBuffer from. Fixed by treating a zero-byte read as not-yet-ready (keeps the caller's existing long-poll retrying) instead of caching it as final.
+
+## 2.9.46
+
+- **New**: `getFileStats` now reports `resumeNeededBytes` / `resumeDownloadedBytes` — the bytes still to download in the 16 MB window ahead of the file's current read position (tracked per file by `prioritizeByteRange`, cleared on torrent removal), counted byte-accurately including partial pieces. Lets the browser show how much is left to download and the time to resume while buffering.
+
 ## 2.9.45
 
 - **New**: HLS transcode output switched from MPEG-TS (`.ts`) to **fMP4/CMAF** (`.m4s` segments + a shared `init.mp4`). Codec parameter sets (SPS/PPS) now live once in the init segment (referenced by `#EXT-X-MAP`) instead of being repeated in every segment. Benefits: (1) hardware encoders that do not repeat parameter sets — notably the CM4 / HA-Yellow `h264_v4l2m2m` — produce independently-usable segments (on `.ts` the segments after the first lacked SPS/PPS → "non-existing PPS", which is why v4l2m2m was rejected); (2) lower container overhead. The synthetic VOD playlist now emits `#EXT-X-VERSION:7` + `#EXT-X-MAP`; each seek-restart run rewrites `init.mp4`, so `getFileStream` caches and serves the FIRST init for the whole session — it is codec-config-only and position-independent (verified: a single init cleanly decodes segments produced by a later seek-restart run). Raised v4l2m2m `-num_capture_buffers` to 32 (the default 4 deadlocks / drops frames on the CM4). **Verified**: server-side clean decode of the synthetic playlist across seek-restart runs; end-to-end playback **and seek** in hls.js 1.6.16. **Still needs**: verification on native iOS HLS (Safari fMP4) before relying on it. NOTE: v4l2m2m still emits a residual no-picture access unit that the strict startup test rejects, so it continues to fall back to software for now (no regression); fMP4 removes the SPS/PPS blocker — the remaining quirk is separate.

package/package.json

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

package/services/hls-session-manager.js

@@ -48,6 +48,15 @@ const MAX_LOOKAHEAD_SEGMENTS = 8;
 // succession (stall-recovery seeks); without a cooldown ffmpeg ping-pongs
 // between positions, restarting endlessly and producing nothing.
 const RESTART_COOLDOWN_MS = 4_000;
+// Encoder stall watchdog. A running ffmpeg emits `-progress` output on stdout
+// continuously while it encodes; when it hangs mid-file (alive, but producing
+// no output and no stderr — a deadlock, e.g. a stalled input read), that output
+// stops and `progress.updatedAt` freezes. If a segment INSIDE the look-ahead
+// window is being demanded but progress has not advanced for this long, the
+// encoder is wedged (observed: the segment 503s forever). Treat it like a seek
+// and restart ffmpeg at the demanded segment. Conservative — a slow-but-moving
+// encode keeps advancing `updatedAt`, so this only fires on a true freeze.
+const ENCODER_STALL_MS = 12_000;
 // Seek debounce. A far (out-of-window) segment request is a server-side seek.
 // Rather than restart ffmpeg on the first one, wait a short quiet period:
 // further far requests re-arm it and update the target to the latest index, so
@@ -1804,12 +1813,28 @@ export class HlsSessionManager {
     // and position-independent, but each seek-restart run REWRITES init.mp4, so
     // cache the FIRST one and always serve that — otherwise the init the player
     // fetched could differ from a later run's, breaking playback after a seek.
+    //
+    // ffmpeg creates init.mp4 before it has finished writing the fMP4 header
+    // boxes into it (unlike segments, its write is not gated behind an atomic
+    // rename), so a read can race a moment where the file EXISTS but is still
+    // EMPTY. Root cause of a real incident: that empty read used to be cached
+    // as `session.initBytes` — a zero-length Buffer is still a truthy object,
+    // so `if (session.initBytes)` treated it as "already resolved" and served
+    // the empty file for the rest of the session's life, permanently breaking
+    // playback (hls.js can never initialize its SourceBuffer from an empty
+    // init segment) while the transcode itself kept encoding normally. Guard
+    // on non-empty content on both the cache check and the fresh read, so an
+    // empty read is treated as not-yet-ready and the caller's long-poll keeps
+    // retrying until ffmpeg has actually written the header.
     if (fileName === SEGMENT_INIT_FILE_NAME) {
-      if (session.initBytes) {
+      if (session.initBytes && session.initBytes.length > 0) {
         return { kind: "file", stream: Readable.from([session.initBytes]), contentType: "video/mp4", isPlaylist: false };
       }
       try {
         const bytes = await readFile(path.join(session.dirPath, SEGMENT_INIT_FILE_NAME));
+        if (bytes.length === 0) {
+          return { kind: "warming-up" };
+        }
         session.initBytes = bytes;
         return { kind: "file", stream: Readable.from([bytes]), contentType: "video/mp4", isPlaylist: false };
       } catch {

package/services/torrent-pool.js

@@ -295,6 +295,16 @@ export class TorrentPool {
    */
   #lastAccess = new Map();
 
+  /**
+   * Last byte offset each active reader is streaming from, keyed by torrent then
+   * fileIndex. Set by prioritizeByteRange on every /stream range request; read by
+   * getFileStats to report how much of the window ahead of the read head is still
+   * to download — the "amount left to resume" shown while buffering.
+   *
+   * @type {Map<import("webtorrent").Torrent, Map<number, number>>}
+   */
+  #readPositionByTorrent = new Map();
+
   /** Global disk cap in bytes (0 = disabled). */
   #maxDiskBytes = 0;
 
@@ -700,6 +710,7 @@ export class TorrentPool {
     }
     this.fileUsageByTorrent.delete(torrent);
     this.#lastAccess.delete(torrent);
+    this.#readPositionByTorrent.delete(torrent);
     const name = typeof torrent.name === "string" ? torrent.name : "(unknown)";
     try {
       torrent.destroy({ destroyStore: true }, () => {
@@ -743,6 +754,14 @@ export class TorrentPool {
 
     const header = this.#getHeaderRangeProgress(torrent, file);
 
+    // Bytes still to download in the window ahead of where this file is being
+    // read — "how much left to resume". Null until a read position is known.
+    const readPositions = this.#readPositionByTorrent.get(torrent);
+    const readByteStart = readPositions ? readPositions.get(fileIndex) : undefined;
+    const resume = typeof readByteStart === "number"
+      ? this.#getResumeWindowProgress(torrent, file, readByteStart)
+      : null;
+
     // Null-safe downloaded/progress (webtorrent's own getters throw on a
     // deselected null piece — see fileDownloadedBytes).
     const fileLength = typeof file.length === "number" ? file.length : 0;
@@ -753,6 +772,9 @@ export class TorrentPool {
       fileProgress: fileLength > 0 ? Math.max(0, Math.min(1, fileDownloaded / fileLength)) : 0,
       fileDownloaded,
       fileLength,
+      // Resume window (ahead of the read head): bytes needed vs downloaded.
+      resumeNeededBytes: resume ? resume.totalBytes : null,
+      resumeDownloadedBytes: resume ? resume.downloadedBytes : null,
       // Phase-1 progress: how much of the header/index region (the bytes the
       // codec probe needs before transcoding can start) is downloaded. Counted
       // by whole pieces from the torrent bitfield, so it advances coarsely
@@ -808,6 +830,45 @@ export class TorrentPool {
     return { totalBytes, downloadedBytes };
   }
 
+  /**
+   * Count, by whole torrent pieces, how many bytes of the window AHEAD of the
+   * current read position are downloaded — i.e. how much is still to download
+   * before playback can continue from that point. Mirrors
+   * {@link #getHeaderRangeProgress}, for the moving read head.
+   *
+   * @param {import("webtorrent").Torrent} torrent
+   * @param {import("webtorrent").TorrentFile} file
+   * @param {number} readByteStart - Byte offset within the file the reader is at.
+   * @returns {{ totalBytes: number, downloadedBytes: number } | null}
+   */
+  #getResumeWindowProgress(torrent, file, readByteStart) {
+    const pieceLength = Number(torrent?.pieceLength);
+    const bitfield = torrent?.bitfield;
+    const fileLength = Number(file?.length);
+    if (
+      !Number.isFinite(pieceLength) || pieceLength <= 0 ||
+      !bitfield || typeof bitfield.get !== "function" ||
+      !Number.isFinite(fileLength) || fileLength <= 0
+    ) {
+      return null;
+    }
+    const fileOffset = Number.isFinite(file.offset) ? file.offset : 0;
+    const windowStart = Math.max(0, Math.min(Number(readByteStart) || 0, fileLength - 1));
+    const windowEnd = Math.min(fileLength - 1, windowStart + PRIORITY_WINDOW_BYTES - 1);
+    const firstPiece = Math.floor((fileOffset + windowStart) / pieceLength);
+    const lastPiece = Math.floor((fileOffset + windowEnd) / pieceLength);
+    // Byte-accurate: count the PARTIAL progress of in-progress pieces (not whole
+    // pieces), so "amount left" moves smoothly instead of jumping by a whole
+    // piece (8 MB here) at a time.
+    let totalBytes = 0;
+    let downloadedBytes = 0;
+    for (let piece = firstPiece; piece <= lastPiece; piece += 1) {
+      totalBytes += pieceLength;
+      downloadedBytes += pieceDownloadedBytes(torrent, piece);
+    }
+    return { totalBytes, downloadedBytes };
+  }
+
   /**
    * Pre-fetch the leading and trailing bytes of a torrent file so that
    * WebTorrent prioritises the pieces that contain file headers and footers.
@@ -967,6 +1028,16 @@ export class TorrentPool {
     const fileEndPiece = Math.floor((fileOffset + fileLength - 1) / pieceLength);
 
     const safeStart = Math.max(0, Number(byteStart) || 0);
+
+    // Remember where this file is being read from, so getFileStats can report the
+    // download progress of the window ahead of the read head (resume amount).
+    let readPositions = this.#readPositionByTorrent.get(torrent);
+    if (!readPositions) {
+      readPositions = new Map();
+      this.#readPositionByTorrent.set(torrent, readPositions);
+    }
+    readPositions.set(fileIndex, safeStart);
+
     const absStart = fileOffset + safeStart;
     const playheadPiece = Math.floor(absStart / pieceLength);
     const absWindowEnd = Math.min(