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 — TrueNAS Taiga	2026-05-23	2026-09-29	tech	family	arr taiga truenas media operations	personal/tech/flaresolverr-taiga family/how-to/truenas-infrastructure family/how-to/arr-stack-kraken

Arr stack — TrueNAS Taiga

Каноническая документация arr-стека на TrueNAS Taiga. Kraken сюда не входит.

Текущее состояние

Проверено 2026-09-29 после полного force-recreate:

• flaresolverr, prowlarr, radarr, sonarr, lidarr, jellyfin, transmission запущены.
• docker compose config -q проходит.
• Lidarr → SkyHook: 10 результатов через VLESS proxy.
• Lidarr → Transmission: штатный test проходит.
• Prowlarr → RuTracker: реальный search возвращает 50 результатов.
• Prowlarr → Kinozal: реальный search возвращает 14 результатов.
• FlareSolverr: health ok, session prowlarr создаётся с proxy и pre-login.
• 3x-ui egress закреплён: Sweden master → Poland failover → текущий auto-resolve.
• Три последовательных proxy-запроса сохраняют один внешний IP.
• FlareSolverr watcher автоматически восстанавливает session и RuTracker login после потери.

Health-warning у Sonarr/Lidarr может показывать старый quarantine индексаторов. Проверять нужно реальным search и IndexerStatus, а не одной строкой health.

Архитектура

Компонент	Container	Порт	Назначение
Prowlarr	prowlarr	9696	индексаторы и sync
Radarr	radarr	7878	фильмы
Sonarr	sonarr	8989	сериалы
Lidarr	lidarr	8686	музыка и SkyHook
FlareSolverr	flaresolverr	8191	Cloudflare/browser
Transmission	transmission	9091	torrent download client
Jellyfin	jellyfin	8096	media server
VLESS proxy	vless-proxy	1080/1081	SOCKS5/HTTP proxy

Compose:

/mnt/RED_2TB/docker/arr/docker-compose.yml

Конфигурация сервисов: /mnt/RED_2TB/docker/arr/<service>. Media mount внутри arr-контейнеров: /storage.

Маршрутизация

1. Lidarr → api.lidarr.audio идёт через http://vless-proxy:1081.
2. FlareSolverr/Chrome → RuTracker идёт через socks5://vless-proxy:1080.
3. Локальный Transmission идёт напрямую по transmission:9091.

Sticky egress для трекеров

Настройки 3x-ui находятся на Taiga в /mnt/RED_2TB/docker/xray-admin/x-ui.db. Для пользователя vless-space используется цепочка:

space-master   → sub1-sweden-yt
space-failover → sub1-poland-yt
space-auto     → sub1-* / leastLoad

Master и первый failover не должны быть заменены общим leastLoad: смена egress-IP между challenge и повторным запросом инвалидирует Cloudflare-cookie.

Lidarr должен иметь:

proxyEnabled=true
proxyType=http
proxyHostname=vless-proxy
proxyPort=1081
proxyBypassLocalAddresses=true
proxyBypassFilter=transmission,prowlarr

Pitfall: proxyBypassLocalAddresses=false помогает SkyHook, но одновременно отправляет локальный Transmission через VLESS и ломает его. Внешний и локальный маршруты разделены намеренно.

FlareSolverr и RuTracker

Entrypoint:

/mnt/RED_2TB/docker/arr/flaresolverr-entrypoint.sh

При старте он ждёт /health, создаёт session prowlarr с socks5://vless-proxy:1080, читает credentials RuTracker из Prowlarr SQLite в режиме immutable=1, выполняет pre-login и запускает основной процесс. В compose важны PROXY_URL, BROWSER_TIMEOUT=180000, shm_size: 1gb, restart: unless-stopped и read-only mount каталога Prowlarr.

После старта watcher проверяет egress-IP каждую минуту и login-состояние RuTracker каждые пять минут. При смене IP или потере login он пересоздаёт session и выполняет pre-login заново.

RuTracker должен иметь оба Prowlarr-тега:

proxy + flaresolverr = [1,2]

Подробности: personal/tech/flaresolverr-taiga.

Повторный сбой 2026-10-26 UTC: реальные отказы RuTracker сопровождались локальной ошибкой Prowlarr database is locked; подобные блокировки затрагивали и другие индексаторы, затем Lidarr. Отдельно исправлен watchdog FlareSolverr: признак входа теперь проверяется в HTML после разбора JSON, временная ошибка запроса не сбрасывает рабочую сессию. Проверено: 50 результатов реального поиска, успешный одиночный тест RuTracker в Lidarr, после CheckHealth предупреждение о недоступности индексаторов исчезло. Высокое ожидание дискового I/O и блокировки SQLite требуют отдельного разбора; исправление watchdog их не устраняет.

Перезапуск и приёмка

ssh truenas_admin@mallexxx.duckdns.org \
  'cd /mnt/RED_2TB/docker/arr && docker compose config -q && docker compose up -d --force-recreate flaresolverr prowlarr radarr sonarr lidarr'
ssh truenas_admin@mallexxx.duckdns.org \
  'cd /mnt/RED_2TB/docker/arr && docker compose ps'

FlareSolverr session:

curl -fsS -H 'Content-Type: application/json' \
  -d '{"cmd":"sessions.list"}' http://127.0.0.1:8191/v1

Ожидается status=ok и session prowlarr.

SkyHook:

curl -H "X-Api-Key: $LIDARR_KEY" \
  'http://127.0.0.1:8686/api/v1/artist/lookup?term=Astrix'

Ожидается непустой JSON-массив и запись VLESS о api.lidarr.audio:443.

RuTracker проверять реальным search, а не только indexer/test:

curl -H "X-Api-Key: $PROWLARR_KEY" \
  'http://127.0.0.1:9696/api/v1/search?query=radiohead&type=search&indexerIds=1'

Ожидается непустой массив без error у результатов.

Pitfalls и исправления

Session не наследует proxy задним числом

PROXY_URL применяется при создании Chrome session. После изменения proxy session нужно пересоздать. Entrypoint делает это автоматически при старте FlareSolverr.

Профиль прокси меняется между запросами

Симптом: FlareSolverr успешно решает challenge, но Prowlarr получает Auth Failed или timeout на следующем запросе. Причина — 3x-ui leastLoad выбрал другой профиль и внешний IP изменился. Исправление — pinned master/failover chain и watcher relogin; timeout сам по себе проблему не решает.

Prowlarr API маскирует password

GET индексатора возвращает ********. Нельзя использовать такой JSON для pre-login. Рабочий pre-login читает SQLite read-only из отдельного контейнера.

indexer/test не является единственной приёмкой

Он может тестировать объект с замаскированным password и вернуть Auth Failed, хотя реальный search работает. Приёмка — реальный /api/v1/search плюс FS request с cookie bb_session.

Размер HTML не доказывает login

Страница Cloudflare/Chromium может быть большой. Надёжный признак — bb_session и успешный запрос через ту же session.

Quarantine может быть историческим

Перед очисткой сделать SQLite backup. Остановить Prowlarr, удалить только IndexerStatus, выполнить PRAGMA quick_check, запустить снова и повторить реальный search. Всю БД не удалять.

testall создаёт ложные timeout

Параллельные browser challenges перегружают Chrome. Проверять один индексатор за раз с большим timeout.

Массовая закачка альбомов

Альбомы скачиваются пачкой, по одному ходить не нужно:

Сценарий	Действие
Новый артист	Monitor → All + Start search for missing albums — очередь на все отсутствующие альбомы
Уже добавлен	Artist → Edit → Monitor: All + Search Monitored
Вся библиотека	Wanted → Missing → Search All
Много артистов сразу	Library Import (Monitor: All каждому) или POST /api/v1/artist в цикле

Один альбом за раз — только при Monitor: Single Album или ручном поиске лупы у альбома.

Приёмка пакетного поиска — реальный queue/History в Lidarr, а не строка health: при открытом дефекте download-client очередь формируется, но раздачи не стартуют.

Troubleshooting

Симптом	Проверка	Исправление
SkyHook 403	host config Lidarr и VLESS log	proxy vless-proxy:1081, local bypass оставить включённым
Transmission auth error	download-client test	синхронизировать password с текущим Transmission PASS; host transmission:9091
RuTracker Auth Failed	session, cookies, real search	пересоздать session/pre-login; не использовать ********
DNS/Cloudflare timeout	VLESS log, FS cookies, tags	проверить [1,2] и BROWSER_TIMEOUT=180000
Старый health quarantine	IndexerStatus и real search	backup + очистка только IndexerStatus
сервис не пережил restart	compose, mounts, restart policy	проверить bind mounts и restart: unless-stopped

Backup и безопасность

Перед изменением Prowlarr DB или compose сохранять backup рядом с исходным файлом. Пароли и API keys в Obsidian не записывать.

Связанные документы

• personal/tech/flaresolverr-taiga — FlareSolverr, session, pre-login и диагностика.
• family/how-to/truenas-infrastructure — общий TrueNAS.
• family/how-to/arr-stack-kraken — отдельный стек Kraken; не смешивать с Taiga.

Автопоиск русских имён при латинском имени MusicBrainz, 2026-11-05

У Plamenev (artist 473, MBID 8a907c72-8387-4da1-871b-4467cf0abddc) мониторинг всех четырёх альбомов был включён, но ArtistSearch 2–4 ноября каждый раз скачивал 0 отчётов. Причина подтверждена кодом SearchCriteriaBase.ArtistQuery => Artist.Name: штатный поиск использовал только Plamenev. В текущем MusicBrainz и в ArtistMetadata.Aliases нет русских псевдонимов этого MBID. Такой запрос находил только MP3-сингл Princess, отсутствующий в текущем каталоге, и FLAC-пак с неизвестным артистом. Запрос Пламенев в тех же настроенных индексерах находит MP3-дискографии RuTracker 5777792 и NoNaMe Club 1254828. Это проблема полноты имени запроса, а не выключенного monitoring или недоступных индексеров.

Постоянное общее исправление — модуль /mnt/RED_2TB/docker/arr/lidarr-autosearch/lidarr_alias_search.py, вызываемый обычным worker после ArtistSearch и нормализации паков. Он работает только с monitored-артистами, у которых 0 импортированных треков и не было grabbed: уже скачанные или зависшие пакеты не дублируются. Нужны как минимум два вышедших monitored-альбома. Используются сохранённые кириллические псевдонимы; дополнительно допускается обратимая транслитерация латинского имени, только если как минимум два названия альбомов кириллические. За один проход отправляется не более двух альтернативных запросов. Неподдержанные буквы не угадываются. Общие правила не содержат имён/ID конкретных артистов.

Альтернативный поиск идёт через Prowlarr только в индексеры, уже включённые в automatic search самого Lidarr. До принятия пакета читается только небольшой torrent metainfo: его MP3-пути должны содержать два разных названия нужных monitored-альбомов, а заголовок — соответствовать имени/его транслитерации. Аудиокниги, чужие авторы, FLAC, одно совпадение и будущие/выключенные альбомы такой проверки не проходят. После подтверждения содержимого переводится название дискографии в каноническое имя и повторно вызываются /parse и полный /release/push RSS decision engine. Ограничения качества, сидов и monitoring сохраняются; принудительного /release в этом модуле нет.

SEARCH_POLICY_VERSION=3: смена общей политики повторно рассматривает подходящих артистов без ручного сброса состояния Plamenev. Cron 4, периодичность и профили не изменялись. Бэкап прежних worker/tests/state: /mnt/RED_2TB/docker/arr/lidarr-autosearch/backup-name-search-20261105T051857Z/. Сначала установлен модуль-зависимость, затем атомарно опубликован worker. Все 50 тестов прошли локально и на NAS (8 новых тестов альтернативного поиска, 23 worker, 15 metadata search, 4 имён файлов).

Реальная приёмка 05:19:50 UTC: этот же общий обработчик нашёл по Пламенев и проверил в NoNaMe Club 1254828 MP3-пак «3 альбома, 9 сборников, 2013–2021» размером 1 304 529 537 байт. Подтверждены каталоги «Герой с тысячью лиц», «Крадущая сны», «Для мира на земле». Lidarr одобрил пакет без единого отказа; Transmission hash F5754EEF71798B17B3E961346CDEE1DCBF91A9F7. На 05:27:08 UTC downloadedEver=166 529 665, haveValid=166 300 289, прогресс 12,8%, скорость 1 146 880 байт/с, один подключённый сид, ошибок нет. Английский The Hero With a Thousand Faces не найден в проверенных каталогах пакета и остаётся monitored. Пока не объявлять всю загрузку/импорт завершёнными. Нативное подтверждение и состояние библиотеки: plamenev-name-search-validation.json; события alternate_name_search / alternate_pack_decision в runs.jsonl.

Границы исправления: это общий дополнительный этап установленного автопоиска, а не патч исходников Lidarr или исправление MusicBrainz. Он закрывает расхождение латинского/кириллического имени для MP3-дискографий при перечисленных проверках. Одиночные релизы, артисты с одним альбомом, уже имеющимися импортированными треками или предыдущим grabbed этим этапом не обслуживаются; произвольные псевдонимы не угадываются. Поэтому исправление не гарантирует загрузку любого отсутствующего артиста. Для первичной приёмки был вручную вызван тот же общий обработчик с текущим artistId; релиз, торрент и особое правило для Plamenev вручную не задавались. Последующие запуски выполняет общий worker через cron.

Лайкнутые артисты: мониторинг без автоматического скачивания, 2026-11-05

По запросу пользователя включены ранее выключенные лайкнутые артисты из проверенного CSV Spotify/Яндекс. Область операции — 733 сопоставленные записи из liked-artists-unmonitored-2026-11-05.csv, а не все 1333 записи Lidarr. На момент выполнения 731 артист ещё был unmonitored: им установлены monitored=true и monitorNewItems=none. Для всех их существующих альбомов подтверждён monitored=false; менять альбомные флаги фактически не понадобилось, они уже были выключены. Каста (62) и Geoffrey Day (491) к этому времени были включены пользователем: их настройки сохранены. 78 несопоставленных имён не добавлялись и не подменялись похожими артистами.

Это режим отдельных артистов. RSS индексеров, automatic/interactive search, TrueNAS cron 4 и прежние загрузки не отключались. Настройки всех остальных артистов и альбомов, quality/metadata profiles, пути и теги сохранены. Поисковые команды и загрузки этой операцией не отправлялись.

Важно различать три настройки в Lidarr 3.1.6.5079: monitored артиста; флаги monitored уже известных альбомов; monitorNewItems для альбомов, впервые обнаруженных при обновлении каталога. Значение none третьей настройки не выключает уже выбранные альбомы, поэтому проверены оба уровня. Для данного режима оставлять monitorNewItems=none: существующий worker восстанавливает полностью выключенные альбомы только для артистов с monitorNewItems=all. При none такое восстановление не выполняется. Пустой каталог может обновляться через общий worker, но вновь обнаруженные альбомы останутся без мониторинга. Наличие артиста в monitored само по себе не означает, что его альбомы запрошены к скачиванию.

Операция выполнена через штатные PUT /api/v1/artist/editor и PUT /api/v1/album/monitor, без прямых изменений БД. На время массовой записи взят существующий worker.lock; cron оставлен enabled. Порядок: сначала новые альбомы — None при ещё выключенном артисте, затем проверка выключенных существующих альбомов, затем включение артиста. Это исключает промежуточный запрос дискографии.

Резервная копия, манифест и приёмка: /mnt/RED_2TB/docker/arr/lidarr-autosearch/monitor-only-likes-20261105T073539Z/ (before.json, result.json, follow-up-verification.json). Одноразовая операция — enable_liked_artists_monitor_only.py, список — liked-artists-monitor-only-targets.json рядом с общим worker. Это не новая периодическая задача. Восстановление — через native API вернуть только выбранным ID значения monitored/monitorNewItems из before.json, а не восстанавливать живую БД целиком.

Повторная проверка 5 ноября в 13:37 по Бишкеку: все 733 сопоставленные записи CSV включены; у 731 изменённого артиста новые альбомы — None и 0 monitored-альбомов. Новых grabbed и новых записей очереди для них нет. Всего в Lidarr теперь 925 monitored-артистов; настройки остальных сохранены. Исходный CSV является снимком до этой операции и больше не означает текущий выключенный мониторинг.

Скачивание Geoffrey Day / Geoffplaysguitar по отдельному запросу, 2026-11-05

После массового включения лайкнутых артистов без скачивания пользователь отдельно запросил загрузку Geoff. Geoffrey Day (491, MBID 472a8c1b-ffef-400a-b4b4-8d5741d3ca85) и GeoffPlaysGuitar — одна запись: последнее имя присутствует в её псевдонимах. Только этому артисту назначен уже существующий общий metadata profile 3 «Watchlist music», сохранён общий MP3 quality profile 1, установлены monitored=true, monitorNewItems=all. Scoped RefreshArtist с artistIds=[491], isNewArtist=true и ожиданием его rescan наполнил каталог: 29 релизов, все monitored. ArtistSearch завершился успешно, но скачал 0 отчётов: подходящих сольных MP3 в проверенных индексерах пока не найдено. Резервная копия настроек и каталогов до/после: /mnt/RED_2TB/docker/arr/lidarr-autosearch/geoff-download-20261105T074710Z/.

Лайкнутые треки Geoff из Atomic Heart относятся к сборникам Various Artists (1239), а не к его сольному каталогу. По явному запросу на скачивание выбран найденный MP3-320 пакет RuTracker 6483234, размер 1 248 114 702 байта. До отправки проверен torrent metainfo: MP3-каталоги содержат точные названия всех шести уже выбранных OST Vol.1–6 (album IDs 9622–9627). Дополнительно в паке есть шесть Singles/EP. Не считать эти шесть синглов автоматически сопоставленными или импортированными.

Это разовая операция скачивания по запросу пользователя, не новая персональная настройка автопоиска. Исходный заголовок «Atomic Heart Soundtrack Collection (Various Artists) …» не распознавался штатным альбомным поиском. После подтверждения всех выбранных альбомов в содержимом для native /parse использован заголовок Various Artists - Discography 2023-2026 MP3 320kbps; он распознал ровно шесть нужных OST. Оригинальные guid, размер, proxy download URL и индексер сохранены. /release/push пропустил пакет через полный decision engine: approved=true, rejections=[]; принудительный /release и обход качества не использовались. Другие артисты, RSS и cron не менялись.

Transmission torrent 724, hash B9D1249744F59A196728EEA12E5308DDD0D90C8F, имя Atomic Heart Soundtrack Collection. Проверка 5 ноября в 13:50:57 по Бишкеку: downloading, 18,18%, downloadedEver=226 883 598 байт, haveValid=203 733 006, rateDownload=11 378 688 байт/с, 3 пира, errorString пуст. Это одна раздача с шестью grabbed-записями по альбомам, не шесть торрентов. Полный импорт на момент проверки не подтверждён. Доказательства: geoff-atomic-grab-result.json, geoff-transmission-verification.json, geoff-atomic-metainfo.torrent рядом с worker; JSON с приватным proxy URL хранится только на NAS.

Скачивание Pain по отдельному запросу, 2026-11-05

После включения лайкнутых артистов без автоматического скачивания пользователь отдельно запросил скачивание Pain. Для Pain (22, MBID 84d5a9df-dd85-43e9-92f3-ed87bcd59b58) установлены monitored=true, monitorNewItems=all, общий metadata profile 3 «Watchlist music»; общий MP3 quality profile 1 сохранён. Scoped RefreshArtist с artistIds=[22], isNewArtist=true и ожиданием его rescan обновил каталог: 28 релизов, все monitored. ArtistSearch выполнен. Другие артисты, RSS, cron и настройки Transmission не менялись. Резервная копия: /mnt/RED_2TB/docker/arr/lidarr-autosearch/pain-download-20261105T075334Z/.

Подтверждены правильные загрузки: Pain - I Am (2024), NoNaMe Club 1723621, MP3-320, размер 100 501 591 байт, hash 9F3DB2FC47A67845CAC508D3134B6384E04AF79D; Pain - Party in My Head (2021) Single, MP3-320, hash 3948AC0B02448C12B950185751E50DF6F75B407E. Проверка 5 ноября в 14:04:24 по Бишкеку: I Am — downloading, 212 992 байта приняты, 131 072 проверены, 1 пир, скорость 40 960 байт/с; Party in My Head — добавлен, downloading, 0 байт и 0 пиров. Основные NNM-трекеры отвечают Success, сидов 7 и 3 соответственно. Ошибок торрентов нет. Загрузку и импорт всей дискографии завершёнными не считать. Доказательство — pain-transmission-verification.json рядом с worker.

Во время поиска выявлено ложное сопоставление штатного Lidarr: чужой Painkiller - Pain and Destruction (2023) был привязан к альбому Pain (499). Торрент BD2B0210F09A1FA887EBE3C611596FD86F7E0612 немедленно остановлен; на проверке им было принято 0 байт. Неправильная раздача помечена штатным blocklist через DELETE queue с removeFromClient=false, blocklist=true, skipRedownload=true, затем удалена только из Transmission с delete-local-data=false. Повторно проверено, что этого hash в клиенте нет. Файлы не удалялись и ошибочного импорта не было. Это блокировка конкретной неверной раздачи, не заявление об исправлении всех неоднозначных сопоставлений штатного поиска. Исходная проверка — pain-initial-transmission-check.json.

Дополнительно проверен MP3-пак Kinozal 859659 «Pain - Discography Metal 1997–2016». Его MP3-каталоги подтверждают несколько нужных альбомов, но в заголовке нет битрейта: обычный /parse определяет качество Unknown. Полный /release/push отклонил кандидат по Unknown, лимиту размера для этого качества и уже имеющимся VBR-V0-файлам. Битрейт не выдумывался, эти отказы не обходились, пакет не скачивался. Результат — pain-pack-decision.json. Сопоставление всей дискографии или загрузку всех 28 релизов не обещать; корректно утверждать запуск двух названных раздач и включение остальных релизов в дальнейший поиск.