@torrent-tv/proxy 2.9.107 → 2.9.109

package/services/hls-session-manager.js

@@ -137,7 +137,17 @@ const MAX_SEEK_FAILURES = 3;
 // look-ahead cap when idle, so a lingering session costs retained segments on
 // disk, not sustained CPU. Active playback refreshes the timer on every segment
 // fetch, so it never expires mid-watch.
-const DEFAULT_SESSION_TTL_MS = 10 * 60 * 1000;
+// How long a session outlives the BROWSER, not the viewing. Since server
+// 0.8.103 a browser that holds a session re-asserts it every 30 s, so an open
+// tab never consumes this at all — not while paused, not across a three-hour
+// film. What is left is the case where the browser has genuinely gone: the tab
+// was killed without releasing, the phone slept, the network dropped. Keeping
+// the session means such a viewer comes back to a warm encoder instead of
+// waiting out a cold start; the cost while nobody is there is disk for the
+// produced segments, since the encoder is suspended and burns no CPU, and that
+// disk is already bounded by the pool's 10 GB cap with eviction. Thirty minutes
+// covers a meal, a phone call or a lift ride.
+const DEFAULT_SESSION_TTL_MS = 30 * 60 * 1000;
 const DEFAULT_STARTUP_WAIT_MS = 5_000;
 // Realtime budget — runtime downswitch (software encoder only). Periodically
 // check each active software-transcode session's ffmpeg `speed`; when it stays

package/services/webrtc-manager.js

@@ -429,5 +429,50 @@ export function createWebRtcManager({ sendSignal, onDataChannel, onLog, udpPort,
     }
   }
 
-  return { handleSignal, closeSession, dispose };
+  /**
+   * What the transport itself is doing for one session.
+   *
+   * The discriminator for a send queue that stops draining. `bufferedAmount`
+   * alone says only that bytes are stuck in OUR queue; these say whether they
+   * are leaving the machine:
+   *
+   *  - `bytesSent` climbing while the queue climbs → packets ARE going out and
+   *    nothing is acknowledging them: the path back is broken.
+   *  - `bytesSent` flat while the queue climbs → SCTP is not transmitting at
+   *    all: the peer's receive window is closed, or congestion control has
+   *    collapsed. `bytesReceived` still climbing at the same time proves the
+   *    peer is alive and its packets still reach us, i.e. the failure is
+   *    one-directional.
+   *  - both flat → nothing crosses in either direction.
+   *
+   * @param {string} sessionId
+   * @returns {{ bytesSent: number, bytesReceived: number, rtt: number, pair: string, state: string, iceState: string } | null}
+   */
+  function getTransportSnapshot(sessionId) {
+    const pc = peers.get(sessionId);
+    if (!pc) {
+      return null;
+    }
+    const read = (fn, fallback) => {
+      try {
+        return fn();
+      } catch {
+        return fallback;
+      }
+    };
+    const pair = read(() => pc.getSelectedCandidatePair(), null);
+    return {
+      bytesSent: read(() => pc.bytesSent(), -1),
+      bytesReceived: read(() => pc.bytesReceived(), -1),
+      rtt: read(() => pc.rtt(), -1),
+      pair: pair
+        ? `${pair.local?.address}:${pair.local?.port}->${pair.remote?.address}:${pair.remote?.port}` +
+          ` (${pair.local?.type}/${pair.remote?.type})`
+        : "none",
+      state: read(() => pc.state(), "?"),
+      iceState: read(() => pc.iceState(), "?")
+    };
+  }
+
+  return { handleSignal, closeSession, dispose, getTransportSnapshot };
 }