@torrent-tv/proxy 2.69.0 → 2.69.1

package/CHANGELOG.md

@@ -1,3 +1,10 @@
+## 2.69.1
+
+- **Fix**: The change trigger on the torrent worker's memory line watched the one figure that does not move. A thread's watched quantity was `heapTotal`, and through the session of 2026-09-02 that stood at 31-173 MB while the same isolate's `arrayBuffers` swung between 130 and 950 MB — so nothing ever earned a line and every reading of the quantity that grew came out on the quiet minute. Each of `heapTotal`, `external` and `arrayBuffers` is now compared against its own last written value and any one of them moving writes the line. Nothing is summed: `arrayBuffers` is documented as part of `external` and reads larger than it here, and this code has no business resolving that.
+- **Fix**: The process line was read once a minute, which cannot see what kills this process. Both out-of-memory kills of 2026-09-02 fell inside a single gap of that cadence — the last line before the first said `rss=602MB` and the kernel recorded `anon-rss:1722836kB` 34 seconds later; before the second it said `rss=1171MB` and the kernel recorded `anon-rss:1905024kB` nine seconds later. The figure is read every second now and written when `rss` has moved by 25 MB or when a quiet minute is up, so a rise of a gigabyte is a curve instead of one number and then a death.
+- **Chore**: A quiet second costs one call to `process.memoryUsage()`. Every /proc read — `meminfo`, `smaps_rollup`, `smaps`, the free-space call — moved behind the decision to write, where only `smaps` already was. The `high rss … watch for OOM` warning moved with them, or at one reading a second it would have printed a line a second for as long as the process stayed large.
+- **Chore**: The piece-buffer counters are on the memory line itself rather than on a timer of their own. Both sides read them at the same instant now — the worker's own buffers beside its `arrayBuffers`, and the ones handed to the main thread beside the process's `rss`. On separate timers they were up to a minute apart: 950 MB of `arrayBuffers` at 14:10:40 could only be checked against readings half a minute either side saying 14 and 130 buffers were alive, and the arithmetic did not close. `watchedFigures` is exported and pinned, with two checks in `test/memory-budget.test.js`.
+
 ## 2.69.0
 
 - **Fix**: The language detector no longer states an answer the text cannot support. Measured 2026-09-02 over Wikipedia extracts in seventeen languages, 120 random windows per language per length: franc's answer for Russian walks between Bulgarian, Serbian and Russian until about 650 characters, while Korean is settled by 40 and English by 130 — the figure is the language's own, because Russian competes with three neighbours for the same trigrams and Korean competes with nothing. The detector now asks franc for a candidate, refuses when the text is shorter than THAT candidate's measured figure, and refuses again when the answer does not survive losing either half of the text. The margin to the runner-up was tried first and rejected on measurement: it is 0.026 where the answer is wrong and 0.015 where it is right, so it separates nothing. `research/franc-boundary-2026-09-02.md`.