@torrent-tv/proxy 2.87.10 → 2.87.11

package/research/double-spawn-2026-09-10.md

@@ -1,171 +1,171 @@
-# Каждый кодировщик запускается дважды, и второй процесс никто не убивает
-
-Разбор восьми полевых сессий 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 с.
+# Каждый кодировщик запускается дважды, и второй процесс никто не убивает
+
+Разбор восьми полевых сессий 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 с.