@torrent-tv/proxy 2.80.1 → 2.80.3

package/CHANGELOG.md

@@ -1,4 +1,13 @@
-## 2.81.0
+## 2.80.3
+
+- **Fix**: A boundary carries the keyframe it IS, instead of being looked up by value in the container's list. A cut is kept on the player's clock — `keyframe - startTime`, rounded to six places — and the seek used to add the start time back and search the file's own keyframes for the result. That round trip is lossy: a keyframe at 26.234 s in a container starting at 0.083 s comes back as 26.233999999999998, and "the keyframe at or before that" is then the PREVIOUS one. Two parts in a quadrillion became 8.717 seconds. Where each cut is on the file's own clock is now carried by index (`output/cut-grid.js`, `Timeline.sourceTimes`) and asked for directly, so a boundary cannot fail to find itself.
+- **Fix**: A run on the source's keyframe grid is given no output-side trim. Beside `-copyts` that trim does the opposite of what it says: measured 2026-09-06 on a file with a 5 s keyframe interval, a run that landed at 15 s and was told to trim to the cut at 20 s produced its first piece starting at 10 s, and one told to trim to 17 s produced cuts at 13.129, 18.129, 23.129 — the whole grid moved back by the trim itself. The muxer's cut times are absolute under `-copyts` while the trim is not, so every cut of the run inherits the difference while the numbering, fixed when the process starts, does not.
+- **Fix**: Those two together are why a film would not start on 2026-09-05. The run was asked for segment #36 at 247.873 s, landed at 230.439 s — one keyframe from each fault — and its pieces were named #36, #37, #38 while carrying film 17.4 s earlier: the proxy's own log said `segment #41 carries 267.976s while the playlist the player holds says 283.283s`, six times over. The soundtrack's run did the same with its own numbers, and the two tracks ended up with different holes. The player's picture buffer covered the playhead at 251.7 s; its sound buffer read `230.465..245.398` and `262.827..308.289` — a 17.4 s hole exactly across it. What a player can play is the overlap of the two, so nothing was playable, the cushion stood at 0.0 s for two minutes, and the viewer was told the proxy had sent no video. Every segment had in fact been delivered.
+- **Chore**: Where a file is cut is decided in `services/output/cut-grid.js`, which is the layer that owns cutting; `hls-session-manager.js` is 48 lines shorter for it.
+
+## 2.80.2
+
+- **Chore**: The same code as 2.80.1, republished. The release command ran twice when the session it was started from was interrupted, so both versions carry exactly the change described below; 2.80.2 is what `latest` points at.
 
 - **Fix**: Three encoders were started on one track within 200 ms, each into the road another was already writing, and the film came apart. Field 2026-09-05: fifteen readers on a piece store that holds sixteen pieces, half of all evictions taking a piece a reader had declared it wanted, two thirds of reads coming back from disk — and then `/stream` handing out bytes that were not the file's, twenty-two source-parse errors from ffmpeg at scattered offsets, a segment the player could not append, and an empty picture for six minutes while the proxy went on encoding. The placement rule was the cause: an encoder was put at the first unmade piece of the most urgent band, which is always the piece the working encoder is about to write.
 - **Fix**: One encoder's work now ends where the next one's begins. A free stretch may run to the end of the track, and an encoder given all of it walks into every stretch behind it — two LIVE encoders then write the same file names at the same time, and the file belongs to neither. That is the thing being prevented, and only that: driving through material that is already made is a legitimate outcome of the comparison, taken when encoding it again costs less than the death of this encoder plus the start of another. Bounded at the next start, two live stretches cannot overlap however the bands move. Bounding them at a band's own end was tried and is worse: a band edge travels with the viewer, so every step forward leaves a sliver just past the previous encoder and buys an encoder for it.

package/package.json

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