From a526949a9be3e7f0bf14d84716dc0ad1854958b4 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Wed, 2 Sep 2026 13:41:31 +0600 Subject: [PATCH] [2026-09-02] eagle: family/how-to/arr-stack-taiga.md family/how-to/truenas-infrastructure.md --- family/how-to/arr-stack-taiga.md | 77 +++++++++++++++---------- family/how-to/truenas-infrastructure.md | 10 ++-- 2 files changed, 54 insertions(+), 33 deletions(-) diff --git a/family/how-to/arr-stack-taiga.md b/family/how-to/arr-stack-taiga.md index ddc6eec8..e148cdad 100644 --- a/family/how-to/arr-stack-taiga.md +++ b/family/how-to/arr-stack-taiga.md @@ -15,7 +15,7 @@ Secondary arr stack on Taiga (TrueNAS), added 2026-05-20. > **STATE 2026-09-02 (end-of-session):** Стек **ПОДНЯТ И РАБОТАЕТ** ✅. `docker compose up -d` в `/mnt/RED_2TB/docker/arr` создал и запустил `prowlarr`, `radarr`, `sonarr`, `jellyfin` (все в проекте `arr`, процессы под **uid 950** — PUID/PGID=950 применён). Сеть `media_net` воссоздана (`docker network create media_net`), transmission подключён к `media_net`. **Персистентность сетей:** в `docker/transmission/docker-compose.yml` добавлена networks секция `media_net` + `transmission_default` (external) — transmission сам находится в обеих сетях при любом пересоздании. > -> **⚠️ ПЛЕЙБЕК РАБОТАЕТ, но НЕ ПЛАВНО на high-bitrate (диагноз 2026-09-02):** после успешного фикса `storage` root traverse jellyfin проигрывает, НО на ТВ «Книга джунглей» тормозит и грузится кусками. **ЭТО НЕ ТРАНСКОДИНГ** (проверено: ffmpeg-процессов нет, transcode dir пуст, h264 720p идёт direct play нативно). **Причина — сеть между двумя домами:** ТВ/Мак (192.168.1.x, ТТК) и TrueNAS (192.168.2.x, Ростелеком 90.189.160.148) — разные домохозяйства/провайдеры; доступ только через внешку. Замер: **~28 Мбит/с потолок, ~104 мс RTT, ~50 мс один межоператорский хоп** (мой провайдер 3–6 мс → прыжок на `194.186.168.65` до 54 мс). Ограничитель = **upload домашней ростелекомовской линии TrueNAS (~30 Мбит/с)**, не Mac-download (мой CDN-даун 78 Мбит/с ✅). Файл 720p BR 7.1 GB (средний ~12 Мбит/с, пики выше) близко к потолку → на динамичных сценах канал забивается + 104мс RTT рвёт HLS-буфер. **Пути решения:** (а) отдавать ниже потолка ~25 Мбит (понизить битрейт через jellyfin-лимит), (б) поднять ап-линию на стороне TrueNAS, (в) если TrueNAS физически в том же здании — дать локальный маршрут вместо обхода через внешку 90.189.160.148. Полный трассировочный разбор: см. секцию ниже «Плейбек по сети → узкое место ап-линии TrueNAS». +> **⚠️ ПЛЕЙБЕК РАБОТАЕТ, но НЕ ПЛАВНО на high-bitrate (диагноз 2026-09-02, ОБНОВЛЁН конец сессии):** после успешного фикса `storage` root traverse jellyfin проигрывает, НО на ТВ «Книга джунглей» тормозит и грузится кусками. **ЭТО НЕ ТРАНСКОДИНГ** (проверено: ffmpeg-процессов нет, transcode dir пуст, h264 720p идёт direct play нативно). **НЕ ап-линия TrueNAS** — замер с самого NAS опроверг раннюю гипотезу (см. ниже): линия TrueNAS даёт ~**184 Мбит/с down / ~117 Мбит/с up** (Cloudflare-замер с NAS), т.е. НЕ зажата на ~30 Мбит. **Настоящая причина — per-TCP-flow / BDP-ограничение при высоком RTT** между двумя домами: single SCP = ~28 Мбит/с, но **4 параллельных потока = ~51 Мбит/с** (агрегат РАСТЁТ с параллельностью → это ограничение конгeст-окна одного TCP, а НЕ жёсткий лимит линии/транзита). RTT ~104 мс, ~50 мс теряются на **одном физическом межоператорском прыжке** (мой провайдер TTK 3–6 мс → хоп `194.186.168.65` до 54 мс). Пер-хоп loss-анализ: грань моего ISP чиста (0%, 3 мс), дальние хопы дают спорадические LOSS-кластеры (ICMP-деприоритизация, НЕ устойчивые потери), re-route 104 мс **полностью не уберёт** (это география/пиринг, не дефектная петля). Мак-download НЕ виноват (CDN ~78 Мбит/с ✅). Файл 720p BR 7.1 GB (средний ~12 Мбит/с, пики >20) в пределах одного TCP-потока ~28–51 Мбит с малым запасом + 104 мс рвёт HLS-буфер → динамичные сцены подтормаживают. **Jellyfin НЕ умеет мультистримить один плейбек** (последовательный HLS на одном TCP; штатной настройки «в N потоков» нет). **Реальные пути:** (в 1) if TrueNAS в одном здании/роутере — дать локальный маршрут к `192.168.2.197` (убьёт 104 мс, LAN-скорость); (2) поднять ап-линию TrueNAS ТОЛЬКО если она реально мала — но замер 117 Мбит up говорит, что скорее нужен не тариф, а (3) снижение эффективной латентности/битрейт-запаса: ограничить jellyfin-транскод < ~20 Мбит ИЛИ прокси, тянущий файл с NAS в 4+ TCP-потоков (подтянет агрегат к 51+), ИЛИ WireGuard-туннель через VPS (меньше jitter/пер-потоковой деградации; минус не убирает 104 мс). Жирный отказ от варианта (б) «поднять ап-линию» как первичного — он основывался на ОШИБОЧНОМ замере 28 Мбит от Мака как потолка TrueNAS. Полный пересмотренный разбор: секция «Плейбек по сети → …» ниже. > > **✅ Два пост-запуска блокатора — ОБА РЕШЕНЫ (2026-09-02 конец):** > 1. **Jellyfin не проигрывал (FFmpeg 243)** — переход решён двумя фиксами: (а) `chown -R 950:950 /mnt/RED_2TB/docker/arr/jellyfin` (конфиг вглубь был 911:911) открыл UI; (б) главный скрытый корень — корень `/mnt/RED_2TB/storage` остался `921:921`, ACL `everyone@ EXECUTE=False` → uid 950 не мог traverse в `/storage/Movies/...`. Фикс (root): `chown 950:950 /mnt/RED_2TB/storage && chmod 750 /mnt/RED_2TB/storage`. После этого jellyfin проигрывает. Транскодинг откл.: Dashboard→Playback→убрать «Allow …transcoding». @@ -46,17 +46,17 @@ Secondary arr stack on Taiga (TrueNAS), added 2026-05-20. (Details were referenced but not captured. Update this page after next Taiga arr maintenance session.) -## Плейбек по сети → узкое место ап-линии TrueNAS (диагноз 2026-09-02) +## Плейбек по сети → per-TCP-flow/BDP-ограничение при хай-РТТ (диагноз 2026-09-02, ПЕРЕСМОТРЕН конец сессии) **Симптом:** jellyfin на TrueNAS работает, файлы проигрываются, но на ТВ high-bitrate (720p BluRay и выше) *тормозят / грузятся кусками*, потом подтормаживают на динамике. -**Вердикт — НЕ транскодинг.** Live-проверка во время плейбека через `docker exec jellyfin sh -c 'ps ... | grep ffmpeg'` и `ls /config/cache/transcodes/`: +**Вердикт — НЕ транскодинг и НЕ ап-линия TrueNAS.** Live-проверка во время плейбека через `docker exec jellyfin sh -c 'ps ... | grep ffmpeg'` и `ls /config/cache/transcodes/`: - нет ни одного дочернего ffmpeg, transcode dir пуст; - jellyfin-процесс `ps` — это сам сервер, не транс-ребёнок. - Файл `The.Jungle.Book.1967.720p.BluRay.5xRus.Eng.HDCLUB.mkv` — h264 **High@L4.1, 1256×720** → приложение ТВ (Jellyfin app) тянет нативно (direct play), транскодинг не нужен. -- Lог же показывает, что даже при просмотре jellyfin может ремуксовать в **HLS-сегменты по 6 сек** (`-codec:v:0 copy ... -f hls` — копия, не перекодирование кадров). «Грузка кусками» = эти HLS-сегменты добираются по сети. +- Lог показывает, что jellyfin даже при direct-play может ремуксовать в **HLS-сегменты по 6 сек** (`-codec:v:0 copy ... -f hls` — копия, не перекодирование). «Грузка кусками» = HLS-сегменты добираются по сети одним TCP-потоком. -**Корень — сетевая топология «два дома», доступ только через внешку:** +**Сетевая топология (два дома, доступ только через внешку):** | | Сеть | Шлюз | Внешний IP | Провайдер | |---|---|---|---|---| @@ -65,32 +65,51 @@ Taiga arr maintenance session.) TrueNAS **физически/логически НЕ в локальной сети Мак/ТВ**. ТВ→Jellyfin идёт целиком по интернету между двумя домами через межоператорский транзит. -**Замеры (воспроизводимы):** +**Замеры (воспроизводимы) — САМОЕ ВАЖНОЕ: замер с самого NAS, а не от Мака.** +> Ранняя гипотеза «~28 Мбит = ап-линия TrueNAS ~30 Мбит» была ОШИБОЧНОЙ: 28 Мбит — это потолок ОДНОГО TCP-потока от Мака по пути с 104мс RTT, а НЕ лимит линии TrueNAS. Проверено замером С TrueNAS до Cloudflare: ```bash -# Латентность и потери — интернет до внешки TrueNAS: -ping -c 5 mallexxx.duckdns.org # ~104 мс avg (межсетевой, НЕ LAN) - -# Где теряются ~50 мс — межоператорский прыжок: -traceroute -m 10 -n 90.189.160.148 -# х1-7 мой провайдер: 3–6 мс -# х8 194.186.168.65 → прыжок до ~54 мс (переход ТТК→рядом с Ростелекомом) -# х10 217.107.108.41 : ~62 мс - -# Пропускная способность Мак→TrueNAS (потолок ап-линии TrueNAS): -ssh truenas_admin@mallexxx.duckdns.org 'truncate -s 200M /tmp/spd_src.bin; sync' -time scp -q truenas_admin@mallexxx.duckdns.org:/tmp/spd_src.bin /tmp/spd_dst.bin -# 200 MB/~60s ≈ ~28 Мбит/с ← потолок -# (проверка, что Mac-download НЕ виноват: curl CDN даёт ~9.8 MB/s ≈ 78 Мбит/с) - -# Факты TrueNAS-стороны: -ip -4 addr show | grep inet # enp3s0 = 192.168.2.197 (локальная сеть дома TrueNAS) -cat /sys/class/net/enp3s0/speed # 1000 Mb/s (NIC 1G, не узкое место на хосте) -ip route | grep default # via 192.168.2.2 (домашний роутер TrueNAS) +# На самом TrueNAS — интернет-линия НЕ зажата: +ssh truenas_admin@mallexxx.duckdns.org \ + 'curl -o /dev/null -s -w "DOWN %{speed_download} B/s\n" "https://speed.cloudflare.com/__down?bytes=50000000"' + # DOWN ~23 MB/s ≈ 184 Мбит/с +ssh truenas_admin@mallexxx.duckdns.org \ + 'truncate -s 30M /tmp/up.bin && curl -o /dev/null -s -w "UP %{speed_upload} B/s\n" -X POST "https://speed.cloudflare.com/__up" --data-binary @/tmp/up.bin; rm -f /tmp/up.bin' + # UP ~14.7 MB/s ≈ 117 Мбит/с +# ovh/tele2 speedtest ХОСТЫ ЗАБЛОКИРОВАНЫ из RU (curl 000/timeout) — юзать Cloudflare __down/__up. ``` -**Вывод:** ограничитель = **ап-линия домашней ростелекомовской линии TrueNAS (~30 Мбит/с)**, не Mac-линк (78 Мбит/с ✅), не кодек, не транскодинг. Файл 7.1GB/78 мин → средний ~12 Мбит/с с пиками >20 → на сценах с высокой динамикой пики близко к потолку 28 Мбит → стоп-кары, усугублённые 104 мс RTT рвущим HLS. +**Где реальная пропускная просадка — per-TCP-flow/BDP при высоком RTT** (не жёсткий лимит). Ключевой тест — агрегат растёт с параллельностью: +```bash +# 1 поток: ~28 Мбит/с +scp -q truenas_admin@mallexxx.duckdns.org:/tmp/dis.bin /tmp/dis.bin -**Что реально чинит:** -1. Если TrueNAS в том же здании (не подтверждено): дать ТВ/Маку прямой доступ к `192.168.2.197`, а не обход через внешку `90.189.160.148` — станет LAN-скорость, 104 мс уйдут. Топология в `truenas-infrastructure.md` (Доступ) говорит про разные подсети — сверить, один ли это физический роутер/здание. -2. При истинно удалённом TrueNAS: либо поднять ап-линию тарифа TrueNAS (напр. 500/300), либо в jellyfin ограничить битрейт/качество ниже потолка ~25 Мбит/с (Dashboards→Playback/клиентское качество), либо (наилучшее) смотреть контент через **serving-стек Kraken** (Kraken выполняет serving, Taiga — acquisition; из документации стека это штатное разделение — см. `arr-stack-kraken.md`). +# 4 параллельных потока: ~51 Мбит/с ← агрегат РАСТЁТ → BDP-штраф одного TCP при 104мс, не лимит линии/транзита +for f in a b c d; do scp -q truenas_admin@mallexxx.duckdns.org:/tmp/$f.bin /tmp/par_$f.bin & done; wait +``` +(8-потоковый тест не дозамерен — апрув на запуск истёк; экстраполированное число НЕ фигурирует.) + +**Латентность и loss по хопам (per-hop):** +```bash +ping -c 5 mallexxx.duckdns.org # ~104 мс avg +traceroute -m 10 -n 90.189.160.148 +# х1-7 мой провайдер: 3–6 мс +# х8 194.186.168.65 → прыжок ~54 мс (переход ТТК→Ростелеком-регион) + +# per-hop loss probe (через отдельные ping каждые ~0.25с к 92.62.74.1 / 194.186.x / 217.107.x / 8.8.8.8): +# моя ISP-грань 92.62.74.1: ~3 мс, 0% loss (61/61) ← сегмент чистый +# дальние хопы (194.186.x,8.8.8.8): спорадич. LOSS-кластерами синхронно → ICMP-деприоритизация, НЕ устойчивые потери данных +# mtr на macOS по умолчанию нет — ставить tofu (brew install mtr). 8.8.8.8 тоже ~53мс → ВСЕ дальние сети идут через тот же 50мс переход. +``` + +**Вывод (пересмотренный):** ограничитель = **per-TCP-flow / BDP-штраф за 104мс RTT**, а не ап-линия TrueNAS (117 Мбит up — отдаёт, но один поток из-за латентности получает лишь ~28–51). Файл 7.1GB/78 мин → средний ~12 Мбит/с, пики >20 — впритык к achievable single-flow ~28–51 с малым запасом; 104мс рвёт HLS-буфер → стоп-кары. Re-route 104мс полностью НЕ уберёт (пиринг/география, но у Мак/ТВ-все дальние сети идут через тот же 50мс переход — намек, что частичный выигрыш смены исхода возможен, но не гарантирован). + +**Что реально чинит (по убыванию надёжности):** +1. **Если TrueNAS в одном здании/роутере** → дать ТВ/Маку локальный маршрут к `192.168.2.197`, не через внешку `90.189.160.148` — убьёт 104мс, станет LAN. Топология в `truenas-infrastructure.md` (Доступ) говорит про разные подсети — обязательно сверить, один ли это физический роутер/здание (вопрос открыт). +2. **Jellyfin НЕ умеет мультистримить один плейбек** (последовательный HLS на одном TCP; штатной настройки «в N потоков» нет). Параллельность можно применить только на уровне доставки файла, НЕ внутри jellyfin-потока: + - прокси-«качель»: локально отдаёт клиенту один поток, а файл тянет с NAS в 4+ TCP (aria2/hget) → подтянет агрегат к ~51+; + - **WireGuard-туннель дом↔NAS через VPS** (`91.207.28.205`, см. `truenas-remote-access-reverse-proxy.md`) — меньше jitter/пер-потоковой деградации, но 104мс физику не уберёт. +3. **Прагматичный фикс под ТВ-стрим сейчас:** ограничить jellyfin-транскод битрейтом < ~20 Мбит (заведомо ниже single-flow achievable ~28), чтобы один HLS-поток укладывался без дожевания. Включается сразу, без новой инфраструктуры. +4. Поднять ап-линию TrueNAS — **только если** замер из п.º (117 Мбит up) реально маловат для нужного контента; как первичный вариант отвергнут. + +> **Перекрёстно:** это исправление ранней ошибочной записи «потолок ~28 = ап-линия TrueNAS» (см. history этого файла до 2026-09-02). Если будущая сессия увидит противоречие — истина здесь: NAS-линк 184/117 Мбит, проблема per-flow/BDP при высоком RTT. diff --git a/family/how-to/truenas-infrastructure.md b/family/how-to/truenas-infrastructure.md index 20d70682..3414ee59 100644 --- a/family/how-to/truenas-infrastructure.md +++ b/family/how-to/truenas-infrastructure.md @@ -43,10 +43,12 @@ - ⚠️ Кра́кен и TrueNAS — **разные сети** (192.168.1.x vs 192.168.2.x). Доступ с Кракена на TrueNAS по локальному IP **не работает** **⚠️ Измеренный потолок канала Mac/ТВ (192.168.1.x) → TrueNAS (192.168.2.x) — 2026-09-02:** -Между этими двумя сетями нет LAN — только обход через внешку провайдеров (ТТК дом A ↔ Ростелеком дом B). Замерено: -- **~28 Мбит/с** пропускной способности (SCP 200MB за ~60s) — ограничитель = **ап-линия домашней ростелекомовской линии TrueNAS (~30 Мбит/с)**; Mac-download сам даёт 78 Мбит/с. -- **~104 мс RTT**, из них ~50 мс на **одном межоператорском хопе** `194.186.168.65` (traceroute до `90.189.160.148`). -- Следствие: **высокобитрейтный медиа-плейбек (720p BluRay и выше) через jellyfin на этом пути тормозит/грузится кусками** (HLS + 104мс RTT vs потолок ~28 Мбит). НЕ транскодинг (jellyfin direct-play). Детали и замеры/команды: `family/how-to/arr-stack-taiga.md` → «Плейбек по сети». Решение для плавного просмотра: повысить ап-тариф на стороне TrueNAS, ограничить битрейт в jellyfin, или смотреть через serving-стек Kraken. +**⚠️ Измеренный потолок канала Mac/ТВ (192.168.1.x) → TrueNAS (192.168.2.x) — 2026-09-02, ПЕРЕСМОТРЕНО:**
Между этими двумя сетями нет LAN — только обход через внешку провайдеров (ТТК дом A ↔ Ростелеком дом B). Замерено: +- **Single TCP flow ≈ 28 Мбит/с**, но **4 параллельных потока ≈ 51 Мбит/с** (агрегат РАСТЁТ с параллельностью) → это **per-TCP-flow / BDP-штраф за ~104 мс RTT**, а **НЕ лимит линии TrueNAS**. +- ⚠️ **ПОЗДНЕЙШИЙ ЗАМЕР С САМОГО NAS ОПРОВЕРГ раннюю запись «ап-линия TrueNAS ~30 Мбит/с»**: NAS → Cloudflare даёт **~184 Мбит/с down / ~117 Мбит/с up** (`curl https://speed.cloudflare.com/__down?bytes=50000000` и POST `__up`). ovh/tele2 speedtest из RU заблокированы — юзать Cloudflare-эндпоинты. +- **~104 мс RTT**, из них ~50 мс на **одном межоператорском хопе** `194.186.168.65` (TTK 3–6 мс → прыжок до ~54 мс). Per-hop loss: моя ISP-грань чиста (0%, 3 мс); дальние хопы дают спорадич. LOSS (ICMP-деприоритизация, не устойчивые потери). Re-route 104мс полностью не уберёт (пиринг/география). +- Следствие: **высокобитрейтный медиа-плейбек (720p BluRay и выше) через jellyfin на этом пути тормозит/грузится кусками** (HLS одним TCP + 104мс RTT, single-flow ~28–51 Мбит впритык к пикам файла). НЕ транскодинг (direct-play). **Jellyfin не умеет мультистримить один плейбек.** +- Пересмотренный разбор + команды: `family/how-to/arr-stack-taiga.md` → «Плейбек по сети → per-TCP-flow/BDP». Решения: дать локальный маршрут (если TrueNAS в одном здании/роутере), ограничить jellyfin-битрейт < ~20 Мбит, или прокси с мульти-TCP-загрузкой файла, или WireGuard-туннель через VPS. ## Пользователи и группы (ключевые)