@torrent-tv/proxy 2.72.1 → 2.72.2

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 CHANGED
@@ -1,3 +1,9 @@
1
+ ## 2.72.2
2
+
3
+ - **Fix**: A claim for room in the piece store could never end. Two waits inside one function shared a single field for when the wait began — the wait for the disk, and the wait for a piece that may be evicted — and each of them zeroed that field on giving up, which restarted the other's clock. Measured 2026-09-03: the claim cycled for ever, five seconds per side, `grewWaitingForDisk` and `waitedForPins` each climbing once every five seconds while `blockedByPins` stayed at 0, so the refusal the store is supposed to end with was unreachable. A claim's patience is now held by the claim itself and not by the store, which is also correct with several claimants: one caller giving up used to reset the wait of every other. A claim that cannot be met now fails after 5 s — measured 5025 ms — with `Every resident piece is pinned and nothing moved`.
4
+ - **Chore**: The whole suite can finish again. `test/piece-store-reservations.test.js` did not fail on the defect above, it HUNG, so `node --test` never completed at all and no release since 2.72.0 had been covered by a full run. The three checks that drive a held disk write now carry a 30 s bound, so a return of this defect is a failure in seconds rather than a stoppage.
5
+ - **Chore**: Two further checks in that file were failing and nobody could see it, because the file stopped before reaching them. Measured on the unmodified code, both fail there identically, so neither is from this release. One asked whether the claim was waiting by reading `waitedForPins` alone, while the store was demonstrably waiting for the disk and counting `waitedForDisk`; it now accepts either. The other gave the store three blocks and then required a piece to be admitted while a block was in flight, which is a full store by the store's own accounting — it has four now, so what the check measures is what it was written for: a completing spill must not put the stale copy back on disk.
6
+
1
7
  ## 2.72.1
2
8
 
3
9
  - **Fix**: Subtitles on an embedded ASS track were shown to the viewer as the whole dialogue row — `21,0,Default,,0000,0000,0000,,I am the powerful Demon King of the Sixth Heaven.` — because one function both unwrapped the container's framing and stripped the codec's markup, and decided which framing it held by counting commas. Matroska writes eight fields before the text and takes the two timing fields out into the block's own timestamp (`matroska.org/technical/subtitles.html`); a row in a `.ass` FILE has nine and states its own column order in `[Events]`. The function expected the file's shape, found nine fields where it wanted more than nine, and returned the row untouched. The test that covered this passed because its fixture carried the file's two timestamps — a shape that never occurs on that path.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@torrent-tv/proxy",
3
- "version": "2.72.1",
3
+ "version": "2.72.2",
4
4
  "description": "Torrent proxy client that exposes webseed-like HTTP stream endpoint.",
5
5
  "license": "GPL-3.0-or-later",
6
6
  "publishConfig": {