@torrent-tv/proxy 2.83.5 → 2.83.7

package/bin/cli.js

@@ -85,6 +85,10 @@ program
   .option("--no-transcode-audio", "Disable optional HLS AAC audio transcoding")
   .option("--no-port-mapping", "Disable automatic UPnP/NAT-PMP port mapping")
   .option("--delivery-sink", "Serve /api/delivery-sink, a torrent-free byte stream for delivery testing")
+  .option(
+    "--send-chunk-bytes <bytes>",
+    "Size of one data-channel message when sending a response body (0 = whatever the body read hands over, ~64KB). For measuring whether the delivery wedge depends on that size."
+  )
   .option(
     "--usrsctp-state",
     "Read usrsctp's association state with gdb when a wedge is declared. OFF by default: gdb attaches to THIS process and stops every thread of it while it works."
@@ -327,7 +331,6 @@ try {
   });
   app = started.app;
   actualPort = started.port;
-  const sourceRegistry = started.sourceRegistry;
   const directBaseUrl = explicitBaseUrl || `http://${bindHost}:${actualPort}`;
 
   // A native fault writes the whole address space out — 4.18 GB each on the
@@ -546,10 +549,12 @@ try {
   dataChannelHandler = createDataChannelHandler({
     proxyPort: actualPort,
     onLog: (message) => logger.info(message),
-    // Resolves a browser's registry sourceKey to the torrent pool's own key
-    // (the content's infohash) so the subtitle push subscription and the
-    // pool's own publish agree on what a source is called. See server.js.
-    sourceRegistry,
+    // Who wants pushed subtitle cues for a file, by name. Late-bound like the
+    // rest: the registry lives on the manager, built inside `startProxyServer`
+    // with this handler already in hand. The transport gets opaque ids and
+    // never learns what a viewer is.
+    viewersWantingCues: (sourceKey, fileIndex) =>
+      started?.hlsSessionManager?.viewers?.wantingCues?.(sourceKey, fileIndex) ?? [],
     // Lets a stuck send queue ask the transport what it is doing. Late-bound:
     // the manager is created below, with this handler already in hand.
     getTransportSnapshot: (sessionId) => webRtcManager?.getTransportSnapshot(sessionId) ?? null,
@@ -557,6 +562,10 @@ try {
     // transmit death (roadmap item 10, 2026-08-24) gets its evidence.
     witness: packetWitness,
     usrsctpState: usrsctpStateReader,
+    // How large one data-channel message is. The wedge of 2026-09-12 arrived
+    // mid-message, and whether it depends on this size is the one thing no
+    // reading has settled — so it is measured rather than reasoned about.
+    sendChunkBytes: Number.parseInt(options.sendChunkBytes ?? "0", 10) || 0,
     // Presence, from the one thing that knows it. Late-bound for the same
     // reason as the transport snapshot above: the manager is built inside
     // `startProxyServer`, with this handler already in hand.

package/package.json

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

package/research/delivery-wedge-stand-ladder-2026-09-13.md

@@ -0,0 +1,329 @@
+# Клин доставки: лестница на стенде и чтение исходника usrsctp — 2026-09-13
+
+Всё ниже либо замерено на стенде, либо прочитано из исходника на закреплённом
+коммите. Где вывод не подтверждён замером, это сказано прямо.
+
+## 0. Что установлено за день, одним абзацем
+
+Клин воспроизводится по требованию — четыре прогона из четырёх — и не зависит
+ни от чего, чем мы можем управлять: ни от размера сообщения, ни от
+ненадёжного канала, ни от видимости вкладки, ни от паузы между запросами, ни от
+торрента с кодировщиком. Разбор через учёт полёта в usrsctp построен и **сам же
+опровергнут** дальнейшим чтением. Наверх заведён `sctplab/usrsctp#750` с
+воспроизведением и с поправкой. Чего по-прежнему нет — счётчиков живой
+заклинившей ассоциации.
+
+## 1. Стенд
+
+Три места, три роли:
+
+1. **хост Home Assistant** — контейнер `ttv-wedge-stand` из образа дополнения
+   `b34a1737/aarch64-addon-torrent_tv_proxy:0.74.4`, на порту 9090, с ключом
+   `--delivery-sink`. Отправитель. Своё дополнение при этом остановлено;
+2. **машина разработчика** — Chrome Canary с отладочным портом, вкладка на
+   `webauth.courses`. Внутри страницы цикл поднимает СВОЁ соединение
+   (`new WebRtcProxy(id)`) и подряд просит по 4 МБ. Приёмник и источник
+   нагрузки;
+3. **дроплет** — только сигналинг и отчёты цикла по HTTP.
+
+Выбранная пара за все прогоны: `2001:1c00:a603:2100:…:9090 -> 2001:1c00:a603:2100:…`
+(host/srflx), оба адреса в одном `/64` — то есть напрямую, внутри домашней сети,
+мимо дроплета. Это та же форма пары, что и в полевом клине 2026-09-12.
+
+Загрузчик — `stand/wedge/browser-loader.js` (в родительской папке, рядом с
+`driver.mjs`). Раньше он жил только во вкладке и пропадал вместе с ней.
+
+### Три вещи, каждая из которых стоила прогона
+
+1. **правка в контейнере дополнения не выживает.** `ha apps restart` пересоздаёт
+   контейнер из образа, а убийство процесса внутри будит watchdog, который тоже
+   пересоздаёт. Поэтому свой контейнер — watchdog его не трогает;
+2. **целиться по идентификатору, а не по имени.** Локальный стенд разработчика
+   назывался так же, и цикл подключился к нему;
+3. **отладочный порт Chrome не открывается на профиле по умолчанию** начиная со
+   136-й версии. Нужен явный `--user-data-dir`. А чтобы перекрытое окно
+   считалось видимым — `--disable-features=CalculateNativeWinOcclusion`.
+
+## 2. Лестница: четыре плеча, четыре клина
+
+| плечо | что менялось | клин | скорость |
+|---|---|---|---|
+| опорное (2026-09-12) | — | 2696 МБ | 190-325 Мбит/с |
+| `16k` | сообщение 16 КБ вместо ≈65 КБ | 1220 МБ | 43-49 Мбит/с |
+| `nofast` | без канала `proxy-fast`, вкладка видима | 288 МБ | 40-64 Мбит/с |
+| `drain` | пауза 300 мс между запросами | 5300 МБ | 34 Мбит/с |
+
+Форма приговора одинакова во всех: запрос висит 30 с и не получает ничего,
+канал при этом `open`; со стороны прокси все каналы встают на одном счётчике,
+`queued[…0B]`, `rtt` 20-30 мс, `pc=connected ice=completed`. Это форма поля
+дословно.
+
+**Разброс 288-5300 МБ, восемнадцатикратный, при одном прогоне на плечо.** Ни
+одно плечо от другого не отделено: полевой разброс сам по себе был 485-2694 МБ.
+Поэтому «пауза помогает» утверждать нельзя, хотя `drain` и прошёл дальше всех.
+
+**Чего лестница не имеет и что надо снять первым делом:** нескольких прогонов
+опорного плеча подряд. Без измеренного разброса любое плечо нечитаемо — это та
+самая ошибка, что сделана сегодня дважды.
+
+## 3. Что снято замерами
+
+1. **размер сообщения** — не влияет. Клин и на 65 КБ, и на 16 КБ. Гипотеза, ради
+   которой строился `--send-chunk-bytes`, закрыта;
+2. **ненадёжный канал `proxy-fast`** (`ordered: false, maxRetransmits: 0`) — не
+   нужен для клина. Прогон `nofast` не создавал его вовсе. Это же снимает
+   подозрение, на котором стоит открытый с 2020 года `sctplab/usrsctp#427`;
+3. **скрытая вкладка и торможение приёмника** — не при чём, `peerTab=visible`
+   весь прогон `nofast`;
+4. **пауза, дающая полёту вычерпаться** — не спасает;
+5. **торрент, кодировщик, нарезка, хранилище кусков** — не при чём, стенд отдаёт
+   синтетические байты.
+
+## 4. Чтение usrsctp `fec583d5` — и почему разбор не устоял
+
+**Что прочитано и верно:**
+
+1. `sctp_indata.c:5144` — `peers_rwnd = sctp_sbspace_sub(a_rwnd, total_flight +
+   total_flight_count * 256)`. Наше представление об окне пира — это объявленное
+   им окно МИНУС наш собственный учёт полёта;
+2. `sctp_output.c:8481` — при `peers_rwnd == 0` и `total_flight > 0` ставится
+   `no_data_chunks = 1`: данные не отправляются вовсе;
+3. `sctp_output.c:9376` — зондирование окна ставится только при
+   `total_flight == 0`;
+4. `sctp_var.h:338` — вычет учёта несимметричен: прибавка безусловна, вычет
+   только если байты сходятся, иначе оба счётчика обнуляются.
+
+Из 1-3 следует состояние, объясняющее каждый факт с провода: завышенный и не
+убывающий счётчик полёта делает окно нулевым при любом объявленном, данные не
+идут, зонда нет, ретрансмиссии нет, подтверждения обрабатываются.
+
+**Чем это опровергнуто — дальнейшим чтением того же файла.** Пустую очередь
+отправленного исправляют ТРИ места, а не одно:
+
+1. `sctp_handle_sack:4836` — ловит «очередь пуста, полёт положителен», печатает
+   предупреждение, под INVARIANTS падает, обнуляет `total_flight`;
+2. `sctp_handle_sack:5007` — обнуляет полёт по всем путям, оба счётчика, и
+   останавливает таймеры;
+3. `sctp_express_handle_sack:4226` — то же.
+
+Подтверждения во время клина приходят — это доказано проводом. Значит состояние
+«байты числятся, очередь пуста» исправлялось бы на ближайшем подтверждении и
+существовать не может.
+
+Остаётся другая форма: очередь **не** пуста, а куски на ней учтены и никогда не
+будут подтверждены. Её и стережёт `sctp_fs_audit`, и вот он затворён
+(`j == 0`, `sent_queue_retran_cnt == 0`, `win_probe_recovered == 0`,
+`done_once == 0`, плюс ранний выход при `pr_sctp_cnt >= sent_queue_cnt`). Но эта
+форма плохо ложится на провод: куски на очереди должны держать таймер
+ретрансмиссии и порождать повторы, а повторов нет 178,8 с.
+
+**Механизма, который я готов защищать, на сегодня нет.**
+
+## 5. Наверх
+
+`sctplab/usrsctp#750` — наблюдение, воспроизведение, снятые причины, вопросы,
+и отдельным сообщением поправка, снимающая разбор из раздела 4. PR не подан
+сознательно: подавать правку по опровергнутому разбору нельзя.
+
+`#427` открыт с 2020 года, сопровождающие не воспроизвели ни на FreeBSD, ни на
+usrsctp. У нас воспроизведение есть — это и есть то, чего им не хватало.
+
+## 6. Что делать дальше, по убыванию пользы
+
+1. **прочитать счётчики живой заклинившей ассоциации** — `total_flight`,
+   `total_flight_count`, `peers_rwnd`, `cwnd`, состояние очереди отправленного.
+   Единственный способ назвать причину. На БОЕВОМ прокси это однажды заморозило
+   процесс (пункт 77); **на стенде безопасно** — отдельный контейнер, зрителей
+   нет. Для этого построено плечо `hold`: оно не закрывает ассоциацию после
+   приговора, чего не делало ни одно прежнее, поэтому читать было нечего;
+2. **объявлять заклинивший канал потерянным — на ПРИЁМНИКЕ.** Детекторы прокси
+   смотрят на его очередь, а она читается нулём: байты уже отданы в usrsctp. В
+   поле 2026-09-06 прокси объявил клин на шестнадцать минут позже браузера.
+   Браузер же знает сразу: висящий запрос без единого байта, когда предыдущие
+   приходили за секунду. Порог не выбирается, а выводится из измеренного худшего
+   времени ответа этого соединения;
+3. **восстановление, и оно может быть незаметным.** Вторая ассоциация к тому же
+   пиру поднимается за 232 мс и сразу даёт 310 Мбит/с — замерено трижды. Подушка
+   зрителя 120 с. Лестница пересоединения уже есть и работает на ЗАКРЫТОМ канале
+   (поле 2026-09-12, 20:03); не срабатывает она только потому, что заклинивший
+   канал остаётся `connected`. То есть строить надо пункт 2, а не восстановление;
+4. **несколько прогонов опорного плеча** — измеренный разброс, без которого
+   лестница не читается.
+
+
+## 6.1. Попытка прочитать счётчики: сделана, не удалась, причина названа
+
+Плечо `hold` заклинило на 1436 МБ и **удержало ассоциацию открытой** — первый
+раз, когда было что читать. `gdb` в контейнере стенда есть.
+
+Четыре подключения подряд, только чтение, срок жизни задан снаружи
+(`timeout -s KILL`). Результат:
+
+1. `system_base_info` найден по адресу `0x7f5a9eb8b0` — но как символ **без
+   отладочной информации**;
+2. `ptype struct sctp_association` — `No struct type named sctp_association`;
+3. `list sctp_output.c:8481` — `No source file named sctp_output.c`.
+
+Секции `.debug_info`, `.debug_abbrev`, `.debug_str` в `node_datachannel.node`
+присутствуют, но покрывают C++ часть libdatachannel; C-модули usrsctp собраны
+без `-g`. Значит разметки структур нет, и прочитать поля по имени нельзя.
+
+**Читать по жёстко забитым смещениям — нельзя.** Смещения зависят от флагов
+сборки (`INET6`, `SCTP_DEBUG` и прочих), а ошибка в смещении даёт правдоподобное
+число, которое ничем не отличить от верного.
+
+**Отдельный результат, важный для пункта 77 роадмапа: чтение отладчиком
+безопасно.** Процесс пережил все четыре подключения и отвечает на `/healthz`.
+Губителен был не отладчик как таковой, а **вызов функции внутри исследуемого
+процесса** (`usrsctp_getsockopt`), прерванный убийством: он оставил захваченный
+замок и тупик. Правило, которое из этого следует: подключаться можно, читать
+можно, вызывать внутри процесса — нельзя.
+
+**Что осталось для этого чтения:** собрать node-datachannel с `-g` под aarch64
+и поставить в контейнер стенда. Это не форк — те же исходники, отладочная
+сборка, и только для стенда.
+
+
+## 6.2. ПРИЧИНА НАЗВАНА: таймер ретрансмиссии не запланирован
+
+Счётчики прочитаны из живой заклинившей ассоциации 2026-09-13. Это отменяет
+раздел 6.1, где сказано, что прочитать не удалось: не удавалось с поставляемым
+модулем, а с отладочной сборкой удалось.
+
+### Как получена сборка (воспроизводимо)
+
+Сборочный контейнер из образа дополнения, `apk add cmake git ninja pkgconf
+openssl-dev linux-headers`, затем:
+
+```
+git clone --depth 1 --branch v0.32.3 --recurse-submodules     https://github.com/murat-dogan/node-datachannel.git
+npm i -g cmake-js && npm i --no-save --ignore-scripts node-addon-api
+cmake-js compile --CDCMAKE_BUILD_TYPE=RelWithDebInfo --CDOPENSSL_ROOT_DIR=/usr --parallel 4
+```
+
+Две грабли: `npm ci` падает на рассинхроне замка, а нужен из всего этого только
+`node-addon-api` ради `napi.h`; и CMake не находит libcrypto, хотя он на месте —
+корень OpenSSL приходится указать явно. Получается 58 МБ с отладочной
+информацией; libdatachannel v0.24.2 и usrsctp `fec583d5` внутри — ровно те
+версии, что работают в поле.
+
+Модуль подменяется в контейнере стенда поверх поставляемого (копия рядом,
+`.orig`).
+
+### Обход структур usrsctp
+
+`system_base_info.sctppcbinfo.listhead.lh_first` → цепочка `sctp_inpcb` по
+`sctp_list.le_next`; у каждого `sctp_asoc_list.lh_first` → цепочка `sctp_tcb`
+по `sctp_tcblist.le_next`; у каждого `asoc`, и пути по `asoc.nets` через
+`sctp_next.tqe_next`. Сценарии — `/tmp/sctp.gdb` и `/tmp/sctp3.gdb` в контейнере
+стенда. `ticks` — статическая в `sctp_callout.c`, по имени не берётся.
+
+### Что прочитано
+
+Клин на 2356 МБ, ассоциация удержана открытой плечом, которое не закрывает её
+после приговора:
+
+```
+TCB state=8 flight=95786 fcount=82 rwnd=4572914 sentq_cnt=82 sendq_cnt=0
+    retran=0 prsctp=0 sentq_empty=0
+NET rxt_timer: flags=0x0 c_time=342660
+    cwnd=95450 flight_size=95786 ssthresh=83634 RTO=200 error_count=0
+    partial_bytes_acked=0 fast_retran_loss_recovery=0 dest_state=0x1c1
+ASOC last_acked_seq=1527044401 sending_seq=1527044484
+CHUNK tsn=1527044402 sent=1 snd_count=1 book_size=1172
+CHUNK tsn=1527044403 sent=1 snd_count=1 book_size=1172
+CHUNK tsn=1527044404 sent=1 snd_count=1 book_size=1172
+```
+
+### Диагноз
+
+**`rxt_timer.flags = 0x0`** — ни `SCTP_CALLOUT_PENDING` (0x0004), ни
+`SCTP_CALLOUT_ACTIVE` (0x0002). Таймер ретрансмиссии НЕ ЗАПЛАНИРОВАН, при том
+что 82 куска лежат неподтверждёнными, каждый отправлен ровно один раз
+(`snd_count=1`, `sent=SCTP_DATAGRAM_SENT`) и ни один не помечен к пересылке.
+
+**Полёт 95786 против окна перегрузки 95450** — окно заполнено, `sctp_med_chunk_output`
+нового не отправит.
+
+Замок замкнут сам на себя: подтвердить куски некому, переслать некому, полёт не
+убывает, окно не освобождается, не уходит ничего. Навсегда.
+
+Это объясняет каждое наблюдение с провода: ни пакета с данными, ни
+ретрансмиссии, ни зонда окна, подтверждения обрабатываются, лечит только новая
+ассоциация.
+
+### Что этим снято ЧИСЛАМИ
+
+1. **учёт полёта точен** — `fcount=82` против `sentq_cnt=82`, фантома нет.
+   Раздел 4 опровергнут не только чтением, но и замером;
+2. **окно пира 4 572 914 байт, распахнуто**, а не ноль. Затвор
+   `peers_rwnd == 0 && total_flight > 0` не при чём;
+3. **таймер не отодвинут после неудач**: `RTO=200` — минимум, `error_count=0`.
+   Он просто не заведён.
+
+### Чего НЕ установлено
+
+Какая дорога теряет таймер. Обе, что должны его заводить, на вид верны:
+`sctp_output.c:9417` заводит после отправки, если он не запланирован;
+`sctp_indata.c:4265` заводит для каждого пути с ненулевым полётом при обработке
+подтверждения. У `sctp_t3rxt_timer` ранние выходы только через
+`sctp_threshold_management`, а при `error_count=0` он не срабатывал. По одному
+снимку дорогу не назвать: нужен ряд снимков в секундах перед обрывом.
+
+### Что это меняет для продукта
+
+Обнаружение на приёмнике и ротация остаются в силе, но теперь известно, что
+именно обходится: незаведённый таймер в конкретной ассоциации. **Ротация лечит
+это по построению** — новая ассоциация начинает с исправным таймером.
+
+Числа отправлены в `sctplab/usrsctp#750`.
+
+
+### Подтверждено на втором клине — подпись детерминированная
+
+Клин на 96 МБ (ниже прежнего минимума; отладчик к прогону не прикасался, обе
+записи переменных сделаны до создания ассоциации):
+
+| | первый | второй |
+|---|---|---|
+| полёт | 95786 | 51568 |
+| окно перегрузки | 95450 | 50566 |
+| разрыв | 336 | 1002 |
+| кусков в полёте / в очереди | 82 / 82 | 44 / 44 |
+| окно пира | 4572914 | 4647668 |
+| помечено к пересылке | 0 | 0 |
+| ошибок пути | 0 | 0 |
+| `rxt_timer.flags` | 0x0 | 0x0 |
+
+Разрыв оба раза **меньше одного пакета** — отправка встала ровно там, где
+следующий кусок перестал влезать в окно. Само по себе это нормальное поведение
+при заполнении окна; ненормально, что оно не разгребается.
+
+Ряд объёмов до клина теперь: 96, 288, 1220, 1436, 2356, 2696, 5300 МБ. Порога
+нет, разброс пятидесятипятикратный.
+
+### Вывод usrsctp: включается не тем флагом, каким кажется
+
+`option(sctp_debug "Provide debug information" 1)` в CMakeLists самого usrsctp
+включён по умолчанию — но у libdatachannel есть **свой** `option(SCTP_DEBUG
+"Enable SCTP debugging output to verbose log" OFF)`, и перекрывает именно он.
+Поэтому в обычной сборке вывода нет, хотя первый флаг говорит обратное.
+
+Проверено на живом процессе: `system_base_info.debug_printf` установлен в
+`rtc::impl::SctpTransport::DebugCallback`, а `sctpsysctl.sctp_debug_on` равен
+нулю — libdatachannel выставил бы `SCTP_DEBUG_ALL` сам, но его строка стоит под
+`#ifdef SCTP_DEBUG`, до C++ не дошедшим.
+
+Обе переменные пишутся отладчиком без вызова функций внутри процесса: указатель
+вывода можно перевести прямо на `printf`, минуя журнал libdatachannel и его
+уровень. Записи принимаются, но печатать нечего, пока нет пересборки с
+`--CDSCTP_DEBUG=ON`.
+
+## 7. Чего этот день НЕ установил
+
+1. ~~причину~~ — УСТАНОВЛЕНА, см. 6.2. Не установлена дорога, теряющая таймер;
+2. повторяемость по плечам: один прогон на плечо, разброс восемнадцатикратный;
+3. связь клина с полевыми эпизодами до 2026-08-26 — они старше и части нынешней
+   нынешнего кода не имели;
+4. что пауза в `drain` действительно помогает, а не попала в верхний край
+   разброса.

package/research/handover-2026-09-13.md

@@ -0,0 +1,209 @@
+# Передача: клин доставки, стенд и werift — 2026-09-13
+
+Написано для того, кто продолжит. Всё, что ниже, либо прочитано из журналов и
+кода, либо помечено как непроверенное.
+
+## 1. Что установила сессия 2026-09-12 (прокси 2.83.5)
+
+Показ встал на **521,2 с фильма** и не возобновился. Причина — клин доставки,
+и он снят на проводе с обеих сторон. Разбор:
+`research/delivery-wedge-on-the-wire-2026-09-12.md`.
+
+Цепочка, каждое звено с числом из журнала:
+
+1. 21:50:39.658 — последнее, что браузер получил. Его счётчик канала
+   `proxy=12112msg/479898176B` не сдвинулся больше ни разу;
+2. прокси продолжал отдавать: `sent=485243979 → 485263428`, очереди
+   `queued[proxy:0B proxy-control:0B proxy-fast:0B]`, `rtt=24ms`,
+   `pc=connected ice=completed`. Обратное направление работало весь клин;
+3. через ассоциацию прошло **485 МБ**. Прежние эпизоды: 783, 813, 825, 2294 МБ.
+   Порога по объёму нет;
+4. обрыв пойман посреди отдачи одного куска: `bytes=10657210 sendMs=360
+   bufferedAtEnd=0` — usrsctp принял всё, очередь пуста; на проводе за
+   следующие три секунды ушло 6 727 961 байт (≈63 %), и в середине четвёртой —
+   ноль, без ретрансмиссий и без утоньшения подтверждений.
+
+**Лечение было измерено и выброшено.** Браузер поднял вторую ассоциацию к тому
+же пиру, прокачал `GET /api/delivery-sink?bytes=4194304` за 140 мс, записал
+`the fault is held in the wedged association` — и **закрыл её через 0,45 с**.
+Показ остался на мёртвой.
+
+**Почему зритель сидит навсегда, а не минуту:** лестница пересоединения не
+запускается. В клиентском журнале нет ни `transport lost`, ни `reconnect
+attempt`, потому что заклинивший канал остаётся `state=connected
+ice=connected`, и объявлять его потерянным нечему. В тот же вечер в 20:03 на
+ЗАКРЫТОМ канале та же лестница отработала штатно.
+
+## 2. Две поправки к роадмапу, сделанные чтением кода
+
+1. **`waitForBufferDrain` УЖЕ починен** (`services/data-channel-handler.js:1199`,
+   выпущено в 2.80.6): он ждёт нижней отметки с опросом каждые 50 мс,
+   постоянная `DC_BUFFER_DRAIN_TIMEOUT_MS` удалена. Запись в роадмапе
+   («fails open», 2026-09-06) устарела.
+2. **И он всё равно не защищает.** В поле 2026-09-12 `bufferedAtEnd=0` и
+   `drainMs=0` на каждой строке: наша очередь пуста, потому что libdatachannel
+   отдал байты в usrsctp, а держит их usrsctp. `bufferedAmount()` слеп к этому
+   по построению — прокси отдал 10,6 МБ в тишину и не узнал.
+
+**Что на месте этого предложено и НЕ построено:** backpressure по тому, что
+зритель ПОДТВЕРДИЛ. Браузер уже сообщает счётчики каждого канала
+(`proxy=12112msg/479898176B` в строке `[dc-far]`, раз в 500 мс). Отправка
+сверяется с ними, а не только с `bufferedAmount()`. Порог не выбирать — вывести
+из того, сколько байт эта связь держит в полёте при здоровой работе.
+
+## 3. Обновление зависимости — проверено, не лечит
+
+Пин `^0.32.0`, в npm **0.33.4**. Внутри libdatachannel 0.24.2 → 0.24.5.
+Подмодуль usrsctp сверен по четырём тегам (v0.24.2, .3, .4, .5):
+`fec583d54493f879d2ae44a743423bf8a04371ab` во всех. **От клина не лечит.**
+Запись роадмапа «upstream fix waiting нет» была верна на 26.08; теперь
+перепроверена и по-прежнему верна по существу, но libdatachannel ушёл вперёд
+на три версии (там исправление прерывистых отказов DTLS-рукопожатия).
+
+## 4. werift — исследовано, читая сам пакет
+
+werift 0.24.4, MIT, обновлён 2026-08-10, один автор. 4,2 МБ, 9 зависимостей.
+`ice/`, `dtls/`, `sctp/`, `rtp/`, `webrtc/` — полная реализация на TypeScript.
+
+**За:**
+1. usrsctp исчезает целиком, а с ним и подозреваемый;
+2. ни одной нативной зависимости (`@noble/curves`, `tweetnacl`,
+   `@peculiar/x509` — чистый JS). Ни prebuilt, ни musl/aarch64, ни сборки в
+   дополнении. Для проекта с одним форком нативного модуля и девятью смертями
+   процесса это существенно;
+3. `bufferedAmount`, `bufferedAmountLow`, `bufferedAmountLowThreshold` есть —
+   наш backpressure переносится.
+
+**Против:**
+1. **Мультиплексирования одного UDP-порта нет.** `lib/common/src/transport.js:130`
+   создаёт `dgram.createSocket` на соединение; `icePortRange` — диапазон, а не
+   общий сокет. У нас `IceUdpMuxListener` держит один порт 9090 на все сессии,
+   и ровно он замаплен UPnP — шаг 3 удалённого доступа (2.9.18). На werift
+   каждая сессия берёт свой порт, которого в маппинге нет;
+2. **Цена в процессоре не измерена и может быть запретительной.**
+   `lib/sctp/src/sctp.js:16` — `USERDATA_MAX_LENGTH = 1200`. Сообщение в 65 КБ
+   режется на 55 SCTP-кусков, каждый собирается в JS, CRC32c через
+   `Buffer.concat` на пакет (`chunk.js:763`), поверх — DTLS-шифрование на JS.
+   При 8 Мбит/с ≈830 пакетов/с; на измеренных 24.08 пиках 150-330 Мбит/с —
+   за 30 000/с. На CM4, который кодирует 1080p на 1,96x.
+
+**Вывод:** werift снимает подозреваемого и платит сломанным единым портом и
+неизвестной производительностью. Назвать его решением до замера нельзя.
+Замер дешёвый: поднять werift-приёмник, прокачать гигабайт, сравнить загрузку
+процессора с сегодняшней.
+
+## 5. Стенд — построен наполовину, упёрся в выбор прокси
+
+Цель: измерить, ЗАВИСИТ ЛИ КЛИН ОТ РАЗМЕРА ПОРЦИИ. Это гейт на всё остальное,
+и он не снят ни разу — стенд 26.08 прокачал 1,0 ГБ без отказов, но его
+приёмник был libdatachannel, а нужен dcSCTP браузера.
+
+**Что работает:** `chrome-devtools` MCP подключён к Chrome 155 на 9222
+(`list_pages` отвечает). Локальный прокси поднимается и регистрируется:
+
+```
+node bin/cli.js --server-url https://webauth.courses --port 9091 \
+  --delivery-sink --name wedge-stand --log-file <path>
+```
+
+**Что мешает:** браузер его не выбирает. Дважды подряд, включая после
+перезагрузки страницы:
+
+```
+selectedId: f3013ad3 (полевой, хост дополнения)
+candidates: wedge-stand score=0.6075, proxy-f3013ad3 score=0.4466
+```
+
+Стенд имеет ЛУЧШИЙ счёт и не выбран. Отличие одно: `reachable: false` —
+сервер дозванивается снаружи и до машины разработчика не достаёт. Значит
+нагрузка пошла бы на рабочий узел, чего делать нельзя.
+
+**Два выхода, решение за пользователем:** сделать стенд достижимым (проброс
+порта) или добавить способ назначить прокси явно (правка продукта ради
+стенда).
+
+**Оговорка, которую надо держать при любом прогоне:** клин наступал при 485,
+783, 813, 825 и 2294 МБ — разброс впятеро. Одна прогонка на значение не
+докажет ничего; нужно по нескольку, и это часы прокачки. Если разброс внутри
+одного размера порции останется таким же, честный ответ — «не установлено», а
+не число.
+
+**Механика автономного прогона, продуманная и не построенная:** фоновый
+процесс через `run_in_background`; цикл в странице ставится ОДНИМ вызовом
+`evaluate_script` и дальше живёт сам; результат выходит через `client-logger`
+на сервер, а не через канал данных, — этот путь HTTP и переживает клин, чего
+сегодня не хватило (пункт 85: браузер замолчал ровно на клине).
+
+## 6. Что делать дальше, по порядку
+
+1. снять препятствие со стендом и взять замер размера порции — это гейт;
+2. backpressure по подтверждённому зрителем (§2), целиком наш код;
+3. замер werift на процессоре, если §1 не даст ответа;
+4. сообщить наверх: у нас есть то, чего нет ни у кого — два захвата с обеих
+   сторон и доказательство, что вторая ассоциация к тому же пиру работает в ту
+   же секунду. Ни в libdatachannel, ни в usrsctp вопрос не открыт.
+
+**Чего делать НЕ надо:** прямой HTTPS (шаги 6-7) как ответ на этот клин.
+Сказано пользователем 2026-09-12: это не решение проблемы.
+
+## 7. Что осталось незакрытым от прошлых сессий и всплыло сегодня
+
+1. ложное срабатывание 21:13:34 при 76 МБ прокачанных — 180 с захвата и файлы
+   кольца на показ, который шёл дальше ещё 37 минут;
+2. `--delivery-sink` включён на полевом прокси. Он отдаёт ответ любого размера
+   и существует только для стенда.
+
+## 8. СОСТОЯНИЕ НА КОНЕЦ 2026-09-12: дополнение ОСТАНОВЛЕНО, на его месте стенд
+
+**Смотреть нельзя, пока это не свёрнуто.** Дополнение остановлено намеренно
+(`ha apps stop b34a1737_torrent_tv_proxy`), и его место на порту 9090 занял
+контейнер `ttv-wedge-stand`, запущенный из того же образа
+(`b34a1737/aarch64-addon-torrent_tv_proxy:0.74.4`) с пропатченными
+`services/data-channel-handler.js` и `bin/cli.js`.
+
+**Свернуть:**
+
+```
+ssh ha 'sudo docker rm -f ttv-wedge-stand'
+ssh ha 'sudo docker exec hassio_cli ha apps start b34a1737_torrent_tv_proxy'
+```
+
+**Почему свой контейнер, а не правка живого.** Пробовал патчить контейнер
+дополнения — не выживает: `ha apps restart` пересоздаёт его из образа, а
+убийство процесса внутри поднимает watchdog, который тоже пересоздаёт. Дважды
+проверено по дате создания контейнера. Свой контейнер watchdog не трогает.
+
+**Что построено в продукте** (в npm НЕ опубликовано, в git НЕ закоммичено):
+`--send-chunk-bytes <N>` — размер одного сообщения канала данных;
+`bodySender` — чистая функция нарезки и склейки, восемь проверок
+(`test/send-chunk-bytes.test.js`), одна проверена на красноту поломкой склейки
+через границу чтения; `msgBytes=` в строке `[net-debug]`; `chunks=` теперь
+считает сообщения, а не чтения тела. Запись в CHANGELOG на 2.83.7.
+
+**Как сменить размер** (стенд перезапускается изнутри своего контейнера):
+
+```
+ssh ha 'sudo docker exec ttv-wedge-stand pkill -f cli.js'
+ssh ha 'sudo docker exec -d ttv-wedge-stand sh -c "node /usr/local/lib/node_modules/@torrent-tv/proxy/bin/cli.js --server-url https://webauth.courses --host 0.0.0.0 --port 9090 --ffmpeg-bin /usr/bin/ffmpeg --state-dir /standdata --delivery-sink --send-chunk-bytes 16384 --name wedge-stand > /standdata/stand.log 2>&1"'
+```
+
+**Нагрузка** ставится одним вызовом `evaluate_script` в открытой на
+`webauth.courses` вкладке Chrome (9222, chrome-devtools MCP): цикл поднимает
+СВОЁ соединение `new WebRtcProxy(id)` — рабочее соединение страницы не
+трогается, — тянет `GET /api/delivery-sink?bytes=4194304` подряд и пишет отчёты
+через `POST /api/client-logs`, то есть по HTTP, мимо заклинивающего канала.
+Состояние лежит в `window.__WEDGE_STAND__`, остановка — `.stopped = true`.
+
+**Читать результат:**
+
+```
+ssh do 'docker logs --tail 400 infra-server-1' | grep wedge-stand
+ssh ha 'sudo docker exec ttv-wedge-stand grep msgBytes /standdata/stand.log | tail -5'
+```
+
+**Ловушка, стоившая одного прогона:** локальный стенд на машине разработчика
+назывался тем же именем `wedge-stand`, и цикл подключился к нему вместо ХА.
+Целиться по id, не по имени. Локальный остановлен.
+
+**Опорный прогон запущен 2026-09-12 23:36 UTC** на `f312d1e6`, размер `asread`
+(65 382 байта), 4 МБ на запрос, 190-325 Мбит/с. Результата на момент записи нет.

package/routes/api/subtitles/get.js

@@ -24,6 +24,7 @@
  * @returns {Promise<void>}
  */
 
+import { deriveSourceKey } from "../../../services/torrent-source-key.js";
 import { spawn } from "node:child_process";
 import { TextSubtitleTrack } from "../../../services/tracks/TextSubtitleTrack.js";
 import { SubtitleController } from "../../../services/controllers/SubtitleController.js";
@@ -44,7 +45,7 @@ function setLanguageHeaders(reply, lang) {
   }
 }
 
-export async function handleApiSubtitlesGet(req, reply, { sourceRegistry, torrentPool, ffmpegBin, localBaseUrl }) {
+export async function handleApiSubtitlesGet(req, reply, { sourceRegistry, torrentPool, ffmpegBin, localBaseUrl, viewers }) {
   const query = req.query ?? {};
   const sourceKey = typeof query.sourceKey === "string" ? query.sourceKey.trim() : "";
   const fileIndex = Number(query.fileIndex);
@@ -55,6 +56,30 @@ export async function handleApiSubtitlesGet(req, reply, { sourceRegistry, torren
     return reply.code(400).send({ error: "sourceKey and fileIndex are required." });
   }
 
+  // Turning subtitles on is a fact about the VIEWER, and this is the only place
+  // that knows both the person and the file, so this is where it is recorded.
+  //
+  // It used to be recorded in the transport, against the CHANNEL, which the
+  // transport could only do by sniffing this path out of the request and
+  // deriving the torrent key itself. Two costs followed: a reconnect lost the
+  // subscription for the rest of the session, and the layer that carries bytes
+  // held application routing and torrent identity.
+  //
+  // The browser sends its registry key; the push side speaks the pool key, so
+  // the two are reconciled here — the same reconciliation the transport did.
+  const consumerId = typeof query.consumerId === "string" ? query.consumerId.trim() : "";
+  if (consumerId && hasTrackIndex && viewers) {
+    const record = sourceRegistry?.get(sourceKey);
+    if (record) {
+      try {
+        viewers.wantsCues(consumerId, await deriveSourceKey(record.sourceType, record.source), fileIndex);
+      } catch {
+        // A subscription that cannot be resolved costs this viewer pushed cues;
+        // it must not cost them the subtitles they asked for in this request.
+      }
+    }
+  }
+
   // Interface layer delegates to SubtitleController (orchestrator + domain),
   // which owns external-file vs embedded-track branching and the cluster walk.
   const controller = new SubtitleController({ sourceRegistry, torrentPool });