@torrent-tv/proxy 2.30.1 → 2.30.2

package/CHANGELOG.md

@@ -1,3 +1,8 @@
+## 2.30.2
+
+- **Fix**: The cut-time shift of 2.28.0 is reverted — the field measured it and it moved the cuts OFF the source's keyframes rather than onto them. Of 75 pieces the picture produced afterwards, only **nine** began at a time the container's own table names, against **70 of 75** for the soundtrack, which the change never touched; the median distance from the playlist went from 0.04 s to 4.33 s. Before it, every piece began exactly on a named keyframe and it was the playlist that disagreed with them — which is the correction path's business, not the cut list's. The reasoning that produced the shift (that the muxer decides its cuts before the output is relabelled) was argued from ffmpeg's semantics rather than measured, and the measurement says otherwise.
+- **Fix**: The steering line compared two different things. `steered onto N of M holders` summed the successes over every attempt of a wait while taking M from the last attempt alone, which is how the log came to read `steered onto 12 of 6 holders`. Both halves are now totals over the same attempts: `steered onto N of M asks (K peers held it)`.
+
 ## 2.30.1
 
 - **Fix**: A seek was undone a second after it was made. Measured 2026-08-17: the viewer jumped to 2083.4 s, both runs restarted at segment #373 — correctly — and then a request for #371, issued by the player BEFORE the jump and reissued a second later, dragged the encoder back to #370. The viewer sat at #374 waiting for it to return. Two things let that happen, and both are fixed. The behind-head repair refuses a request that is behind the position the VIEWER themselves reported: its existing guard only holds while a seek is still settling, which by then it was not. And a segment request may no longer move the recorded viewer position BACKWARDS past a reported seek — playback only ever moves forward from one, so nothing legitimate is lost, while a stale request can no longer rewrite the viewer's own statement, which is how the repair came to believe it. A reported seek is the viewer stating where they are; a request is evidence about where the player is reading, and evidence may refine a statement forward, never contradict it backwards. Pinned by `test/stale-request-after-seek.test.js`, whose control case shows the same traffic still repairing a genuinely misplaced run when the viewer has said nothing.

package/package.json

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

package/services/hls-session-manager.js

@@ -3567,30 +3567,22 @@ export class HlsSessionManager {
     const gridCutTimes = explicitTimes && (!session.transcodeVideo || session.cutGrid === "keyframe")
       ? segmentCutTimesFrom(session.segmentBoundaries, safeIndex)
       : null;
-    // On the COPY branch the muxer decides its cuts against the source's own
-    // timestamps, not against the labels we ask it to write. That branch keeps
-    // the source's timestamps (`-copyts`) and re-labels the output 0-based with
-    // `-output_ts_offset -sourceStartTime`; the cut list, being applied before
-    // that relabelling, must therefore be stated in the SOURCE's terms.
+    // Cut times are stated on the grid, for both branches.
     //
-    // Measured 2026-08-17, and this is the whole of the trouble: asked to cut
-    // at 808.808 s on the 0-based grid, ffmpeg cut at 806.806 s — exactly
-    // `sourceStartTime` (2.002 s) early, and 806.806 s is itself a keyframe the
-    // container's table names, which is why every "disagreement" landed on
-    // another real keyframe. The soundtrack, which is re-encoded and takes the
-    // other branch, cut where it was asked. The two then told the shared
-    // boundary table different things and corrected each other back and forth
-    // for the whole session (#202: 808.808 → 806.806 → 808.750 → …), so the
-    // playlist and the media drifted apart by a whole segment and the player
-    // refetched what it could not place.
+    // 2.28.0 added `sourceStartTime` to them on the copy branch, reasoning that
+    // the muxer decides its cuts before the output is relabelled. The field
+    // measured it the next session and the reasoning was wrong: of 75 pieces
+    // the picture produced, only NINE began at a time the container's own
+    // keyframe table names (the soundtrack, untouched by the change, scored 70
+    // of 75). Before it, every piece began exactly on a named keyframe and it
+    // was the PLAYLIST that disagreed with them. So the shift moved the cuts
+    // OFF the keyframes rather than onto them, and it is gone.
     //
-    // Nothing here is a guess about ffmpeg's semantics: the shift is the same
-    // one the seek already applies on this branch (`seekSeconds = startSeconds
-    // + sourceStartTime`), and the field measurement above is what says the
-    // cuts needed it too.
-    const cutTimes = gridCutTimes && onKeyframeGridFor(session) && sourceStartTime !== 0
-      ? gridCutTimes.map((time) => Number((time + sourceStartTime).toFixed(6)))
-      : gridCutTimes;
+    // What remains true, and is what that measurement is really about: the
+    // picture cuts where the source's keyframes are, and the playlist must be
+    // built from those same times. That is the correction path's job, not the
+    // cut list's.
+    const cutTimes = gridCutTimes;
 
     // A second chance for a predecessor that survived the escalation above —
     // the first block is the one that does the work. Its exit is ignored

package/services/torrent-worker/fastest-wires.js

@@ -87,7 +87,7 @@ function speedOf(wire) {
  * @param {object} torrent
  * @param {number} pieceIndex
  * @param {number} [limit] - How many wires to push it onto.
- * @returns {{ asked: number, considered: number, fastestBytesPerSecond: number }}
+ * @returns {{ asked: number, attempted: number, considered: number, fastestBytesPerSecond: number }}
  *   `asked` counts requests the library actually placed: it refuses when a
  *   wire's pipeline is full or when nothing can be reserved even with hotswap,
  *   and that refusal is information — a piece nobody can be asked for is
@@ -95,7 +95,7 @@ function speedOf(wire) {
  */
 export function askFastestWiresFor(torrent, pieceIndex, limit = 3) {
   if (!canPlaceRequests(torrent) || !Number.isInteger(pieceIndex) || pieceIndex < 0) {
-    return { asked: 0, considered: 0, fastestBytesPerSecond: 0 };
+    return { asked: 0, attempted: 0, considered: 0, fastestBytesPerSecond: 0 };
   }
   const candidates = wiresForPiece(torrent, pieceIndex);
   let asked = 0;
@@ -116,6 +116,13 @@ export function askFastestWiresFor(torrent, pieceIndex, limit = 3) {
   return {
     asked,
     considered: candidates.length,
+    // How many of the asks the library placed, against how many it was asked
+    // for. The caller sums these over the whole wait, and summing `asked`
+    // against a `considered` taken from the LAST attempt is how the field log
+    // came to read "steered onto 12 of 6 holders" — a ratio of two different
+    // things. Both halves are returned per attempt so the caller can add each
+    // to its own total.
+    attempted: Math.min(candidates.length, Math.max(1, limit)),
     fastestBytesPerSecond: candidates.length > 0 ? speedOf(candidates[0]) : 0
   };
 }

package/services/torrent-worker/piece-reader.js

@@ -517,12 +517,15 @@ export async function* readFragments({
       // holder delivers — measured 2026-08-17, the swarm had a fivefold surplus
       // of bandwidth and the reader still waited 1.0-4.5 s, 47 times in two
       // minutes, on pieces five peers already had.
-      let pushed = { asked: 0, considered: 0, fastestBytesPerSecond: 0 };
+      let pushed = { asked: 0, attempted: 0, considered: 0, fastestBytesPerSecond: 0 };
       const pushToFastest = () => {
         try {
           const result = askFastestWiresFor(torrent, pieceIndex);
           pushed = {
             asked: pushed.asked + result.asked,
+            // Summed like the successes, so the line compares two totals over
+            // the same attempts instead of a total against a snapshot.
+            attempted: (pushed.attempted ?? 0) + result.attempted,
             considered: result.considered,
             fastestBytesPerSecond: result.fastestBytesPerSecond
           };
@@ -592,7 +595,7 @@ export async function* readFragments({
             // What WE did about it, so the next session says whether steering
             // the piece onto faster holders shortens the tail — by number
             // rather than by impression.
-            `; steered onto ${pushed.asked} of ${pushed.considered} holders` +
+            `; steered onto ${pushed.asked} of ${pushed.attempted} asks (${pushed.considered} peers held it)` +
             (pushed.fastestBytesPerSecond > 0
               ? `, fastest ${Math.round(pushed.fastestBytesPerSecond / 1024)}KB/s`
               : "")

package/test/fastest-wires.test.js

@@ -97,7 +97,7 @@ test("a build without the request entry is reported, not silently skipped", () =
   assert.equal(canPlaceRequests({ wires: [] }), false);
   assert.equal(canPlaceRequests({ wires: [], _request: () => true }), true);
   const result = askFastestWiresFor({ wires: [wire({ speed: 1 })] }, 1);
-  assert.deepEqual(result, { asked: 0, considered: 0, fastestBytesPerSecond: 0 });
+  assert.deepEqual(result, { asked: 0, attempted: 0, considered: 0, fastestBytesPerSecond: 0 });
 });
 
 test("a wire that cannot say how fast it is ranks last rather than throwing", () => {