@torrent-tv/proxy 2.9.48 → 2.9.49

package/CHANGELOG.md

@@ -1,3 +1,7 @@
+## 2.9.49
+
+- **New**: `getSessionProgress` (the transcode-session progress endpoint) now also reports `outputMbps` — the observed produced bitrate from recently completed segment files (already computed internally for the viewer-link budget check, `#checkLinkBudget`), so the browser can turn its OWN measured link throughput into a delivery-speed multiplier for the unified download/transcode/delivery playback-start ETA, the same way the transcode's own `speed` already is one.
+
 ## 2.9.48
 
 - **Fix**: The "bytes still needed to resume" figure shown while buffering could jump UP mid-poll even though nothing regressed, which read as confusing/broken. Root cause: the resume-window progress (`resumeNeededBytes`/`resumeDownloadedBytes`) was always computed against the LIVE read position, which slides forward as the file is read/transcoded further — so when the window moved past an already-downloaded piece into a fresh, never-touched one, "bytes needed" jumped up (a moving reference frame, not a real setback). `getFileStats` now accepts an optional `resumeAnchorByteStart` and always returns the byte offset the window was computed against; the browser client captures that offset on the FIRST poll of a buffering episode and sends it back on every subsequent poll of the SAME episode, so the window stays pinned to a fixed target and the figure only ever decreases as real download progress happens. Verified: with the anchor pinned, repeated polls report the same "needed" while the live read position moves with no new data, and a real download of a piece inside the frozen window correctly decreases it.

package/package.json

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

package/routes/api/transcode-sessions/progress/get.js

@@ -14,7 +14,7 @@ export async function handleApiTranscodeSessionsProgressGet(req, reply, { hlsSes
     return reply.code(400).send({ error: "sessionId is required." });
   }
 
-  const progress = hlsSessionManager.getSessionProgress(sessionId);
+  const progress = await hlsSessionManager.getSessionProgress(sessionId);
   if (!progress) {
     return reply.code(404).send({ error: "Transcode session was not found." });
   }

package/services/hls-session-manager.js

@@ -1970,9 +1970,9 @@ export class HlsSessionManager {
    * Also refreshes `lastAccessedAt` to prevent the session from expiring.
    *
    * @param {string} sessionId
-   * @returns {object | null}
+   * @returns {Promise<object | null>}
    */
-  getSessionProgress(sessionId) {
+  async getSessionProgress(sessionId) {
     if (!isSafeSessionId(sessionId)) {
       return null;
     }
@@ -1990,6 +1990,13 @@ export class HlsSessionManager {
     const warmupRemainingSeconds = isWarmupPhase
       ? Math.max(0, warmupTotalSeconds - warmupElapsedSeconds)
       : null;
+    // Observed OUTPUT bitrate (Mbit/s) from recently completed segment sizes —
+    // already computed for the viewer-link budget check (#checkLinkBudget); also
+    // exposed here so the browser can turn its OWN measured link throughput into
+    // a "content-seconds delivered per wall-clock second" rate for the unified
+    // three-stage ETA (download / transcode / delivery), the same way the
+    // transcode's own `speed` already is one. Null when not enough segments yet.
+    const outputMbps = await this.#observedStreamMbps(session);
     return {
       sessionId: session.id,
       state: session.progress.state,
@@ -2005,6 +2012,7 @@ export class HlsSessionManager {
       // of a percentage of the whole-file transcode.
       segmentDurationSec: this.segmentDurationSec,
       speed: session.progress.speed,
+      outputMbps,
       updatedAt: session.progress.updatedAt,
       error: session.state === "failed" ? session.lastError : ""
     };