@torrent-tv/proxy 2.14.0 → 2.14.2

package/CHANGELOG.md

@@ -1,3 +1,11 @@
+## 2.14.2
+
+- **Fix**: A separately published audio track starts BEHIND the picture's read head, and a request behind its run is answered as before. Two mistakes compounded in 2.14.1 and left the viewer on a spinner that never ended. The position this class keeps is written by the segments a session serves — the READ head — while the viewer's picture sits behind it by everything they have buffered, so the track was started AHEAD of them: field 2026-08-15, the run placed at segment #16 while the player asked for #10. On top of that, 2.14.1 had begun answering such a request "not found" at once instead of holding it, which turned a condition the encoder used to correct in twenty seconds into a permanent refusal: hls.js retried #10 for a minute and a half, raised a fatal network error, recovered, and retried it again. The prompt refusal is withdrawn — it was written for a probe and met a real request — and the track now starts a whole look-ahead behind the read head, which is exactly how far apart the two can be. The price is audio the player already holds: at ten to twenty times realtime and 75 KB a piece, a second or two of work.
+
+## 2.14.1
+
+- **Fix**: Changing the audio track no longer costs twenty seconds of silence. The player asks the NEW rendition for its segment #0 before anything else — measured 2026-08-15, a track changed at 159 s with the rendition correctly placed at #26 — and the repair that exists for a run placed WRONGLY took that literally: it killed the run and restarted the encoder at the beginning of the film, so the segment the viewer was waiting for arrived 20.5 s later. A rendition is never repaired by moving it, because its run is placed where the viewer is and the request behind it is the player probing; and such a request is now answered at once rather than held, since holding it spends the player's patience on a fragment that can never be produced. The refusal stands down while a seek of the rendition's own is settling: a viewer going BACKWARDS is reported to the base and forwarded to the rendition, but its run only moves when the settle fires, so until then the requests for the new position are behind the old one — and those are exactly the ones the viewer is waiting for.
+
 ## 2.14.0
 
 - **Fix**: A rung the source is served at by COPY is never withdrawn from the offer, and the offer is one answer for the whole file rather than one per rung. Which heights this host can serve is a property of the FILE, but a rung is a session of its own and knows only its own encode — so, asked while the viewer watched 240p, the 240p session priced the 1080p rung as a re-encode, because ITS video is re-encoded, and refused it on a machine that had been serving that exact height by copy a minute earlier. Field 2026-08-15: `proxy now offers 360p 240p` four seconds after the switch, and the viewer could not go back to the quality that worked. A copied rung costs no encoder at all, so no measurement of the host can be a reason to drop it — it is precisely where a viewer on a rung the machine cannot hold returns to.

package/package.json

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

package/services/hls-session-manager.js

@@ -5334,8 +5334,26 @@ export class HlsSessionManager {
       // while the player is asking for segment #537 — and the audio would begin
       // at zero and never catch up, since nothing treats a far request as a
       // seek. The accessor falls back to the last segment actually requested.
-      startPositionSeconds:
-        Math.floor(this.#viewerPositionOf(this.#activeVariant(base)) / 10) * 10,
+      // Behind where the picture has been READ to, by the whole look-ahead.
+      //
+      // The position this class keeps is written by the segments a session
+      // serves, so it is the READ head, and the player's picture sits behind it
+      // by everything it has buffered — up to the look-ahead cap. Starting the
+      // audio at the read head therefore starts it AHEAD of the viewer, and
+      // every request they then make is behind a run that only moves forward.
+      // Field 2026-08-15: the run was placed at #16, the player asked for #10,
+      // and the audio never arrived until the encoder was dragged back.
+      //
+      // The cap is exactly how far apart the two can be, so subtracting it
+      // cannot leave the run ahead of the viewer. The price is audio the player
+      // already has — for a track being encoded at ten to twenty times realtime
+      // and served in 75 KB pieces, that is a second or two of work.
+      startPositionSeconds: Math.max(
+        0,
+        Math.floor(
+          (this.#viewerPositionOf(this.#activeVariant(base)) - LOOKAHEAD_PAUSE_SECONDS) / 10
+        ) * 10
+      ),
       segmentFormatId: base.segmentFormat.id,
       // Cut where the picture is cut. Two streams meant to be played together
       // have to be divided at the same times, and the grid is the base's — the

package/test/quality-variants.test.js

@@ -637,3 +637,39 @@ test("a rung served by copy stays offered while a re-encoded rung is on screen",
     "one answer for the family: a rung asked while watching another must not disagree with the base"
   );
 });
+
+test("a separately published audio track starts behind the picture's read head", async (t) => {
+  const { manager, base, dirPath } = await managerWithBase();
+  t.after(async () => {
+    await manager.disposeAll();
+    await rm(dirPath, { recursive: true, force: true });
+  });
+  // What broke playback on 2026-08-15: the position this class keeps is where
+  // segments have been SERVED to, and the viewer's picture is behind it by
+  // everything they have buffered. Started at the read head, the audio run sat
+  // ahead of the viewer and every request they made was behind a run that only
+  // moves forward.
+  base.viewerPositionSeconds = 140;
+  base.audioSeparate = true;
+  manager.getCachedAudioTracks = () => [
+    { index: 0, language: "rus", title: "", isDefault: true },
+    { index: 1, language: "eng", title: "", isDefault: false }
+  ];
+  const created = [];
+  manager.createOrGetSession = async (params) => {
+    created.push(params);
+    const rendition = fakeSession({ id: VARIANT_ID, encodeHeight: 0, dirPath });
+    rendition.audioOnly = true;
+    return { sessionId: VARIANT_ID, session: rendition };
+  };
+
+  // A segment, not the playlist: the playlist is answered from the base and
+  // deliberately starts no encoder.
+  await manager.resolveAudioRenditionFile(BASE_ID, 1, "segment-00010.mp4");
+
+  assert.equal(created.length, 1, "the track's own session was made");
+  assert.ok(
+    created[0].startPositionSeconds <= 20,
+    `started behind the picture, not at the read head — got ${created[0].startPositionSeconds}s for a read head of 140s`
+  );
+});