@torrent-tv/proxy 2.89.9 → 2.89.10

package/CHANGELOG.md

@@ -1,3 +1,7 @@
+## 2.89.10
+
+- **Fix**: An audio track warm-up that is still being made answers `503` with `warming: true`. That answer means the track and how it is produced are recorded for the viewer; a `503` without it is a preparation that failed and recorded nothing. Until now the two were the same status, so a page restating its soundtrack after a reconnect could not tell whether the proxy had kept it.
+
 ## 2.89.9
 
 - **Fix**: The delivery probe judges a connection by how old the newest probe the browser has seen is, not by how long that probe took to arrive. The time it took is fixed once it has arrived, so on the wedge of 2026-09-28 it stayed 9 ms for a whole minute while the browser saw nothing after probe 1464, and every line read `flowing`; on idle healthy connections its 3 ms allowance left out the browser's own handling of the message, and `association-stopped` was printed for connections that delivered every probe. The age's allowance now also counts the probe interval, which `probeWedgeIsCertain` already counted. A real wedge is now named within about a second and reaches the packet witness.

package/docs/browser-proxy-contract.md

@@ -94,7 +94,7 @@ soundtracks the viewer can choose from.
 | `POST /api/transcode-sessions/:id/fragment-far` | Diagnostic fragment and buffer positions; does not change encoding. Best effort, success `204`. |
 | `POST /api/transcode-sessions/:id/release` | `{ consumerId, reason }` releases this viewer's session assignment. |
 | `GET /transcode/:id/:fileName` | HLS playlist, init, or media segment. A file that is still being produced is answered with retryable `503`, not `202`. |
-| `GET /transcode/:id/v/:height/warm` and `/transcode/:id/a/:track/warm` | Prepare the requested video height or audio track at a position. `204` means ready. Audio warm-up `404` means the proxy does not support this operation for that session. Audio warm-up takes an optional `transcode=0\|1`: whether the browser cannot play THAT track's codec as it is. The proxy decides the track's mode by the rule used when a file is opened; without the parameter it assumes the browser needs what it needed for its current track. |
+| `GET /transcode/:id/v/:height/warm` and `/transcode/:id/a/:track/warm` | Prepare the requested video height or audio track at a position. `204` means ready. Audio warm-up `404` means the proxy does not support this operation for that session. Audio warm-up takes an optional `transcode=0\|1`: whether the browser cannot play THAT track's codec as it is. The proxy decides the track's mode by the rule used when a file is opened; without the parameter it assumes the browser needs what it needed for its current track. Audio warm-up `503` with `{ warming: true }` means the track and its mode are recorded for this viewer and its segment is still being made; any other `503`, and `500`, recorded nothing. |
 | `GET /stream?sourceKey=…&fileIndex=N` | Direct file bytes with HTTP range support. |
 
 ### Playback readiness forecast

package/package.json

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

package/routes/transcode/audio-warm/get.js

@@ -90,6 +90,12 @@ export async function handleTranscodeAudioWarmGet(req, reply, { renditions, serv
   }
   // Still being produced. The caller may switch anyway — it will wait where it
   // would have waited before — or ask again.
+  //
+  // `warming: true` says the track and how it is produced ARE recorded for this
+  // viewer — `prepareAudioTrack` records them before the wait — which the
+  // status alone cannot say: the 503 above is a preparation that recorded
+  // nothing. A page restating its soundtrack after a reconnect needs to know
+  // which of the two it got.
   reply.header("Retry-After", "1");
-  return reply.code(503).send({ error: "The audio track is still warming up." });
+  return reply.code(503).send({ error: "The audio track is still warming up.", warming: true });
 }

package/test/audio-warm-recorded.test.js

@@ -0,0 +1,63 @@
+import test from "node:test";
+import assert from "node:assert/strict";
+
+import { handleTranscodeAudioWarmGet } from "../routes/transcode/audio-warm/get.js";
+
+// A page restating its soundtrack after a reconnect has to know whether the
+// proxy RECORDED it. Both answers below are 503; only one of them recorded.
+
+function reply() {
+  return {
+    statusCode: 0,
+    payload: undefined,
+    header() {
+      return this;
+    },
+    code(status) {
+      this.statusCode = status;
+      return this;
+    },
+    send(payload) {
+      this.payload = payload;
+      return this;
+    }
+  };
+}
+
+const request = {
+  params: { sessionId: "base", track: "0" },
+  query: { position: "1641.2", consumer: "viewer-1", transcode: "1" }
+};
+
+test("a track still being made says it was recorded", async () => {
+  let preparedFor = null;
+  const answer = await handleTranscodeAudioWarmGet(request, reply(), {
+    renditions: {
+      prepareAudioTrack: async (...args) => {
+        preparedFor = args;
+        return { sessionId: "rendition", fileName: "segment-00268.mp4" };
+      }
+    },
+    serving: {
+      seekEpoch: () => 0,
+      // Anything but a file or a failure is "not made yet".
+      getFileStream: async () => ({ kind: "superseded" })
+    }
+  });
+  assert.deepEqual(preparedFor, ["base", 0, 1641.2, "viewer-1", false]);
+  assert.equal(answer.statusCode, 503);
+  assert.equal(answer.payload.warming, true);
+});
+
+test("a preparation that failed says nothing was recorded", async () => {
+  const answer = await handleTranscodeAudioWarmGet(request, reply(), {
+    renditions: {
+      prepareAudioTrack: async () => {
+        throw new Error("no encoder");
+      }
+    },
+    serving: {}
+  });
+  assert.equal(answer.statusCode, 503);
+  assert.equal(answer.payload.warming, undefined);
+});