[2026-09-21] eagle: family/projects/watchlist-automation.md personal/tech/inter-site-throughput-taiga-to-mac.md

personal/tech/inter-site-throughput-taiga-to-mac.md

@@ -169,3 +169,111 @@ Moonfin/Breezyfin **НЕ дадут 120 Мбит** — они не распар
 5. По результату: сеть → лимит битрейта или prefetch-proxy; кодек → подбор профиля.
 
 **Статус: план предложен, Alex решения не дал. Ничего не менялось — ни на TrueNAS, ни на ТВ, ни в туннелях.**
+
+---
+
+## ❌ «Поднять несколько xray-туннелей» — почему НЕ поможет (разобрано 2026-09-21)
+
+**Прямой вопрос Alex:** *«что помешает поднять несколько xray tunnels и использовать их? в тесте speedtest 120mbit показывало через наш реверс туннель»*
+
+**Ответ: ничего не помешает поднять, но скорости это не даст.**
+
+`speedtest` = **8 параллельных TCP-сессий**, каждая со своим congestion window → 8 × ~15 Мбит = 120.
+Это доказывает, что **канал** пропускает 120 Мбит. НЕ доказывает, что **одна** сессия их возьмёт.
+
+**Скорость одной TCP-сессии ≈ окно / RTT.** Для 120 Мбит при RTT 104 мс нужно ~1.5 МБ неподтверждённых данных «в полёте».
+Одна сессия так разгоняется только при отсутствии потерь; на межоператорском стыке потери есть → окно режется вдвое →
+стабилизируется на 28–45 Мбит (наши замеры 2026-09-02). Jellyfin отдаёт видео **одним потоком** → упирается в это.
+
+| Подход | Независимых окон | Даст 120 Мбит? |
+|---|---|---|
+| speedtest (8 сессий) | ✅ 8 | ✅ |
+| **Клиент с Range-запросами / prefetch-proxy** | ✅ N | ✅ **правильный путь** |
+| Jellyfin webOS штатный | ❌ 1 | ❌ ~28–45 |
+| **8 xray-туннелей + mux** | ❌ одно логическое окно | ❌ head-of-line blocking |
+| MPTCP по одному физическому пути | ❌ | ❌ |
+
+**MPTCP/bonding агрегируют РАЗНЫЕ физические пути.** У нас путь один: ТТК → Ростелеком (хоп 8, +50 мс).
+N туннелей по одному пути делят один congestion window → суммарно **не больше одного**, плюс оверхед инкапсуляции.
+**Единственный честный путь к реальной агрегации — второй независимый ISP.**
+
+### ⚠️ Питфолл объяснения: аналогия «узкая труба» НЕ работает
+Первое объяснение было через метафору трубы — Alex: *«ниче не понял в твоей аналогии с трубой»*.
+Метафора прятала механизм. **Рабочая формулировка — через ЧИСЛО СЕССИЙ:**
+«канал пропускает 120 Мбит, но только если запрашивать 8 потоками ОДНОВРЕМЕННО; одна сессия возьмёт ~28–45, потому что
+не может разогнать своё окно на 104 мс RTT». Объяснять механизмом, не метафорой.
+
+### 🔴 Многопоточный HLS в Jellyfin / hls.js — есть в планах, НЕ реализован
+
+| Где | Статус | Факт |
+|---|---|---|
+| **Jellyfin** feature request #2171, 230 голосов | ✅ **Planned** (maintainer Joshua M. Boniface) | *«Jellyfin currently streams using only one connection»*. Но issue #3206 (2020) закрыт как **stale**, #6724 — как feature request. **За 5 лет кода нет.** |
+| **hls.js** issue #6753 (окт 2024) | milestone 1.8.0, «Top priorities», **PR отсутствует** | Предлагает префетч **2–5 сегментов одновременно** («Concurrent Loading»). Ровно наш механизм — но не сделано |
+| **ExoPlayer** issue #5978 | proposal | Параллельные DASH/HLS-сегменты. Android, не webOS |
+| **webOS-клиенты** | ❌ невозможно | Нативный video element = чёрный ящик, число соединений не настраивается. Moonfin/Breezyfin/официальный — все однопоточны |
+
+**Вывод: ждать нечего.** Ни от обновления Jellyfin, ни от новых клиентов. Реальные многопоточные решения —
+только **внешние прокси/префетчеры** (см. «Готовые инструменты для prefetch-proxy»).
+
+---
+
+## 🆕 Lampac — самохостируемый backend для Lampa (рассмотрен 2026-09-21, НЕ внедрён)
+
+**`lampac-nextgen/lampac`** (форк `immisterio/Lampac`) — ASP.NET Core (.NET 10), MIT, `linux/amd64`+`linux/arm64`.
+Порт по умолчанию **9118**. Ставится **одним контейнером** и отдаёт плагины самой Lampa.
+
+**Закрывает сразу всё, что разбиралось по частям:**
+
+| Компонент | Что даёт |
+|---|---|
+| **TorrServer** | встроен как subprocess — отдельный контейнер не нужен |
+| **JacRed** | агрегатор торрент-индексаторов, **Jackett-совместимый** |
+| **GStreamer** | **HLS/fMP4 транскод** (заменяет legacy FFmpeg, плагин `/gst.js`) — решает MKV/HEVC-проблему webOS |
+| **LampaWeb** | хостит саму Lampa UI + собирает widgets: `/lg.ipk` для LG webOS, `/samsung.wgt` для Tizen |
+| **TmdbProxy** | локальный кэш TMDB API |
+| **DLNA/UPnP**, Tracks, Sync, TimeCode, Playwright, WAF, GeoIP | прочее |
+
+**Установка (Docker):**
+```bash
+git clone https://github.com/lampac-nextgen/lampac.git && cd lampac
+mkdir -p lampac-docker/config lampac-docker/plugins
+cp config/example.init.conf lampac-docker/config/init.conf
+printf '%s' 'пароль_root' > lampac-docker/config/passwd
+# раскомментировать volumes в docker-compose.yaml
+docker compose up -d
+curl -fsS "http://localhost:9118/version?type=hash"    # проверка
+# плагин для Lampa: http://<IP>:9118/online.js
+```
+⚠️ В контейнере рабочий каталог `/lampac`, файлы читаются **из корня**, не из `config/`. Volumes по умолчанию закомментированы.
+
+### 🔴 Главное ограничение — Lampac НЕ решает проблему узкого канала сам по себе
+
+TorrServer внутри Lampac работает **на том же хосте, что и Lampac**.
+
+```
+Lampac на Кра́кене:   пиры → Кра́кен → [УЗКИЙ КАНАЛ, 1 TCP] → ТВ   ← лимит остаётся
+Lampac в Бишкеке:    пиры → Mac → [быстрая локалка] → ТВ          ← лимит обойдён
+```
+
+Alex **отверг вариант с Mac**: *«нахуя нам блядь на маке что-то! на кракене блядь бэкенд»*.
+Значит Lampac на Кра́кене решает только участок «пиры → Кра́кен».
+
+**Но у Lampac есть то, чего не было в других вариантах:** встроенный **GStreamer HLS-транскод** →
+можно отдать ТВ поток 10–15 Мбит одним потоком, и он пройдёт. Это **не «обойти лимит», а «сделать поток лёгким»** —
+другое решение той же проблемы.
+
+### 🚧 Блокер на момент рассмотрения (снят 2026-09-21)
+Диск Кра́кена был **100%** (0 байт) → Lampac не поставить, TorrServer некуда кэшировать.
+Плюс `/` (SD-карта) — всего 8.4 ГБ свободно, кэш торрентов туда не влезет.
+**Диск освобождён до 77% / 404 ГБ** (см. [[family/plans/watchlist-disk-overflow-fix]]) — блокер снят,
+но решение по Lampac **ещё не принято**.
+
+### Альтернатива: TorrServer прямо на ТВ
+**`6ebeng/torrserver-webos`** — TorrServer как webOS-приложение (.ipk), webOS 4.x–9.x, rooted и unrooted.
+Управление с любого устройства на `http://<tv-ip>:8090`. Бинарник зашит в .ipk (32-bit ARM), работает offline.
+⚠️ **Плеер — встроенный HTML5 `<video>`:** *«webOS has no API to hand stream URL to native player. MP4/H.264 plays
+most reliably; MKV support depends on TV's Chromium»* → **MKV может не заиграть**. Торрент тянется многопоточно
+(N пиров = N окон), но контент берётся из **публичных раздач**, не из библиотеки на TrueNAS.
+
+**Итог по Lampac/TorrServer: концепция рабочая, решение не принято. Требует ответа Alex —
+что важнее: своя библиотека (тогда prefetch-proxy) или «просто смотреть кино» (тогда торрент-путь).**