--- 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/`. 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/?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](https://github.com/transmission/transmission/pull/9049). PR не устанавливался: он ещё не включён в релиз. Штатная [возможность обхода внутреннего кеша](https://github.com/transmission/transmission/pull/5668) присутствует в текущем бинарнике: в `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-/`. До изменения 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.