@torrent-tv/proxy 2.61.0 → 2.63.0

package/CHANGELOG.md

@@ -1,3 +1,15 @@
+## 2.63.0
+
+- **New**: The piece store says what it has TAKEN, not only what it holds. `committed` and `on-disk` stand beside `resident` in its line. The two are different quantities and the difference is the growth that had no explanation: the pool only ever grows — `SharedArrayBuffer` has no shrink — so a piece spilled to disk returns its slot to the free list and its memory to nobody. On 2026-08-28 the store reported "144MB" while the process held 893 MB.
+- **New**: The torrent worker reports its OWN isolate's memory. The piece pool is a `SharedArrayBuffer` allocated there, so the main thread's `arrayBuffers` cannot see it however carefully it is read — which is why the main line said `no torrent stores` in the same second the worker logged a live one. `rss` and the kernel's rollup stay on the main line, because they belong to the process and are read once.
+- **New**: The process line carries `anon` from `/proc/self/smaps_rollup` and the free space where pieces spill. What neither isolate claims is now visible, and both limits are measured rather than declared — a budget for memory alone is half a budget when the overflow goes to a card the host boots from.
+- **Fix**: A store's allowance follows the machine instead of being settled at birth. It was `MemAvailable` divided between the stores at the moment one was created, so a store opened on an idle machine kept an idle machine's allowance for life and went on growing while everything else competed for what was left. It is re-derived every minute, within the reservation the store was created with (`maxByteLength` was fixed from that and `grow()` cannot pass it). Lowering it frees nothing already committed — the pool cannot shrink — but it stops the growth, sends those pieces to disk, and says so in the log when a store is already past its new allowance.
+- **Fix**: The delivery probe no longer calls a healthy connection stopped. Its allowance had one load-dependent term, our own send queue, and that queue is empty by construction — it drains the moment libdatachannel accepts the bytes, whether or not usrsctp then puts them on the wire. So a browser filling its cushion showed an empty queue, a small allowance and a large gap, which reads exactly like a stopped association: four `association-stopped` in the first two minutes of a healthy session on 2026-08-28, and deepening the cushion from 30 s to 120 s had made that burst four times longer. The browser reports its own transport-level received total with every echo, so the question is now answered by a counter rather than a threshold: while that total is advancing, bytes are crossing and no verdict of a stopped association stands. A browser that does not report it is judged exactly as before.
+
+## 2.62.0
+
+- **New**: Each session says what its cushion actually is, every half minute: how many seconds of film are ready ahead of the EARLIEST viewer's picture, roughly how many megabytes that is off the swarm, and how deep a buffer the browsers say they are holding. The three were never printed together and could not be reconstructed afterwards from anything that was — so whether deepening the browser's buffer (2.61.0) protected anybody, and what it cost the person hosting the proxy, had no answer. Every term is measured: the produced range from the segments on disk, the picture from the viewers' own reports, the byte rate from the file's length over its duration. The read window sits on top of the megabytes figure, so it is a floor.
+
 ## 2.61.0
 
 - **New**: The proxy states how far ahead of the viewer it lets an encoder run — `lookaheadSeconds` on the session-create response. The browser sizes its forward buffer from it, so the two sides agree by construction instead of each carrying a figure of its own: the browser held 30 s, with a ceiling of 60, while this proxy keeps 120 s produced and suspends the encoder there. Three quarters of the protection against every interruption was left on the disk.