@torrent-tv/proxy 2.9.106 → 2.9.108

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -453,11 +453,11 @@ export function createPlaybackPlanner({
453
453
  // Full track inventory for the browser's audio/subtitle menus.
454
454
  audioTracks: audioTracks ?? [],
455
455
  subtitleTracks: subtitleTracks ?? [],
456
- // What this host has recently taken to make a session's first segment.
457
- // Null until one has finished since startup.
458
- expectedFirstSegmentMs: firstSegmentMs,
459
- // Second term of the browser's estimate; see research/playback-eta-2026-08-05.md.
460
- expectedSessionCreateMs: sessionCreateMs
456
+ // Both host timings are filled in by `withHostTimings` on the way out,
457
+ // never here: read at build time they would be frozen into the cached
458
+ // plan, which is the bug fixed in 2.9.106.
459
+ expectedFirstSegmentMs: null,
460
+ expectedSessionCreateMs: null
461
461
  };
462
462
  // Only cache a plan whose codecs were actually detected. An empty probe is
463
463
  // a "header not downloaded yet" signal, not a valid result — caching it
@@ -429,5 +429,50 @@ export function createWebRtcManager({ sendSignal, onDataChannel, onLog, udpPort,
429
429
  }
430
430
  }
431
431
 
432
- return { handleSignal, closeSession, dispose };
432
+ /**
433
+ * What the transport itself is doing for one session.
434
+ *
435
+ * The discriminator for a send queue that stops draining. `bufferedAmount`
436
+ * alone says only that bytes are stuck in OUR queue; these say whether they
437
+ * are leaving the machine:
438
+ *
439
+ * - `bytesSent` climbing while the queue climbs → packets ARE going out and
440
+ * nothing is acknowledging them: the path back is broken.
441
+ * - `bytesSent` flat while the queue climbs → SCTP is not transmitting at
442
+ * all: the peer's receive window is closed, or congestion control has
443
+ * collapsed. `bytesReceived` still climbing at the same time proves the
444
+ * peer is alive and its packets still reach us, i.e. the failure is
445
+ * one-directional.
446
+ * - both flat → nothing crosses in either direction.
447
+ *
448
+ * @param {string} sessionId
449
+ * @returns {{ bytesSent: number, bytesReceived: number, rtt: number, pair: string, state: string, iceState: string } | null}
450
+ */
451
+ function getTransportSnapshot(sessionId) {
452
+ const pc = peers.get(sessionId);
453
+ if (!pc) {
454
+ return null;
455
+ }
456
+ const read = (fn, fallback) => {
457
+ try {
458
+ return fn();
459
+ } catch {
460
+ return fallback;
461
+ }
462
+ };
463
+ const pair = read(() => pc.getSelectedCandidatePair(), null);
464
+ return {
465
+ bytesSent: read(() => pc.bytesSent(), -1),
466
+ bytesReceived: read(() => pc.bytesReceived(), -1),
467
+ rtt: read(() => pc.rtt(), -1),
468
+ pair: pair
469
+ ? `${pair.local?.address}:${pair.local?.port}->${pair.remote?.address}:${pair.remote?.port}` +
470
+ ` (${pair.local?.type}/${pair.remote?.type})`
471
+ : "none",
472
+ state: read(() => pc.state(), "?"),
473
+ iceState: read(() => pc.iceState(), "?")
474
+ };
475
+ }
476
+
477
+ return { handleSignal, closeSession, dispose, getTransportSnapshot };
433
478
  }