97 lines
13 KiB
Markdown
97 lines
13 KiB
Markdown
---
|
||
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`).
|
||
|