--- title: Arr Stack — Taiga created: '2026-05-23' updated: '2026-09-02' type: tech namespace: family tags: [arr, taiga, infra, media, pitfalls] related: - "[[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 нативно). **Причина — сеть между двумя домами:** ТВ/Мак (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 конец):** > 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.) ## Плейбек по сети → узкое место ап-линии 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 идёт целиком по интернету между двумя домами через межоператорский транзит. **Замеры (воспроизводимы):** ```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 (~30 Мбит/с)**, не Mac-линк (78 Мбит/с ✅), не кодек, не транскодинг. Файл 7.1GB/78 мин → средний ~12 Мбит/с с пиками >20 → на сценах с высокой динамикой пики близко к потолку 28 Мбит → стоп-кары, усугублённые 104 мс RTT рвущим HLS. **Что реально чинит:** 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`).