@torrent-tv/proxy 2.89.17 → 2.89.19

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

@@ -1,329 +0,0 @@
-# Клин доставки: лестница на стенде и чтение исходника 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/double-spawn-2026-09-10.md

@@ -1,171 +0,0 @@
-# Каждый кодировщик запускается дважды, и второй процесс никто не убивает
-
-Разбор восьми полевых сессий 8-10 сентября 2026: журнал прокси
-(`/data/proxy.log` + `proxy.log.1`, 188 634 строки, версии 2.80.18 и 2.80.19) и
-журнал браузера с дроплета (80 055 строк, восемь подписей сессий). Каждое
-утверждение помечено тем, откуда взято: ЗАМЕРЕНО (число из журнала), ПРОЧИТАНО
-(из исходников), ВЫВЕДЕНО (следствие двух первых).
-
-## 1. Причина: две власти вызывают `start()` на одном прогоне
-
-ПРОЧИТАНО. Прогон строится и ЗАПУСКАЕТСЯ в одном вызове:
-`EncodeOrchestrator.#placeAt` → `makeRun` → `hls-session-manager.#makeRunAt`
-(:3782) → `#startEncodeRun` (:5361), и последней строкой этой функции стоит
-`run.start(because)` (:5546). Вернувшись, оркестратор вызывает
-`run.start(because)` ещё раз (`EncodeOrchestrator.js:576`).
-
-`EncodeRun.start()` (`EncodeRun.js:360`) защиты от повторного вызова не имеет:
-строит аргументы заново, порождает второй процесс и ПЕРЕЗАПИСЫВАЕТ
-`this.#process`. Обработчики первого процесса остаются подписанными на тот же
-объект прогона.
-
-Обе строки появились 2026-09-04, в двух соседних коммитах: `a09b278` («A run is
-an object») поставила вызов в менеджере, `53785f2` («Encoders become classes») —
-в оркестраторе.
-
-ЗАМЕРЕНО, по переходам состояния за оба журнала:
-
-```
-207  IDLE --SPAWNED--> STARTING
-207  STARTING --SPAWNED--> STARTING
-```
-
-Ровно поровну. Двойной запуск происходит на КАЖДОМ прогоне без исключения: 207
-прогонов, 414 процессов ffmpeg.
-
-Ни один тест этого не ловит: в `test/encode-orchestrator.test.js` и соседних
-`makeRun` — заглушка, которая прогон не запускает, поэтому вызов в менеджере не
-исполняется ни разу.
-
-## 2. Остановка убивает только второй процесс
-
-ПРОЧИТАНО. `EncodeRun.stop()` шлёт SIGTERM в `this.#process` — то есть во
-второй. Первый не адресуем ниоткуда: ссылки на него не осталось.
-
-ЗАМЕРЕНО. Прогон `#453..#562` выхода `…grid=kf@38:video-only:v=38/copy`
-остановлен в 09:12:01.178; его ffmpeg писал в поток ошибок до **09:13:46.938 —
-105 секунд спустя**. Прогон `#463..#562` остановлен 09:12:10.204, последняя
-строка 09:13:50.038 — 100 секунд спустя. Осиротевший процесс живёт до конца
-своего отрезка, продолжая декодировать, читать из роя и писать файлы.
-
-ЗАМЕРЕНО. Число РАЗНЫХ отрезков, писавших в поток ошибок в течение одной
-секунды, на ОДНОМ выходе: 11 (09:13:31), 10 (09:13:32), 10 (09:13:34), 10
-(09:13:05). Машина — CM4, четыре ядра. Бюджет в это время печатал `maxRuns=3`, и
-машина состояний насчитывала не более трёх живых прогонов: **восемь из
-одиннадцати процессов не видел никто.**
-
-## 3. Что это ломает
-
-### 3.1. Доказательство завершённости куска обойдено
-
-Два процесса одного прогона получают ОДИН И ТОТ ЖЕ аргумент вывода —
-`making-<метка>-%05d.mp4`, где метка равна первому номеру отрезка. Метка задумана
-как имя прогона («отрезки не пересекаются, значит два живых прогона одного выхода
-начинаются с разных номеров по построению»). Для двух процессов ОДНОГО прогона
-это неверно: метка совпадает, и они пишут одно имя.
-
-ЗАМЕРЕНО: **1105 строк** `segment store: could not publish making-…: ENOENT` —
-один из двух переименовал файл, второму переименовывать нечего. По меткам: 904 на
-`making-0`, остальные разбросаны по всем выходам и всем сессиям.
-
-ВЫВЕДЕНО: это ровно та порча, ради которой 2.80.19 вводил рабочее имя — два
-писателя на одно имя. Правка не отменена, она обойдена изнутри.
-
-ЗАМЕРЕНО, что порча жива после 2.80.19: сессия `8cddc6f8` (10.09, 09:15:04) —
-`fatal: bufferAppendError` одновременно на звуке (`segment-00072.mp4`) и на
-картинке (`segment-00071.mp4`), `currentTime=712.61`. Сессия кончилась.
-
-### 3.2. Механизм имени сам по себе исправен
-
-ЗАМЕРЕНО на хосте дополнения: ffmpeg с `-f segment -segment_list pipe:3
--segment_list_flags +live` и шаблоном `making-0-%05d.mp4` пишет в четвёртый канал
-имена `making-0-00000.mp4`, `…-00001`, `…-00002`, и файлы под этими именами лежат
-на диске. ENOENT возникает не из-за имени и не из-за канала.
-
-### 3.3. Двойное чтение из роя
-
-ВЫВЕДЕНО. Каждый процесс открывает свой `/stream` (свой `createFragmentReader`),
-поэтому читателей хранилища кусков вдвое больше, чем прогонов. Это спусковой
-крючок тупика с закреплёнными кусками, где 2026-09-07 торрент был уничтожен при
-четырёх читателях.
-
-### 3.4. Процессорное время и задержки
-
-ЗАМЕРЕНО. Ответы на опрос прогресса (тело около 500 байт): медиана 22 мс, p90
-**2229 мс**, максимум **18 852 мс**; 362 ответа из 3516 дольше двух секунд.
-ЗАМЕРЕНО. Предложение качества в те же минуты: `not offering 540p=0.10x
-480p=0.11x 360p=0.12x 240p=0.13x`.
-
-## 4. Что найдено рядом и причиной не является
-
-### 4.1. Зритель простоял 44 минуты, и ни один прибор этого не сосчитал
-
-Сессия `39c188b5` (08.09, 20:38-21:28). Зритель перемотал на 551.1 с, затем на
-579.4 с. Картинка встала на 596.8 с, `readyState=1`, и до конца сессии не
-сдвинулась: 528 одинаковых строк `decode t=596.8s frames=11787`.
-
-ЗАМЕРЕНО: буфер держал `video=[…413..549.091] [859.192..886.136]` — перемотка
-пришлась в дыру между 549.1 и 859.2. Браузер запросил за это время 283 куска, но
-класть их в 596.8 было нечего.
-
-ЗАМЕРЕНО: счётчик «сколько стояла картинка» не напечатал НИ ОДНОЙ строки за эту
-сессию, а переход в состояние ожидания случился один раз. Счётчик закрывается
-только по возобновлению, поэтому перерыв, который не кончился, не записывается
-вовсе — худший случай невидим по построению.
-
-ЗАМЕРЕНО: 42 `levelLoadError` за 48 минут при том, что прокси в те же секунды
-отдавал `index.m3u8` (17 539 байт, `fetchMs=8-10`). Обе стороны о запросе
-плейлиста говорят разное.
-
-ЗАМЕРЕНО: браузер запрашивал `/v/540/index.m3u8` и `/v/480/index.m3u8`, декодируя
-1920x1080 — hls.js по-прежнему сам ходит по ступеням при ошибках, вопреки
-закреплению.
-
-### 4.2. Куча главного потока выросла до 845 МБ за 26 секунд
-
-ЗАМЕРЕНО (10.09): 09:15:20 heap=101 МБ, 09:15:31 — 378 МБ, 09:15:35 — 589 МБ,
-09:15:46 — **813 МБ**, `rss=1940MB`. Написаны два снимка кучи процесса —
-`heap-process-…-451543040` (431 МБ, 09:09) и `heap-process-…-885628928` (845 МБ,
-09:15:44), оба в `/data`. **Их никто не открывал.** Это то самое чтение, которого
-ждёт работа о необъяснённом росте памяти.
-
-ЗАМЕРЕНО: после конца сессии куча падает до 35 МБ, а `rss` остаётся 979-981 МБ
-четыре часа подряд без единого зрителя.
-
-### 4.3. Ошибки разбора потока
-
-ЗАМЕРЕНО: 20 294 строки `missing picture in access unit` и 20 118 строк `Invalid
-NAL unit size` — 89 % журнала. Все на ветке КОПИРОВАНИЯ картинки файлов `.mp4`
-(`grid=kf@38` — 629 строк с адресом, `kf@33` — 185, `kf@46` — 94). Причина не
-установлена. Проверено, что общего состояния чтения у двух процессов нет: каждый
-запрос `/stream` создаёт свой читатель.
-
-### 4.4. Прогоны, не сделавшие ничего
-
-ЗАМЕРЕНО: 153 прогона остановлены планом, из них **68 не произвели ни одного
-куска**. Медиана жизни остановленного прогона 9636 мс, p90 26 719 мс, суммарно
-1885 секунд. Причины остановки: 83 — «standing at #N scores worse than standing
-at #M», 49 — «the film is no worse off without it». Довели свой отрезок до конца
-48 из 207.
-
-### 4.5. Мелочи, каждая с местом
-
-1. Поле `live=` в строке плана печатается пустым 89 раз из 211 (`maxRuns=3 live=`).
-2. `/tmp/torrent-tv-hls` — 5,0 ГБ готовых кусков от сессий, кончившихся часами
-   раньше; 3272 файла в десяти каталогах. Ничего не подметает.
-3. `/data` — 3,3 ГБ, из них слепок памяти на 4,4 ГБ от 07.09 и 365 МБ снимков
-   кучи.
-4. Предложение качества в первую секунду сессии переворачивается: 19:39:40.568
-   `not offering 1080p=0.86x (offering 720p 540p 480p 360p 240p)`, 19:39:41.058
-   `not offering 720p=0.24x … (offering 1080p)`. Первое читает копируемую картинку
-   как перекодирование.
-
-## 5. Чего этот разбор НЕ устанавливает
-
-1. почему ffmpeg на ветке копирования выдаёт ошибки разбора — связь с двойным
-   запуском не показана;
-2. что именно держит 945 МБ резидентной памяти при куче в 35 МБ — снимки есть,
-   они не прочитаны;
-3. почему браузер сообщает `levelLoadError`, когда прокси отдал плейлист без
-   ошибки;
-4. откуда в буфере взялся оторванный остров 859..886 с.