@torrent-tv/proxy 2.9.112 → 2.9.113

package/CHANGELOG.md

@@ -1,3 +1,7 @@
+## 2.9.113
+
+- **New**: The transport's own counters are written to the log for as long as a channel is open, not only when its send queue backs up. The queue was the wrong thing to watch: field 2026-08-06, a 9.26 MB segment was accepted by the transport with `maxBuffered=0 bufferedAtEnd=0` and reported as sent at 274 Mbit/s, and it never arrived — after which everything the proxy sent vanished the same way while requests kept arriving in the other direction. With nothing ever queued the existing watcher never woke, so the one question that decides the cause — did those bytes leave the machine — had no answer in the log. Every five seconds it now records bytes sent and received by the transport itself, the queue depth, the round-trip time, and the path in use. The browser records the matching figures on the same cadence (server 0.8.110), so a recurrence is settled by subtracting one line from the other rather than by reasoning.
+
 ## 2.9.112
 
 - **New**: A session whose data went away now waits for it to come back instead of dying. Losing the input is not the session failing — the torrent can be added again and the pieces downloaded again — but a run that died that way marked the session terminal, and every request for the playlist answered 500 from then on, although the swarm was right there and the data would have returned in seconds. Such a run is now retried at the position the viewer is waiting at, backing off from 2 s to at most 15 s so a source that is genuinely unavailable costs a process every few seconds rather than continuously, and the requests being held are simply held: nothing is broken and there is nothing for the viewer to retry. The circuit breaker stays for what it was built for — a target that truly cannot be encoded — and no longer condemns a session that merely lost its data. Which of the two happened is decided by the message, tested against the exact ones the field produced.

package/package.json

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

package/services/data-channel-handler.js

@@ -107,8 +107,42 @@ function makeSendQueueWatcher({ log, getTransportSnapshot }) {
     let lowestSinceDrain = Number.POSITIVE_INFINITY;
     let stuckSince = 0;
     let previous = null;
+    // Independent of the queue: the transport's own counters, sampled for as
+    // long as the channel is open. The queue was the wrong thing to watch —
+    // field 2026-08-06, a 9.26 MB segment was accepted by the transport with
+    // `maxBuffered=0 bufferedAtEnd=0`, reported as sent at 274 Mbit/s, and
+    // never arrived; everything the proxy sent from that moment on was lost the
+    // same way while requests kept coming the other direction. With nothing
+    // queued this watcher never woke, so the one question that matters — did
+    // those bytes leave the machine — has no answer in the log. It does now.
+    let heartbeatPrevious = null;
+    let heartbeatAt = 0;
 
     const timer = setInterval(() => {
+      const sampledAt = Date.now();
+      if (sampledAt - heartbeatAt >= TRANSPORT_HEARTBEAT_MS) {
+        heartbeatAt = sampledAt;
+        const snapshot = getTransportSnapshot?.(sessionId) ?? null;
+        if (snapshot) {
+          const sent = heartbeatPrevious ? snapshot.bytesSent - heartbeatPrevious.bytesSent : null;
+          const received = heartbeatPrevious
+            ? snapshot.bytesReceived - heartbeatPrevious.bytesReceived
+            : null;
+          heartbeatPrevious = snapshot;
+          let depth = 0;
+          try {
+            depth = typeof channel.bufferedAmount === "function" ? channel.bufferedAmount() : 0;
+          } catch {
+            depth = -1;
+          }
+          log(
+            `[dc-transport] ${tag} "${label}" sent=${snapshot.bytesSent}` +
+            `${sent === null ? "" : ` (+${sent})`} received=${snapshot.bytesReceived}` +
+            `${received === null ? "" : ` (+${received})`} queued=${depth}B ` +
+            `rtt=${snapshot.rtt}ms pc=${snapshot.state} ice=${snapshot.iceState} pair=${snapshot.pair}`
+          );
+        }
+      }
       let queued = 0;
       try {
         queued = typeof channel.bufferedAmount === "function" ? channel.bufferedAmount() : 0;
@@ -630,6 +664,10 @@ const PARTIAL_REQUEST_TTL_MS = 60_000;
 // well under a second on the LAN — and short enough that a stuck channel is
 // named while the viewer is still looking at it.
 const SEND_QUEUE_SAMPLE_MS = 1_000;
+// How often the transport's own counters are written to the log, whatever the
+// send queue is doing. Frequent enough to place a loss within a few seconds,
+// sparse enough that a two-hour film costs a few hundred lines.
+const TRANSPORT_HEARTBEAT_MS = 5_000;
 const SEND_QUEUE_STUCK_MS = 5_000;
 const DC_BUFFER_HIGH_WATER = 8 * 1024 * 1024;
 /** Resume sending once the channel buffer drains to this many bytes. */