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-11-02	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; актуальные исправления Lidarr/индексаторов и общий автопоиск от 2026-11-02 описаны ниже:

• 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 → lidarr-metadata-search:5001/api/v0.4 → api.lidarr.audio; дополнительный поиск имён → MusicBrainz. Оба внешних запроса идут через 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 (prefix; также матчится sub1-sweden-yt)
space-failover → sub1-poland-yt
space-auto     → sub1-* / leastLoad

Исправление 2026-11-02: подписка больше не содержала sub1-sweden-yt (актуальный тег — sub1-sweden), поэтому основной selector не находил кандидатов. Резервирование тоже было ошибочным: Xray fallbackTag принимает outbound, а не другой balancer. В журнале — non existing outTag: space-failover; Lidarr показывал Invalid response received from LidarrAPI, вложенная причина — TLS unexpected EOF.

В постоянном settings.xrayTemplateConfig исправлен prefix основного selector и добавлены два outbound типа loopback: space-failover → inboundTag space-failover-loopback, space-auto → inboundTag space-auto-loopback. Соответствующие routing-правила отправляют их на одноимённые balancer и стоят перед правилом vless-space-via-subscription, чтобы не возвращаться на основной маршрут. Остальные клиенты, подписка и observatory не изменялись.

Приёмка на живом Lidarr: /api/v1/search для «Четыре», «Четыре позиции Бруно», «4 Позиции Бруно» и Radiohead — HTTP 200; artist/lookup находит 4 Позиции Бруно (c0e9bf2e-9c31-4ff1-8e23-0021652a9015). Обе резервные ступени проверены временным override space-master на соответствующий loopback: поиск HTTP 200; override затем снят, основной выбор sub1-sweden. Ошибок non existing outTag после рестарта — 0. Бэкап SQLite (через backup API, с WAL) и шаблонов до/после: /mnt/RED_2TB/docker/xray-admin/lidarr-search-fix-20261102T013142Z/. Откат — вернуть только значение xrayTemplateConfig из template-before.json и перезапустить xray-admin; весь файл БД поверх живого контейнера не копировать.

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

Monitored без скачиваний: MASTER BOOT RECORD, 2026-11-02

Перед исправлением у MASTER BOOT RECORD (artistId=97) все 12 альбомов были monitored, файлов и истории загрузок не было. Prowlarr оказался остановлен с 2026-10-28 (ExitCode=137, OOMKilled=false; причину остановки отдельно не установили). До остановки журнал содержал database is locked. Все активные индексаторы Lidarr были в карантине. База Prowlarr прошла PRAGMA quick_check=ok; контейнер запущен без изменения настроек качества. После штатного перезапуска FlareSolverr подтверждён вход в RuTracker (parsed HTML logged-in=true), затем прошли одиночные тесты RuTracker в Prowlarr и RuTracker/NoNaMe Club/Kinozal в Lidarr. Health Lidarr — [].

Уточнённая диагностика MP3, 2026-11-02: проверка одного FLAC-релиза VIRUS.DOS была недостаточна для объяснения отсутствия загрузок MP3. Нужно выполнять поиск по артисту GET /api/v1/release?artistId=97, без albumId: альбомный поиск добавляет название отдельного альбома и может не находить пак дискографии. Lidarr поддерживает дискографии — утверждать обратное нельзя.

На RuTracker есть MP3-пак Master Boot Record - Discography (15 Albums) - 2016-2024, MP3, 160-320 kbps, тема 5969222, размер 1 998 105 001 байт, 23 сида при проверке. Поиск по артисту в Lidarr находит его и возвращает два точных отказа: 1.9 GB is larger than maximum allowed 690.3 MB и MP3-160 is not wanted in profile. Диапазон 160–320 из названия распознан как MP3-160; в профиле MP3 (default) MP3-160 выключен, разрешены MP3-VBR-V2/MP3-256/MP3-VBR-V0/MP3-320. Сам факт, что раздача MP3, не означает соответствия этим ограничениям. На этом этапе диагностики лимиты качества/размера и ручной override раздачи не менялись; фактическое исправление описано ниже.

Другие MP3 из того же поиска также имеют отдельные причины отказа: Realtime Execution — Unable to parse albums from release name; VirtuaVerse — Unable to parse release; сингл Secret Track — Unable to parse albums from release name. Проверенный FLAC-релиз VIRUS.DOS отклонён с FLAC is not wanted in profile, но это не объяснение отказа имеющейся MP3-дискографии.

Первый диагностический MissingAlbumSearch через 3 активных индексатора (команда 87994) завершился с 0 загрузок. Этот результат не означал отсутствия MP3 на RuTracker: требовались поиск по артисту и проверка точных отказов пакета, указанных выше.

Временный обход, впоследствии отменён и заменён общим исправлением ниже: был создан отдельный профиль MBR MP3 160-320 (qualityProfileId=5) — MP3-160/192/224/256/320 и MP3-VBR-V2/V0. Он назначен только artistId=97; общий MP3 (default) и глобальные Quality Definitions не менялись. Конкретный MP3-пак RuTracker 5969222 выбран через POST /api/v1/release из кеша поиска по артисту с artistId=97: выполнен разовый ручной обход только оставшегося отказа по размеру. Бэкап артиста и исходного профиля: /mnt/RED_2TB/docker/arr/lidarr/mbr-fix-20261102T025546Z/.

Итог end-to-end: Transmission torrent 270, hash C485573C679DBF7E185BD72E08B11B4ACD7F5D97, скачан на 100%, ошибок 0, оставлен на раздаче. В /mnt/RED_2TB/storage/Music/MASTER BOOT RECORD проверен 101 непустой MP3, 1 302 439 874 байта; Lidarr подтверждает 11 полностью заполненных альбомов из 12. Новый Computer Metal (2026-10-30) отсутствует в пакете 2016–2024; отдельный поиск /release?albumId=1172 через 3 индексатора вернул 0 результатов. Он остаётся monitored/ожидающим, не заменён концертным Realtime Execution.

После импорта в очереди оставались предупреждения по дополнительным EP/OST/WAREZ из пакета, которых нет в текущем каталоге артиста, и ожидаемому, но отсутствующему Computer Metal. Завершённый пак убран только из отслеживаемой очереди штатным DELETE /queue/<id>?removeFromClient=false&blocklist=false&skipRedownload=false&changeCategory=false. Торрент и исходные файлы сохранены, релиз не блокировался, импортированные файлы проверены. После очистки — 0 строк MBR в очереди, torrent 100%/seeding, health Lidarr [].

На итоговой конфигурации MBR уже возвращён на общий qualityProfileId=1; временный профиль 5 удалён. Описание отдельного профиля выше сохранено как история временного обхода, а не инструкция по текущей настройке. Скачанные/импортированные файлы и раздача сохранены.

Общий поиск имён и псевдонимов без ручного MBID, 2026-11-02

Подтверждено живыми запросами: штатный api.lidarr.audio/search на Frugit возвращал Fruit/Fruity, хотя прямой lookup по MusicBrainz ID работал, а MusicBrainz находил Frugit по имени. Разовое добавление Frugit (1334) по ID было обходом и успело выполниться до просьбы пользователя остановить ручные исправления; оно не исправляло общий поиск. После этого новые артисты вручную не добавлялись.

Установлен общий read-only сервис lidarr-metadata-search, источник на NAS /mnt/RED_2TB/docker/arr/metadata-search/metadata_search.py, compose рядом metadata-search.compose.yml. Он передаёт остальные запросы официальному серверу без преобразования; поиск artist/all дополняет точными совпадениями имён, sort-name и сохранённых псевдонимов MusicBrainz. Подробные данные получает у прежнего сервера по автоматически найденному MBID. Индивидуальной таблицы артистов или исключений нет; сервис не вызывает API добавления артистов в библиотеку. Существующие точные основные имена сохраняют порядок перед дополнительными псевдонимами.

Штатная настройка GET/PUT /api/v1/config/metadataprovider/1: metadataSource=http://lidarr-metadata-search:5001/api/v0.4. Остальные поля metadata provider сохранены без изменений; перезапуск Lidarr не требовался. Docker: Python 3.12 Alpine, UID 950, read-only, без опубликованных портов, сеть media_net, restart unless-stopped, healthcheck и лимит памяти 256 MiB. Оба внешних источника используют прежний vless-proxy:1081; маршрут и IP не переключались. Запросы к каждому источнику ограничены интервалом 1.1 секунды, ответы кешируются; 429/Retry-After соблюдаются, при лимите lookup-запросы к тому же провайдеру не выполняются.

Приёмка проведена сначала отдельно, затем через реальные API Lidarr: /search?term=Frugit и /artist/lookup?term=Frugit находят правильного Frugit по имени; /search?term=Camellia включает японского かめりあ наряду с одноимёнными артистами; Radiohead остаётся первым точным совпадением. Отдельно проверен поиск альбома OK Computer и неизменная передача POST album lookup. MusicBrainz относительный score для точного псевдонима Camellia был 81: нельзя отбрасывать подтверждённый точный alias только из-за относительного рейтинга. Health Lidarr после переключения — []. Все 32 теста (17 worker + 15 поиска) прошли локально, 15 тестов поиска также прошли на NAS.

Бэкап исходного и итогового metadata provider config и приёмки: /mnt/RED_2TB/docker/arr/metadata-search/activation-20261102T071556Z/. Откат — через тот же API вернуть JSON metadata-provider-before.json (прежний metadataSource был пустым); только затем останавливать сервис, чтобы не оставить Lidarr с недоступным источником. Сервис требуется для текущего MetadataSource и поднимается Docker автоматически. Проверки сохраняются в shadow-validation.json и native-validation.json; секретов в этих JSON нет.

Полная сверка Obsidian watchlist с Lidarr, 2026-11-02

По явному запросу пользователя применён весь текущий family/plans/lidarr-artist-watchlist.md, включая тиры B/C и дельту библиотеки. Раньше заметка была списком без синхронизации с Lidarr; автопоиск обслуживал только уже monitored-артистов. Фактически в заметке 176 уникальных позиций: 175 исполнителей и Atomic Heart как серия из шести OST. Добавлен 91 отсутствовавший исполнитель, включён 61 ранее unmonitored; 23 уже отслеживались. Проверено: у всех 175 monitored=true, monitorNewItems=all. Существующий мониторинг вне списка сохранён.

Одного совпадения имени недостаточно: Agatha Christie в импортированной библиотеке оказалась английской писательницей (120), GMS — рэпером (463), Atomic Heart — trance-исполнителем (493). Эти посторонние записи остались выключены. Правильные соответствия: Агата Кристи (25; подтверждена альбомами из Spotify/Yandex), Growling Mad Scientists (1282), шесть Atomic Heart OST у Various Artists (альбомы 9622–9627). Для Camellia используется каноническое имя かめりあ, для Корсики — Коrsика; остальные неоднозначные имена сверены по жанрам и MusicBrainz ID.

Дополнительная причина нулевых каталогов: Standard разрешал только студийные Album. Создан общий metadataProfileId=3, Watchlist music и назначен всем 175 исполнителям: официальные Album/EP/Single, Studio/Soundtrack. Качество осталось общим qualityProfileId=1. Профили остальных артистов не менялись. Проверка ранее пустых каталогов после обновления: Christopher Larkin — 10 релизов, Darren Korb — 35, VINAI — 26 синглов, Marnik — 20 синглов; OVERWERK — 33 релиза (3 Album, 6 EP, 24 Single). Получение подробных метаданных и загрузки продолжаются.

У 15 старых импортированных записей сохранился AddOptions.Monitor=None: ArtistScannedHandler применяет его после завершения RefreshArtist, снова выключает альбомы и затем удаляет AddOptions. Обычный PUT артиста этот внутренний параметр не меняет. Он штатно отработан сканированием только 15 соответствующих папок (RescanFolders 88783, completed), затем проверен мониторинг альбомов всего списка. Полного сканирования /storage/Music и прямого редактирования SQLite не выполнялось. Общий worker теперь после обновления пустого каталога ждёт его RescanFolders и повторно проверяет мониторинг перед поиском; частичный выбор альбомов сохраняется. Регрессионный тест воспроизводит поздний сброс после RefreshArtist.

Снимок сопоставлений/приоритетов: /mnt/RED_2TB/docker/arr/lidarr-autosearch/watchlist.json. Worker соблюдает A → B → C → дельта; выключенных пользователем в Lidarr артистов сам не включает. Это снимок сверки, cron напрямую Obsidian не читает: последующие правки заметки требуют новой сверки. Исходная заметка со списками не переписывалась.

Первоначальный общий backfill запущен отдельным процессом с --max-artists 175, тем же worker, flock и состоянием; журнал initial-backfill.log в каталоге сверки. Регулярный cron 4 остаётся enabled, каждые 15 минут. Подтверждён штатный grab OVERWERK State и двух альбомов Заточки; массовый проход также добавляет Ott, Plini и других. Не считать grab/queued уже импортированными файлами. Для проверки фактического обмена найденные раздачи OVERWERK и Заточки запущены из очереди одним torrent-start-now; у OVERWERK подтверждено 34 432 822 принятых байта, error=0. На этом срезе Заточка ещё ожидала пиров, импорт этих примеров ещё не подтверждён. Подробные замеры сохранены в example-download-validation.json.

Бэкапы, все исходные artist/album JSON, результаты проверки и manifest: /mnt/RED_2TB/docker/arr/lidarr/watchlist-reconcile-20261102T042134Z/. До изменения worker: lidarr-autosearch/before-watchlist-fix-20261102T044754Z/. В каталоге сверки также сохранены прежние metadata profiles. Откат — только флаги/профили затронутых записей из JSON; новые записи при необходимости оставлять unmonitored, не удалять музыку. Все 17 тестов worker прошли локально и на NAS.

Зависание прогресса Transmission и ожидание Nautilus, 2026-11-04

Nautilus Pompilius (artist 69, MBID 247efe0f-80f1-477c-a4a0-b5cb1b8c832e) monitored; его ended/Inactive — метаданные о распавшейся группе и не причина остановки. Общий worker ещё 2026-11-02 09:45 UTC автоматически добавил MP3-пак 94 релиза 1982–2014, torrent 660, hash F1D29EDD16A2CB2328F5B95AFD96A6027E00F99F, размер 13 894 404 705 байт. К 2026-11-04 11:39 UTC у него status=3, downloadedEver=0, startDate=0: очередь не дошла до раздачи.

Реальная общая причина ожидания: активные загрузки Transmission 4.1.3 перестали учитывать уже записанные блоки и не завершались, удерживая очередь. У 26 активных музыкальных загрузок downloadedEver превышал размер раздачи более чем вдвое; суммарное превышение около 2,97 ТБ, помимо отдельно проверенной Мельницы (887 ГБ при размере 125 МБ). Это не признак выполненной загрузки. У большинства haveValid=0 при наличии файлов в incomplete; corruptEver не объяснял объём повторов. Перед восстановлением сохранены settings, live session, torrents/resume и снимки RPC в /mnt/RED_2TB/docker/transmission/backfill-recovery-20261104T114242Z/.

Выполнена штатная torrent-verify: сначала одна диагностическая раздача Мельницы восстановилась до 100%, затем все 26 загрузок с тем же подтверждённым признаком. Всего восстановлен прогресс 27 загрузок; первые три дошли до 100%. В History Lidarr подтверждён реальный импорт Мельницы и Ногу свело!, Би-2 получил отдельный albumImportIncomplete. Затем Transmission штатно перезапущен, ограничения очереди 10 / stalled 5 минут сохранились. После перезапуска haveValid и percentDone растут вместе с принятыми байтами (например, The Hatters с 5,6% до 44,7%); очередь больше не следует оценивать только по downloadedEver. На этом этапе было выполнено только разовое восстановление. Причина и постоянная настройка установлены последующим расследованием ниже.

Установленная причина и предотвращение повторения. В Docker log первая локальная ошибка — 2026-11-02T11:34:24+0700 (04:34:24 UTC): у Би-2 «Горизонт Событий» файл с русским названием имеет компонент 272 байта (277 с .part) при лимите файловой системы 255. Ошибка Filename too long (36) оставляет непишущиеся блоки в общем кеше Transmission 4.1.3. Последующие записи других раздач повторно пытаются вытеснить этот блок и получают чужую ошибку; байты принимаются, но GotBlock не публикуется и прогресс не растёт. Это соответствует разбору и коду PR 9049. PR не устанавливался: он ещё не включён в релиз.

Штатная возможность обхода внутреннего кеша присутствует в текущем бинарнике: в Cache::write_block при cache-size-mb=0 выполняется запись через tr_ioWrite без общего кеша. Установлено cache-size-mb=0, подтверждено в RPC и settings.json после перезапуска. Это предотвращает распространение ошибки одного торрента на остальные; кеш файловой системы ZFS продолжает работать. Периодические перезапуски или перепроверки как «лечение» не добавлялись.

Воспроизведение выполнено в изолированных временных контейнерах из того же image SHA d3adeda7a820f2fb562243e413b50973d2fc2ba0fe78eb0612b76dd8936c7a50, с внутренней Docker-сетью, собственными синтетическими сидером/трекером, без mounts production и без внешних раздач. При кеше 4 МБ намеренно длинное имя первой раздачи вызывает ту же ошибку, а исправная соседняя принимает 8 192 000 байт с haveValid=0 и 0%. При кеше 0 та же ошибочная раздача останавливается отдельно, исправная принимает ровно 8 388 608 байт, проверяет их и достигает 100%. Результаты: cache-regression-20261104T121040Z/cache-{4,0}/result.json под каталогом бэкапа. Контейнеры и временная сеть удалены.

Устранён также исходный триггер для будущей музыки: native script-torrent-added вызывает /config/hooks/normalize_music_paths.py. Только у Lidarr-торрентов он автоматически сокращает недопустимые UTF-8-компоненты пути через штатный torrent-rename-path, учитывая 255 байт для каталога и 250 байт для имени файла с резервом .part. Короткий вариант ≤240 байт сохраняет расширение и получает 12-символьный хеш исходного имени, чтобы различать похожие длинные названия. Меняется путь в клиенте, содержимое и infohash не меняются; обычные имена, другие категории и пользовательские паузы сохраняются. RPC выполняется на собственном интерфейсе контейнера с существующей авторизацией: loopback в данной установке исключён из WHITELIST; правила доступа не расширялись.

Проверены 4 теста UTF-8-границ файлов/каталогов, различения одинаковых обрезанных префиксов, обновления дочерних путей, сохранения пользовательских пауз и возобновления только ошибки длинного имени локально и на NAS. Дополнительная нативная приёмка on-add hook: синтетическое русское имя из 284 байт автоматически сокращено, обе раздачи дошли до 100%, SHA256 файла совпал с исходными данными. Результаты hook-regression-20261104T121545Z/cache-0-hook/result.json. На production проверена 341 ожидающая музыкальная раздача, найден и исправлен 1 длинный компонент (hash faba14712299d9a29836366a48ed9f0283eef76b, 272→240 байт); только этот ранее автоматически начатый, но остановленный по Filename too long торрент возвращён в обычную очередь. Остальные паузы сохранены. Снимки added-hook-before.json, overlong-paths-before.json, overlong-paths-fixed.json и исходный/новый скрипт — в том же бэкапе. Для отката вернуть только сохранённые поля кеша и on-add hook; не подменять живую БД или весь каталог загрузок.

Для проверки именно запроса пользователя Nautilus поднят штатным queue-move-top из конца общей очереди; это разовая смена порядка проверки после общего восстановления, без индивидуального профиля, ручного повторного добавления релиза или исключения в worker. Реальная приёмка: Nautilus сам перешёл из queued в downloading через обычную очередь (без torrent-start-now). На 2026-11-04 11:52:22 UTC downloadedEver=29 592 161, haveValid=28 035 681, percentDone≈0,213%, rateDownload=2 236 416 байт/с, peersConnected=1, errorString пуст. Снимок /mnt/RED_2TB/docker/transmission/backfill-recovery-20261104T114242Z/nautilus-transfer-verified.json. После постоянного исправления подтверждены 8 144 194 145 принятых байт, haveValid=7 846 218 337, прогресс 58,6%, скорость 8 503 296 байт/с, ошибок нет. Исходно сбойная раздача Би-2 также вернулась к status=4, errorString пуст; после постоянного исправления ещё одна другая раздача завершилась сама. Итоговые настройки и состояние сохранены в root-fix-final-validation.json: cache-size-mb=0 и on-add hook включён как в живом RPC, так и на диске; Health Lidarr []. Полную загрузку и импорт 14-ГБ пакета ещё не считать завершёнными.

Общая обработка названий RuTracker и очереди Transmission, 2026-11-02

Дополнительная проверка Rodrigo y Gabriela (812), Diablo Swing Orchestra (700), Триагрутрики (890) выявила включённый в Prowlarr RuTracker russianLetters=true (Strip Russian letters). Он удалял кириллицу, оставляя названия без имени Триагрутрики и слова «Дискография»; у Diablo оставалось - / Discography, которое Lidarr разбирал с неверным именем артиста. Общая настройка изменена на false через штатный API с настоящими credentials из SQLite, остальные поля сохранены. Отдельно штатный парсер Lidarr не поддерживает русские слова для диско/коллекций; это закрывает общая нормализация в автопоиске ниже.

Transmission ограничивал загрузки пятью слотами, зависшие раздачи занимали их до 30 минут. Общая очередь теперь 10 слотов, queue-stalled-enabled=true, queue-stalled-minutes=5; исходные параметры сохранены. Не считать строку queued доказательством принятых байтов: проверять downloadedEver, percentDone и историю импорта. Проверка общей нормализации через штатные решения уже добавила в Transmission MP3-дискографию Diablo Swing Orchestra (6 Albums, 2003–2021), Rodrigo y Gabriela (11 CD, 2001–2023), коллекцию Триагрутрики (2018–2022). Её более старый пак 128–320 пока штатно отклонён из-за недавнего AAC-256 Базирования в очереди (Recent grab event in history is of equal or higher quality); запрет не обходился, недостающие альбомы остаются в повторном поиске. Завершённое предупреждение импорта теперь не блокирует поиск других отсутствующих альбомов того же артиста; активные загрузки и importPending блокируют, как раньше.

Приёмка передачи данных: в 04:13:53 UTC для проверки выполнен один torrent-start-now для уже добавленных паков 327/328/329 (без смены настроек артистов и без выбора релизов вручную). К 04:14:09 фактически принято: Diablo 1 528 404 байта, Триагрутрика 3 567 967, Rodrigo 2 736 128; все status=4/downloading, error=0, подключены сиды. Перед этим они ожидали очереди, поэтому нули в статистике файлов не означали отсутствие найденных раздач. Импорт этих паков на момент среза ещё не завершён; не утверждать полное заполнение каталогов.

Реальный повторный запуск общего worker через TrueNAS cronjob.run 4 (job 2688, 04:09–04:10 UTC) завершился SUCCESS. В нём то же правило применилось к Агате Кристи и сохранило штатный отказ по уже имеющемуся качеству/cutoff; это подтверждает отсутствие принудительного обхода настроек.

Бэкап Prowlarr SQLite и исходного indexer JSON, параметров очереди: /mnt/RED_2TB/docker/arr/lidarr/rutracker-title-fix-20261102T040020Z/. До замены worker сохранены файлы в lidarr-autosearch/before-pack-normalization-20261102T040501Z/, перед снятием суточного ожидания — state-before-title-retry-reset.json. Откат — вернуть только russianLetters и параметры Transmission из JSON, при необходимости предыдущий worker. Не восстанавливать всю живую БД.

Общее исправление автозагрузки monitored-артистов, 2026-11-02

Причины были общими: профиль отбрасывал MP3 ниже 256/VBR-V2, лимит размера отклонял смешанные MP3-дискографии, а альбомный MissingAlbumSearch не находил пакеты по названию артиста. RSS каждые 15 минут проверяет новые публикации, но сам по себе не обеспечивает повторный поиск старых отсутствующих альбомов.

Исправлена общая настройка:

• В MP3 (default) (1) и Standard (3) разрешены также MP3-128/160/192/224; ранее разрешённые MP3 сохранены. FLAC не включался.
• Только у MP3 Quality Definitions maxSize=null (без верхнего лимита), чтобы размер смешанной дискографии не отклонялся по длительности части каталога. Другие форматы не менялись.
• Все текущие артисты используют общий профиль 1, включая MBR. Индивидуальные профили и ручной выбор раздачи для исправления не требуются.
• Общий список выбранных пользователем monitored-артистов сохранён: в момент проверки 36 из 1241. Остальная библиотека не включена в загрузку.

Постоянный автоматический поиск:

• TrueNAS cronjob 4, enabled, каждые 15 минут, пользователь truenas_admin; команда /usr/bin/python3 /mnt/RED_2TB/docker/arr/lidarr-autosearch/lidarr_autosearch.py.
• До 5 артистов за запуск; берутся только monitored-артисты с отсутствующими monitored-альбомами, уже вышедшими по дате. Артисты с активной загрузкой/поиском пропускаются, flock исключает пересечение запусков.
• Штатная команда ArtistSearch ищет дискографии и использует обычный механизм решений Lidarr. Для Various Artists используется MissingAlbumSearch, чтобы не искать все сборники разом. После поиска проверяются MP3-паки: общая нормализация переводит «Дискография»/«полная дискография»/«Коллекция» в Discography и распознаёт явное число ≥2 Albums/альбомов с диапазоном лет. Начальные жанровые теги и конечные псевдонимы убираются только при точном совпадении основного имени артиста. /parse обязан подтвердить тот же artistId, discography=true и выбранные monitored-альбомы. Затем POST /release/push проводит релиз через полный RSS decision engine. Если единственные отказы — Existing files meets cutoff: / Existing files on disk is of equal or higher preference:, пакет содержит реально отсутствующие вышедшие monitored-альбомы и эта раздача ещё не была grabbed, общий worker автоматически вызывает POST /release с исходными guid/indexerId из кеша поиска и ID отсутствующего альбома как привязкой. Это ограниченный обход блокировки частично скачанных паков; отказы по формату, качеству профиля, сидам, блоклисту и чужому артисту не обходятся. Native import распознаёт все папки альбомов внутри пакета и сохраняет свои проверки качества. За запуск принимается не более одного пака на артиста; сначала более широкий по выбранным альбомам. Персональных исключений по артистам нет.
• Повтор для того же набора отсутствующего — через 24 часа; новый набор отсутствующего или новая версия общей политики поиска допускают поиск без суточного ожидания. Текущая SEARCH_POLICY_VERSION=2: обновление общего правила повторно рассматривает всех подходящих артистов без ручного сброса Savant или других отдельных ID. Состояние — state.json, журнал — runs.jsonl рядом со скриптом.
• Если артист включён, monitorNewItems=all, а все существующие альбомы выключены, их monitoring восстанавливается. Частичный выбор альбомов, выключенные артисты и monitorNewItems=none сохраняются. Изменённые ID альбомов записываются в журнал для точного отката.
• Пустой каталог сначала получает RefreshArtist с artistIds=[id] и isNewArtist=true: этот флаг ограничивает последующее сканирование папкой артиста. Без него Lidarr ставит сканирование всей /storage/Music даже при одном ArtistIds.

На установке первоначальная версия обновления пустого каталога создала четыре лишних полных сканирования (88200/88205/88211/88214) перед импортом. Ошибка исправлена в автоматизации. Важный нюанс Lidarr: DELETE /command/id убирает queued-команду только из оперативной очереди, она возвращается из SQLite после рестарта. Для этих четырёх точно проверенных собственных задач выполнена резервная копия БД и перевод в Cancelled=5 при остановленном Lidarr; никакие другие команды/файлы не удалялись.

Бэкап общих профилей, ограничений и исходного мониторинга: /mnt/RED_2TB/docker/arr/lidarr/global-autosearch-fix-20261102T032053Z/. Бэкап до отмены собственных сканирований: lidarr-autosearch/cancel-owned-rescans-<UTC>/. До изменения cron сохранён cronjobs-before.json. При откате восстанавливать только затронутые настройки из JSON; не подменять целую живую БД и не удалять музыку.

Проверки обновления паков: 23 теста worker проходят на NAS и локально, вместе с 15 тестами общего поиска — 38 локальных тестов. Проверены границы monitoring, частичный выбор, повторы, версия политики, активные загрузки, будущие альбомы, Various Artists, область сканирования, многоальбомные заголовки и ограниченный обход только блокировок уже имеющихся файлов. Отдельный тест проверяет использование исходного кешированного guid и отсутствующего albumId. Бэкап worker/tests/state перед обновлением: /mnt/RED_2TB/docker/arr/lidarr-autosearch/backup-partial-packs-20261102T080214Z/. Реальная приёмка Savant: общий обработчик автоматически распознал RuTracker 3956208 «11 Albums, 3 Singles — 2011–2015», проверил native decisions и отправил пакет 2 111 099 121 байт в Transmission, torrent 654, hash FD6BC3D0651C28EF81368B923216CFA18D5BA773. Подтверждены grabbed в Lidarr и строки очереди с тем же downloadId; это один торрент, представленный в Lidarr по альбомам. При проверке torrent status=3 (ожидает очереди Transmission), ошибок нет, принятых байт ещё 0 — загрузку и импорт завершёнными не считать. В файлах пакета подтверждены недостающие ISM, Vario, Overworld и треки Cult. Пакет заканчивается 2015 годом и не содержит Mortals, Slasher, Alchemist 2: они остаются в поиске. Очередь Transmission включена (10 загрузок, stalled=5 минут); другие торренты передают данные, суммарно около 29,9 МБ/с при проверке. Cron 4 проверен enabled, */15, Health Lidarr — []. Реальный запуск через TrueNAS cronjob.run 4 завершился SUCCESS; штатные ArtistSearch автоматически отправили раздачи Infected Mushroom, Muse, Savant, Eminem, Rammstein, Ундервуд, Высоцкого, Пушного и других в Transmission. Проверены фактические принятые байты и завершённые раздачи, не только строки очереди. После освобождения импорта в истории подтверждены новые trackFileImported: Infected Mushroom 34, Savant 44, Muse 20, Billy Talent 10, Пневмослон 37 (срез проверки 2026-11-02, загрузки продолжаются). Реальные непустые MP3 по importedPath дополнительно проверены на диске. Повторных полных сканирований от этого запуска больше нет.

Симптом	Проверка	Исправление
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.