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 нативно). Причина — сеть между двумя домами: ТВ/Мак (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».

✅ Два пост-запуска блокатора — ОБА РЕШЕНЫ (2026-09-02 конец):

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».

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.)

Плейбек по сети → узкое место ап-линии TrueNAS (диагноз 2026-09-02)

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

Вердикт — НЕ транскодинг. 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-сегменты добираются по сети.

Корень — сетевая топология «два дома», доступ только через внешку:

	Сеть	Шлюз	Внешний 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 идёт целиком по интернету между двумя домами через межоператорский транзит.

Замеры (воспроизводимы):

# Латентность и потери — интернет до внешки 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 (~30 Мбит/с), не Mac-линк (78 Мбит/с ✅), не кодек, не транскодинг. Файл 7.1GB/78 мин → средний ~12 Мбит/с с пиками >20 → на сценах с высокой динамикой пики близко к потолку 28 Мбит → стоп-кары, усугублённые 104 мс RTT рвущим HLS.

Что реально чинит:

Если TrueNAS в том же здании (не подтверждено): дать ТВ/Маку прямой доступ к 192.168.2.197, а не обход через внешку 90.189.160.148 — станет LAN-скорость, 104 мс уйдут. Топология в truenas-infrastructure.md (Доступ) говорит про разные подсети — сверить, один ли это физический роутер/здание.
При истинно удалённом TrueNAS: либо поднять ап-линию тарифа TrueNAS (напр. 500/300), либо в jellyfin ограничить битрейт/качество ниже потолка ~25 Мбит/с (Dashboards→Playback/клиентское качество), либо (наилучшее) смотреть контент через serving-стек Kraken (Kraken выполняет serving, Taiga — acquisition; из документации стека это штатное разделение — см. arr-stack-kraken.md).

13 KiB Raw Blame History Unescape Escape

Arr Stack — Taiga

Notes from Setup (2026-05-20)

Key Differences from Kraken Stack

Pitfalls

Плейбек по сети → узкое место ап-линии TrueNAS (диагноз 2026-09-02)

13 KiB

Raw Blame History