obsidian-vault/family/how-to/arr-stack-taiga.md

---
title: Arr stack — TrueNAS Taiga
created: '2026-05-23'
updated: '2026-11-02'
type: tech
namespace: family
tags:
  - arr
  - taiga
  - truenas
  - media
  - operations
related:
  - '[[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:

```text
/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` используется цепочка:

```text
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 должен иметь:

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

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

## FlareSolverr и RuTracker

Entrypoint:

```text
/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-тега:

```text
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 их не устраняет.

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

```bash
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:

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

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

SkyHook:

```bash
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`:

```bash
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.

### Общая обработка названий 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.