obsidian-vault/family/how-to/arr-stack-taiga.md

title, created, updated, type, namespace, tags, related

title	created	updated	type	namespace	tags	related
Arr Stack — Taiga	2026-05-23	2026-09-02	tech	family	arr taiga infra media pitfalls	tech/arr-stack-kraken

Arr Stack — Taiga

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 нативно). НЕ ап-линия 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».
2. Transmission 255 торрентов "no data found" — downloadDir УЖЕ корректно указывал на /storage/Movies, файлы были и читались под 950; ошибка была закеширована от старта при блокированном traverse. Фикс (НЕ root): docker restart transmission → 254/255 чисты сразу. Остался торрент #1 — Verify в UI.

Почему стек изначально не запускался — медиа-права были сломаны (тот же restore-инцидент uid 921/0000): /mnt/RED_2TB/storage/{Movies,Cartoons,Downloads,Music,series,shared} были d---------/drwx------, owner transmission (uid 921). radarr/sonarr монтируют /storage (rw), jellyfin :ro — со сломанными правами не прочитали бы библиотеку. ✅ Права медиа ИСПРАВЛЕНЫ (2026-09-02) до 950:950 drwxrwx---; контейнеры arr/jellyfin затем подняты и запущены. Полный контекст и команды: family/documents/vault-sync/2026-09-02-restore-privilege-scope.md.

Docker-image facts (2026-09-02): All 5 media images loaded locally on TrueNAS (docker images): lscr.io/linuxserver/{radarr,sonarr,jellyfin,transmission,prowlarr}:latest. All containers now exist and run under uid 950. Was: transmission container existed (now running as uid 950); jellyfin/radarr/sonarr/prowlarr containers were NOT yet created — now they are (PUID/PGID=950). Transmission originally ran as ROOT (not 911/950): its compose had no PUID/PGID, so linuxserver /init (s6-overlay) left it root. ✅ Fixed 2026-09-02: PUID=950 PGID=950 added and container force-recreated → now daemon under uid 950. It mounts storage → /mnt/storage, download-dir = /mnt/storage/Downloads. Fix direction (approved Variant A): set PUID=950 PGID=950 on transmission + all arr/jellyfin compose services so every service shares uid 950 and mutually reads files; then recursively fix perms in depth. Plan + commands: 2026-09-02-restore-privilege-scope.md §5.

PROGRESS 2026-09-02 (updated end-of-session): Both compose files edited for PUID/PGID=950 (transmission at /mnt/RED_2TB/docker/transmission/docker-compose.yml, arr at /mnt/RED_2TB/docker/arr/docker-compose.yml incl. all 4 services). transmission container force-recreated from its proper folder (cd /mnt/RED_2TB/docker/transmission && docker compose up -d --force-recreate) and now runs its daemon as uid 950 (was root) — env PUID=950 PGID=950 confirmed, process under abc/950. Media perms in depth recursively fixed to 950:950 drwxrwx--- on all top storage folders (incl. git/nas 2nd root pass). Git-sync on Mac now RESOLVED — the broken NFS4 DENY READ_DATA ACL on ~1946 loose git objects in obsidian-vault.git was stripped via full dacl replacement (not stripacl), so git push from Mac works again (push a2c7279..2b6c181, ahead=0 behind=0). Arr stack is UP (2026-09-02 end): cd /mnt/RED_2TB/docker/arr && docker compose up -d created/started prowlarr/radarr/sonarr/jellyfin. All daemons under uid 950. jellyfin reads /storage/Movies; radarr↔transmission via media_net (transmission:9091) OK; caddy resolves transmission via transmission_default (Web UI). UI ports: prowlarr 9696, radarr 7878, sonarr 8989, jellyfin 8096, transmission 9091. NOTE: radarr/sonarr/jellyfin mount /mnt/RED_2TB/storage as /storage (NOT /media like Kraken) — radarr root-folder on Taiga differs.

Notes from Setup (2026-05-20)

• Config and pitfalls recorded during initial Taiga arr stack deployment
• router.py was customized — check /mnt/RED_2TB/docker/arr-taiga/router.py for current state

Key Differences from Kraken Stack

• Taiga = TrueNAS host (storage-focused)
• Kraken = Raspberry Pi 5 (playback-focused)
• Taiga stack handles acquisition; Kraken handles serving to Jellyfin

Pitfalls

(Details were referenced but not captured. Update this page after next Taiga arr maintenance session.)

Плейбек по сети → per-TCP-flow/BDP-ограничение при хай-РТТ (диагноз 2026-09-02, ПЕРЕСМОТРЕН конец сессии)

Симптом: jellyfin на TrueNAS работает, файлы проигрываются, но на ТВ high-bitrate (720p BluRay и выше) тормозят / грузятся кусками, потом подтормаживают на динамике.

Вердикт — НЕ транскодинг и НЕ ап-линия 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 даже при direct-play может ремуксовать в HLS-сегменты по 6 сек (-codec:v:0 copy ... -f hls — копия, не перекодирование). «Грузка кусками» = HLS-сегменты добираются по сети одним TCP-потоком.

Сетевая топология (два дома, доступ только через внешку):

	Сеть	Шлюз	Внешний IP	Провайдер
Мак / ТВ	192.168.1.57	192.168.1.1	динамика	ТТК (92.62.x / 185.20.x)
TrueNAS	192.168.2.197	192.168.2.2	90.189.160.148	Ростелеком (217.107.x)

TrueNAS физически/логически НЕ в локальной сети Мак/ТВ. ТВ→Jellyfin идёт целиком по интернету между двумя домами через межоператорский транзит.

Замеры (воспроизводимы) — САМОЕ ВАЖНОЕ: замер с самого NAS, а не от Мака.

Ранняя гипотеза «~28 Мбит = ап-линия TrueNAS ~30 Мбит» была ОШИБОЧНОЙ: 28 Мбит — это потолок ОДНОГО TCP-потока от Мака по пути с 104мс RTT, а НЕ лимит линии TrueNAS. Проверено замером С TrueNAS до Cloudflare:

# На самом 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.

Где реальная пропускная просадка — per-TCP-flow/BDP при высоком RTT (не жёсткий лимит). Ключевой тест — агрегат растёт с параллельностью:

# 1 поток: ~28 Мбит/с
scp -q truenas_admin@mallexxx.duckdns.org:/tmp/dis.bin /tmp/dis.bin

# 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):

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мс физику не уберёт. ⚠ XRAY-ТУННЕЛЬ УЖЕ ИЗМЕРЕН и НЕ ПОМОГАЕТ (2026-09-02): оба egress-режима локального xray-test-client (kraken-user reverse → Kraken ~45 Мбит; user1 direct/REALITY → TrueNAS ~37 Мбит) дают ~35–45 Мбит с нестабильностью — тот же уровень, НЕ кратно выше single-flow прямого пути (28–51 Мбит). Детали и способ переключения клиента: personal/tech/xray-reverse-tunnel-kraken-truenas.md § «СОСТОЯНИЕ КЛИЕНТА/Замеры».
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.