@torrent-tv/proxy 2.9.67 → 2.9.68
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 +4 -0
- package/package.json +1 -1
- package/services/hls-session-manager.js +9 -12
package/CHANGELOG.md
CHANGED
|
@@ -1,3 +1,7 @@
|
|
|
1
|
+
## 2.9.68
|
|
2
|
+
|
|
3
|
+
- **Fix**: A seek could be dragged back to the position the viewer had just left. The encoder start was pulled down to the lowest segment the player had outstanding — a stand-in from when the distance to the preceding keyframe was unknown — but at seek time those requests still describe where the player was PLAYING, not where it is going. Field 2026-08-02: a seek to 23:34 (#135) correctly resolved to a start of #134, then got pulled to **#82** (14:15, the position just left) and crawled forward from there. Removed: since boundaries became real keyframes (2.9.65), exactly one segment back always suffices, so the pull has nothing left to correct for.
|
|
4
|
+
|
|
1
5
|
## 2.9.67
|
|
2
6
|
|
|
3
7
|
- **Fix**: A seek waited far longer than it needed to — 56 s measured in the field, of which roughly 50 s was self-inflicted. `SEEK_BACKOFF_SEGMENTS` (how far before the requested segment the encoder starts) was **12**, chosen when segments were an invented 4 s apart and the distance to a usable keyframe was unknown. Since 2.9.65 every boundary IS a real keyframe read from the container index, so the single preceding segment is guaranteed to start on one — and with real 10.43 s segments the old value meant encoding **125 s of content** before reaching the viewer position. Lowered to **1**. Observed: the encoder started at #332 for a seek to #344 and the requested segment only arrived 56 s later, while every segment after it was served in ~100 ms.
|
package/package.json
CHANGED
|
@@ -2244,18 +2244,15 @@ export class HlsSessionManager {
|
|
|
2244
2244
|
: producedThisRun >= this.segmentDurationSec
|
|
2245
2245
|
? `run produced ${producedThisRun.toFixed(1)}s (first segment done)`
|
|
2246
2246
|
: `grace of ${RUN_FIRST_SEGMENT_GRACE_MS / 1000}s expired`;
|
|
2247
|
-
//
|
|
2248
|
-
//
|
|
2249
|
-
//
|
|
2250
|
-
|
|
2251
|
-
|
|
2252
|
-
|
|
2253
|
-
|
|
2254
|
-
|
|
2255
|
-
|
|
2256
|
-
`(lowest segment the player is waiting on)`
|
|
2257
|
-
);
|
|
2258
|
-
}
|
|
2247
|
+
// Deliberately NOT pulled towards the lowest segment the player is waiting
|
|
2248
|
+
// on. That was a stand-in for not knowing how far back the preceding
|
|
2249
|
+
// keyframe lay, and it is now both unnecessary and harmful: boundaries are
|
|
2250
|
+
// real keyframes (2.9.65), so exactly one segment back always suffices,
|
|
2251
|
+
// while the player's outstanding requests at seek time still describe where
|
|
2252
|
+
// it was PLAYING, not where it is going. Field 2026-08-02: a seek to #135
|
|
2253
|
+
// was dragged back to #82 — the position the viewer had just left — because
|
|
2254
|
+
// the player was still fetching around it.
|
|
2255
|
+
const effectiveTarget = target;
|
|
2259
2256
|
session.seekTarget = null;
|
|
2260
2257
|
session.seekFirstFarAt = 0;
|
|
2261
2258
|
session.lowestAwaitedIndex = -1;
|