@torrent-tv/proxy 2.80.7 → 2.80.8
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/encode/EncodePlan.js +1104 -1104
- package/services/orchestrators/EncodeOrchestrator.js +15 -0
package/CHANGELOG.md
CHANGED
|
@@ -1,3 +1,7 @@
|
|
|
1
|
+
## 2.80.8
|
|
2
|
+
|
|
3
|
+
- **Chore**: A run being moved says what it was moved FROM, not only that it was — the plan's own explanation of a move is a sentence, never the windows or the budget it was decided from. Field 2026-09-07: one output's encoder alternated between a viewer's own position and an old, already-passed segment, dozens of times in ten seconds, with nothing recorded beyond the words "scores worse than standing at #N" repeated each time. `EncodeOrchestrator` now logs, on every move, the exact windows the plan saw (priority, the real time behind them, which side of the viewers they lie on), the budget it was working inside, and where every live run stood — everything the next occurrence needs to be read from the log instead of guessed at.
|
|
4
|
+
|
|
1
5
|
## 2.80.7
|
|
2
6
|
|
|
3
7
|
- **Fix**: The piece store's memory floor, re-derived every time the machine's free memory changes, took the widest single reader's declared window (`demand.widestPieces`) as its lower bound instead of what every live reader together needs (`demand.unionPieces`) — right for one reader, wrong for several. Field 2026-09-07: three concurrent readers of one file — the picture, the sound, and the edge-warming read — each declared their own window; the floor guaranteed room for only the widest of the three, so once residents filled that smaller number, every resident piece belonged to some reader's still-live window and none could be evicted. `Every resident piece is pinned and nothing moved for 5000ms; no slot can be freed`, which is not our own failure — it reaches WebTorrent's own `store.put()` callback, and WebTorrent treats any error there as fatal and destroys the torrent outright: `torrent.files` went to `[]`, every later read answered `File N not found in torrent:<hash>`, and the session never recovered. `wantedBytes` in the same file already asked the machine for the union, correctly; the floor below which the store refuses to shrink now asks for the same thing.
|