@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.
- package/CHANGELOG.md +8 -0
- package/bin/cli.js +4 -1
- package/package.json +1 -1
- package/services/data-channel-handler.js +638 -542
- package/services/playback-planner.js +5 -5
- package/services/webrtc-manager.js +46 -1
|
@@ -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
|
-
//
|
|
457
|
-
//
|
|
458
|
-
|
|
459
|
-
|
|
460
|
-
expectedSessionCreateMs:
|
|
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
|
-
|
|
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
|
}
|