@torrent-tv/proxy 2.9.22 → 2.9.23

package/CHANGELOG.md

@@ -1,3 +1,7 @@
+## 2.9.25
+
+- **Fix**: Cold-start playback no longer fails with "Data channel request timed out". `POST /api/playback-plan` (`playback-planner.getPlan`) used to block up to 60 s waiting for the file header to download for the codec probe — exactly the transport's 60 s request timeout, so a cold torrent (peers still connecting, 0 % header) raced and failed. The planner now takes a short per-request budget (`maxWaitMs`, 8 s from the route): it prioritises the file header and probes, and if the header still isn't down it returns the plan flagged `pending: true` (uncached) instead of blocking. The browser polls again — each call keeps the header prioritised — so no single request approaches the 60 s limit and the existing `/stats` poll keeps showing live peers/speed/% the whole time. Pairs with server 0.8.24 (browser-side poll loop); ship together.
+
 ## 2.9.24
 
 - **New**: IPv6-first support (roadmap step 5a). (1) A second STUN server (`stun.cloudflare.com:3478`, alongside Google's) is added to the ICE config — both have IPv6 (AAAA) records, so when the proxy host has a global IPv6 address it gathers a `srflx` candidate over v6 too. IPv6 has no NAT, so if both the proxy and a (v6-native, e.g. cellular) viewer have global v6, the connection can go **direct** over v6 — sidestepping the whole NAT-traversal machinery. (2) Candidate logging now classifies each candidate by address scope — `v4-private` / `v4-public` / `v6-global` / `v6-ula` / `v6-linklocal` / `v6-loopback` (replaces the old private/public host label) — so the field log shows whether a global IPv6 path is actually being offered and chosen. Audited the candidate path: the proxy already forwards ALL candidates (incl. global v6) and the browser adds them all — nothing was dropping global v6, so no filter fix was needed. NOTE: not verifiable on the dev's proxy (its ISP exposes only ULA v6 `fd…`, no global v6); needs a proxy with global v6 to confirm in the field — the new `v6-global` log tag is there to spot it.

package/package.json

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

package/routes/api/playback-plan/post.js

@@ -35,7 +35,11 @@ export async function handleApiPlaybackPlanPost(req, reply, { playbackPlanner })
   }
 
   try {
-    const plan = await playbackPlanner.getPlan({ sourceKey, fileIndex, userAgent });
+    // Short per-request budget: if the file header is not downloaded yet the
+    // planner returns quickly with `pending: true` instead of blocking up to
+    // the transport's 60 s request timeout. The browser polls again (the header
+    // keeps downloading, prioritised on each call). Well under that 60 s limit.
+    const plan = await playbackPlanner.getPlan({ sourceKey, fileIndex, userAgent, maxWaitMs: 8_000 });
     return reply.send(plan);
   } catch (error) {
     if (error instanceof Error && error.code === "SOURCE_NOT_FOUND") {

package/services/playback-planner.js

@@ -167,13 +167,22 @@ export function createPlaybackPlanner({
      * Throws with `error.code === "SOURCE_NOT_FOUND"` or `"FILE_NOT_FOUND"`
      * when the source or file cannot be located.
      *
+     * When the file header has not downloaded yet (cold torrent, peers still
+     * connecting) the codec probe cannot succeed. Rather than block the HTTP
+     * response until it can, the planner prioritises the header, probes for at
+     * most `maxWaitMs`, and if still undetectable returns a plan flagged
+     * `pending: true` (NOT cached). The caller polls again — each call keeps the
+     * header prioritised and downloading — until a real plan comes back. This
+     * avoids a single long request racing the transport's request timeout.
+     *
      * @param {object} params
      * @param {string} params.sourceKey
      * @param {number} params.fileIndex
      * @param {string} [params.userAgent=""]
-     * @returns {Promise<PlaybackPlan>}
+     * @param {number} [params.maxWaitMs=60000] - Max time to wait for the header within ONE call.
+     * @returns {Promise<PlaybackPlan & { pending?: boolean }>}
      */
-    async getPlan({ sourceKey, fileIndex, userAgent = "" }) {
+    async getPlan({ sourceKey, fileIndex, userAgent = "", maxWaitMs = 60_000 }) {
       const cacheKey = `${sourceKey}:${fileIndex}`;
       const cached = cache.get(cacheKey);
       if (cached) {
@@ -218,7 +227,7 @@ export function createPlaybackPlanner({
       // file, and an unsupported codec like xvid gets copied → black video.
       await torrentPool.prefetchFileEdges(torrent, fileIndex);
       let probe = await probeStreamCodecs({ ffmpegBin, inputUrl: directUrl, userAgent });
-      const probeDeadline = Date.now() + 60_000;
+      const probeDeadline = Date.now() + Math.max(0, maxWaitMs);
       let attempt = 0;
       while (
         probe.audioCodec.length === 0 &&
@@ -248,11 +257,14 @@ export function createPlaybackPlanner({
       };
       // Only cache a plan whose codecs were actually detected. An empty probe is
       // a "header not downloaded yet" signal, not a valid result — caching it
-      // would permanently mis-plan the file.
+      // would permanently mis-plan the file. In that case flag the plan
+      // `pending` so the caller polls again (the header keeps downloading,
+      // prioritised by the prefetch above).
       if (codecsDetected) {
         cache.set(cacheKey, plan);
+        return plan;
       }
-      return plan;
+      return { ...plan, pending: true };
     }
   };
 }