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. Не восстанавливать всю живую БД.

Автопоиск русских имён при латинском имени 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.

Общее исправление автозагрузки 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=3: обновление общего правила повторно рассматривает всех подходящих артистов без ручного сброса отдельных 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.