452 lines
101 KiB
Markdown
Executable File
452 lines
101 KiB
Markdown
Executable File
---
|
||
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.
|
||
|
||
### Зависание прогресса 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. Не восстанавливать всю живую БД.
|
||
|
||
### Скачивание Pain по отдельному запросу, 2026-11-05
|
||
|
||
После включения лайкнутых артистов без автоматического скачивания пользователь отдельно запросил скачивание Pain. Для Pain (22, MBID `84d5a9df-dd85-43e9-92f3-ed87bcd59b58`) установлены `monitored=true`, `monitorNewItems=all`, общий metadata profile 3 «Watchlist music»; общий MP3 quality profile 1 сохранён. Scoped RefreshArtist с `artistIds=[22]`, `isNewArtist=true` и ожиданием его rescan обновил каталог: 28 релизов, все monitored. ArtistSearch выполнен. Другие артисты, RSS, cron и настройки Transmission не менялись. Резервная копия: `/mnt/RED_2TB/docker/arr/lidarr-autosearch/pain-download-20261105T075334Z/`.
|
||
|
||
Подтверждены правильные загрузки: `Pain - I Am (2024)`, NoNaMe Club 1723621, MP3-320, размер 100 501 591 байт, hash `9F3DB2FC47A67845CAC508D3134B6384E04AF79D`; `Pain - Party in My Head (2021) Single`, MP3-320, hash `3948AC0B02448C12B950185751E50DF6F75B407E`. Проверка 5 ноября в 14:04:24 по Бишкеку: I Am — downloading, 212 992 байта приняты, 131 072 проверены, 1 пир, скорость 40 960 байт/с; Party in My Head — добавлен, downloading, 0 байт и 0 пиров. Основные NNM-трекеры отвечают Success, сидов 7 и 3 соответственно. Ошибок торрентов нет. Загрузку и импорт всей дискографии завершёнными не считать. Доказательство — `pain-transmission-verification.json` рядом с worker.
|
||
|
||
Во время поиска выявлено ложное сопоставление штатного Lidarr: чужой `Painkiller - Pain and Destruction (2023)` был привязан к альбому Pain (499). Торрент `BD2B0210F09A1FA887EBE3C611596FD86F7E0612` немедленно остановлен; на проверке им было принято 0 байт. Неправильная раздача помечена штатным blocklist через DELETE queue с `removeFromClient=false`, `blocklist=true`, `skipRedownload=true`, затем удалена только из Transmission с `delete-local-data=false`. Повторно проверено, что этого hash в клиенте нет. Файлы не удалялись и ошибочного импорта не было. Это блокировка конкретной неверной раздачи, не заявление об исправлении всех неоднозначных сопоставлений штатного поиска. Исходная проверка — `pain-initial-transmission-check.json`.
|
||
|
||
Дополнительно проверен MP3-пак Kinozal 859659 «Pain - Discography Metal 1997–2016». Его MP3-каталоги подтверждают несколько нужных альбомов, но в заголовке нет битрейта: обычный `/parse` определяет качество Unknown. Полный `/release/push` отклонил кандидат по Unknown, лимиту размера для этого качества и уже имеющимся VBR-V0-файлам. Битрейт не выдумывался, эти отказы не обходились, пакет не скачивался. Результат — `pain-pack-decision.json`. Сопоставление всей дискографии или загрузку всех 28 релизов не обещать; корректно утверждать запуск двух названных раздач и включение остальных релизов в дальнейший поиск.
|
||
|
||
|
||
### Скачивание Geoffrey Day / Geoffplaysguitar по отдельному запросу, 2026-11-05
|
||
|
||
После массового включения лайкнутых артистов без скачивания пользователь отдельно запросил загрузку Geoff. Geoffrey Day (491, MBID `472a8c1b-ffef-400a-b4b4-8d5741d3ca85`) и GeoffPlaysGuitar — одна запись: последнее имя присутствует в её псевдонимах. Только этому артисту назначен уже существующий общий metadata profile 3 «Watchlist music», сохранён общий MP3 quality profile 1, установлены `monitored=true`, `monitorNewItems=all`. Scoped RefreshArtist с `artistIds=[491]`, `isNewArtist=true` и ожиданием его rescan наполнил каталог: 29 релизов, все monitored. ArtistSearch завершился успешно, но скачал 0 отчётов: подходящих сольных MP3 в проверенных индексерах пока не найдено. Резервная копия настроек и каталогов до/после: `/mnt/RED_2TB/docker/arr/lidarr-autosearch/geoff-download-20261105T074710Z/`.
|
||
|
||
Лайкнутые треки Geoff из Atomic Heart относятся к сборникам Various Artists (1239), а не к его сольному каталогу. По явному запросу на скачивание выбран найденный MP3-320 пакет RuTracker 6483234, размер 1 248 114 702 байта. До отправки проверен torrent metainfo: MP3-каталоги содержат точные названия всех шести уже выбранных OST Vol.1–6 (album IDs 9622–9627). Дополнительно в паке есть шесть Singles/EP. Не считать эти шесть синглов автоматически сопоставленными или импортированными.
|
||
|
||
Это разовая операция скачивания по запросу пользователя, не новая персональная настройка автопоиска. Исходный заголовок «Atomic Heart Soundtrack Collection (Various Artists) …» не распознавался штатным альбомным поиском. После подтверждения всех выбранных альбомов в содержимом для native `/parse` использован заголовок `Various Artists - Discography 2023-2026 MP3 320kbps`; он распознал ровно шесть нужных OST. Оригинальные guid, размер, proxy download URL и индексер сохранены. `/release/push` пропустил пакет через полный decision engine: approved=true, rejections=[]; принудительный `/release` и обход качества не использовались. Другие артисты, RSS и cron не менялись.
|
||
|
||
Transmission torrent 724, hash `B9D1249744F59A196728EEA12E5308DDD0D90C8F`, имя `Atomic Heart Soundtrack Collection`. Проверка 5 ноября в 13:50:57 по Бишкеку: downloading, 18,18%, downloadedEver=226 883 598 байт, haveValid=203 733 006, rateDownload=11 378 688 байт/с, 3 пира, errorString пуст. Это одна раздача с шестью grabbed-записями по альбомам, не шесть торрентов. Полный импорт на момент проверки не подтверждён. Доказательства: `geoff-atomic-grab-result.json`, `geoff-transmission-verification.json`, `geoff-atomic-metainfo.torrent` рядом с worker; JSON с приватным proxy URL хранится только на NAS.
|
||
|
||
|
||
### Лайкнутые артисты: мониторинг без автоматического скачивания, 2026-11-05
|
||
|
||
По запросу пользователя включены ранее выключенные лайкнутые артисты из проверенного CSV Spotify/Яндекс. Область операции — 733 сопоставленные записи из `liked-artists-unmonitored-2026-11-05.csv`, а не все 1333 записи Lidarr. На момент выполнения 731 артист ещё был unmonitored: им установлены `monitored=true` и `monitorNewItems=none`. Для всех их существующих альбомов подтверждён `monitored=false`; менять альбомные флаги фактически не понадобилось, они уже были выключены. Каста (62) и Geoffrey Day (491) к этому времени были включены пользователем: их настройки сохранены. 78 несопоставленных имён не добавлялись и не подменялись похожими артистами.
|
||
|
||
Это режим отдельных артистов. RSS индексеров, automatic/interactive search, TrueNAS cron 4 и прежние загрузки не отключались. Настройки всех остальных артистов и альбомов, quality/metadata profiles, пути и теги сохранены. Поисковые команды и загрузки этой операцией не отправлялись.
|
||
|
||
Важно различать три настройки в Lidarr 3.1.6.5079: `monitored` артиста; флаги `monitored` уже известных альбомов; `monitorNewItems` для альбомов, впервые обнаруженных при обновлении каталога. Значение `none` третьей настройки не выключает уже выбранные альбомы, поэтому проверены оба уровня. Для данного режима оставлять `monitorNewItems=none`: существующий worker восстанавливает полностью выключенные альбомы только для артистов с `monitorNewItems=all`. При `none` такое восстановление не выполняется. Пустой каталог может обновляться через общий worker, но вновь обнаруженные альбомы останутся без мониторинга. Наличие артиста в monitored само по себе не означает, что его альбомы запрошены к скачиванию.
|
||
|
||
Операция выполнена через штатные `PUT /api/v1/artist/editor` и `PUT /api/v1/album/monitor`, без прямых изменений БД. На время массовой записи взят существующий `worker.lock`; cron оставлен enabled. Порядок: сначала новые альбомы — None при ещё выключенном артисте, затем проверка выключенных существующих альбомов, затем включение артиста. Это исключает промежуточный запрос дискографии.
|
||
|
||
Резервная копия, манифест и приёмка: `/mnt/RED_2TB/docker/arr/lidarr-autosearch/monitor-only-likes-20261105T073539Z/` (`before.json`, `result.json`, `follow-up-verification.json`). Одноразовая операция — `enable_liked_artists_monitor_only.py`, список — `liked-artists-monitor-only-targets.json` рядом с общим worker. Это не новая периодическая задача. Восстановление — через native API вернуть только выбранным ID значения `monitored`/`monitorNewItems` из `before.json`, а не восстанавливать живую БД целиком.
|
||
|
||
Повторная проверка 5 ноября в 13:37 по Бишкеку: все 733 сопоставленные записи CSV включены; у 731 изменённого артиста новые альбомы — None и 0 monitored-альбомов. Новых grabbed и новых записей очереди для них нет. Всего в Lidarr теперь 925 monitored-артистов; настройки остальных сохранены. Исходный CSV является снимком до этой операции и больше не означает текущий выключенный мониторинг.
|
||
|
||
|
||
### Автопоиск русских имён при латинском имени 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.
|
||
|
||
### Автопоиск русских имён при латинском имени MusicBrainz, 2026-11-05
|
||
|
||
У Plamenev (artist 473, MBID `8a907c72-8387-4da1-871b-4467cf0abddc`) мониторинг всех четырёх альбомов был включён, но ArtistSearch 2–4 ноября каждый раз скачивал 0 отчётов. Причина подтверждена кодом `SearchCriteriaBase.ArtistQuery => Artist.Name`: штатный поиск использовал только `Plamenev`. В текущем MusicBrainz и в ArtistMetadata.Aliases нет русских псевдонимов этого MBID. Такой запрос находил только MP3-сингл Princess, отсутствующий в текущем каталоге, и FLAC-пак с неизвестным артистом. Запрос `Пламенев` в тех же настроенных индексерах находит MP3-дискографии RuTracker 5777792 и NoNaMe Club 1254828. Это проблема полноты имени запроса, а не выключенного monitoring или недоступных индексеров.
|
||
|
||
Постоянное общее исправление — модуль `/mnt/RED_2TB/docker/arr/lidarr-autosearch/lidarr_alias_search.py`, вызываемый обычным worker после ArtistSearch и нормализации паков. Он работает только с monitored-артистами, у которых 0 импортированных треков и не было grabbed: уже скачанные или зависшие пакеты не дублируются. Нужны как минимум два вышедших monitored-альбома. Используются сохранённые кириллические псевдонимы; дополнительно допускается обратимая транслитерация латинского имени, только если как минимум два названия альбомов кириллические. За один проход отправляется не более двух альтернативных запросов. Неподдержанные буквы не угадываются. Общие правила не содержат имён/ID конкретных артистов.
|
||
|
||
Альтернативный поиск идёт через Prowlarr только в индексеры, уже включённые в automatic search самого Lidarr. До принятия пакета читается только небольшой torrent metainfo: его MP3-пути должны содержать два разных названия нужных monitored-альбомов, а заголовок — соответствовать имени/его транслитерации. Аудиокниги, чужие авторы, FLAC, одно совпадение и будущие/выключенные альбомы такой проверки не проходят. После подтверждения содержимого переводится название дискографии в каноническое имя и повторно вызываются `/parse` и **полный `/release/push` RSS decision engine**. Ограничения качества, сидов и monitoring сохраняются; принудительного `/release` в этом модуле нет.
|
||
|
||
`SEARCH_POLICY_VERSION=3`: смена общей политики повторно рассматривает подходящих артистов без ручного сброса состояния Plamenev. Cron 4, периодичность и профили не изменялись. Бэкап прежних worker/tests/state: `/mnt/RED_2TB/docker/arr/lidarr-autosearch/backup-name-search-20261105T051857Z/`. Сначала установлен модуль-зависимость, затем атомарно опубликован worker. Все 50 тестов прошли локально и на NAS (8 новых тестов альтернативного поиска, 23 worker, 15 metadata search, 4 имён файлов).
|
||
|
||
Реальная приёмка 05:19:50 UTC: этот же общий обработчик нашёл по `Пламенев` и проверил в NoNaMe Club 1254828 MP3-пак «3 альбома, 9 сборников, 2013–2021» размером 1 304 529 537 байт. Подтверждены каталоги «Герой с тысячью лиц», «Крадущая сны», «Для мира на земле». Lidarr одобрил пакет без единого отказа; Transmission hash `F5754EEF71798B17B3E961346CDEE1DCBF91A9F7`. На 05:27:08 UTC downloadedEver=166 529 665, haveValid=166 300 289, прогресс 12,8%, скорость 1 146 880 байт/с, один подключённый сид, ошибок нет. Английский The Hero With a Thousand Faces не найден в проверенных каталогах пакета и остаётся monitored. Пока не объявлять всю загрузку/импорт завершёнными. Нативное подтверждение и состояние библиотеки: `plamenev-name-search-validation.json`; события `alternate_name_search` / `alternate_pack_decision` в `runs.jsonl`.
|
||
|
||
|
||
Границы исправления: это общий дополнительный этап установленного автопоиска, а не патч исходников Lidarr или исправление MusicBrainz. Он закрывает расхождение латинского/кириллического имени для MP3-дискографий при перечисленных проверках. Одиночные релизы, артисты с одним альбомом, уже имеющимися импортированными треками или предыдущим grabbed этим этапом не обслуживаются; произвольные псевдонимы не угадываются. Поэтому исправление не гарантирует загрузку любого отсутствующего артиста. Для первичной приёмки был вручную вызван тот же общий обработчик с текущим artistId; релиз, торрент и особое правило для Plamenev вручную не задавались. Последующие запуски выполняет общий worker через cron.
|
||
|
||
### Лайкнутые артисты: мониторинг без автоматического скачивания, 2026-11-05
|
||
|
||
По запросу пользователя включены ранее выключенные лайкнутые артисты из проверенного CSV Spotify/Яндекс. Область операции — 733 сопоставленные записи из `liked-artists-unmonitored-2026-11-05.csv`, а не все 1333 записи Lidarr. На момент выполнения 731 артист ещё был unmonitored: им установлены `monitored=true` и `monitorNewItems=none`. Для всех их существующих альбомов подтверждён `monitored=false`; менять альбомные флаги фактически не понадобилось, они уже были выключены. Каста (62) и Geoffrey Day (491) к этому времени были включены пользователем: их настройки сохранены. 78 несопоставленных имён не добавлялись и не подменялись похожими артистами.
|
||
|
||
Это режим отдельных артистов. RSS индексеров, automatic/interactive search, TrueNAS cron 4 и прежние загрузки не отключались. Настройки всех остальных артистов и альбомов, quality/metadata profiles, пути и теги сохранены. Поисковые команды и загрузки этой операцией не отправлялись.
|
||
|
||
Важно различать три настройки в Lidarr 3.1.6.5079: `monitored` артиста; флаги `monitored` уже известных альбомов; `monitorNewItems` для альбомов, впервые обнаруженных при обновлении каталога. Значение `none` третьей настройки не выключает уже выбранные альбомы, поэтому проверены оба уровня. Для данного режима оставлять `monitorNewItems=none`: существующий worker восстанавливает полностью выключенные альбомы только для артистов с `monitorNewItems=all`. При `none` такое восстановление не выполняется. Пустой каталог может обновляться через общий worker, но вновь обнаруженные альбомы останутся без мониторинга. Наличие артиста в monitored само по себе не означает, что его альбомы запрошены к скачиванию.
|
||
|
||
Операция выполнена через штатные `PUT /api/v1/artist/editor` и `PUT /api/v1/album/monitor`, без прямых изменений БД. На время массовой записи взят существующий `worker.lock`; cron оставлен enabled. Порядок: сначала новые альбомы — None при ещё выключенном артисте, затем проверка выключенных существующих альбомов, затем включение артиста. Это исключает промежуточный запрос дискографии.
|
||
|
||
Резервная копия, манифест и приёмка: `/mnt/RED_2TB/docker/arr/lidarr-autosearch/monitor-only-likes-20261105T073539Z/` (`before.json`, `result.json`, `follow-up-verification.json`). Одноразовая операция — `enable_liked_artists_monitor_only.py`, список — `liked-artists-monitor-only-targets.json` рядом с общим worker. Это не новая периодическая задача. Восстановление — через native API вернуть только выбранным ID значения `monitored`/`monitorNewItems` из `before.json`, а не восстанавливать живую БД целиком.
|
||
|
||
Повторная проверка 5 ноября в 13:37 по Бишкеку: все 733 сопоставленные записи CSV включены; у 731 изменённого артиста новые альбомы — None и 0 monitored-альбомов. Новых grabbed и новых записей очереди для них нет. Всего в Lidarr теперь 925 monitored-артистов; настройки остальных сохранены. Исходный CSV является снимком до этой операции и больше не означает текущий выключенный мониторинг.
|
||
|
||
### Скачивание Geoffrey Day / Geoffplaysguitar по отдельному запросу, 2026-11-05
|
||
|
||
После массового включения лайкнутых артистов без скачивания пользователь отдельно запросил загрузку Geoff. Geoffrey Day (491, MBID `472a8c1b-ffef-400a-b4b4-8d5741d3ca85`) и GeoffPlaysGuitar — одна запись: последнее имя присутствует в её псевдонимах. Только этому артисту назначен уже существующий общий metadata profile 3 «Watchlist music», сохранён общий MP3 quality profile 1, установлены `monitored=true`, `monitorNewItems=all`. Scoped RefreshArtist с `artistIds=[491]`, `isNewArtist=true` и ожиданием его rescan наполнил каталог: 29 релизов, все monitored. ArtistSearch завершился успешно, но скачал 0 отчётов: подходящих сольных MP3 в проверенных индексерах пока не найдено. Резервная копия настроек и каталогов до/после: `/mnt/RED_2TB/docker/arr/lidarr-autosearch/geoff-download-20261105T074710Z/`.
|
||
|
||
Лайкнутые треки Geoff из Atomic Heart относятся к сборникам Various Artists (1239), а не к его сольному каталогу. По явному запросу на скачивание выбран найденный MP3-320 пакет RuTracker 6483234, размер 1 248 114 702 байта. До отправки проверен torrent metainfo: MP3-каталоги содержат точные названия всех шести уже выбранных OST Vol.1–6 (album IDs 9622–9627). Дополнительно в паке есть шесть Singles/EP. Не считать эти шесть синглов автоматически сопоставленными или импортированными.
|
||
|
||
Это разовая операция скачивания по запросу пользователя, не новая персональная настройка автопоиска. Исходный заголовок «Atomic Heart Soundtrack Collection (Various Artists) …» не распознавался штатным альбомным поиском. После подтверждения всех выбранных альбомов в содержимом для native `/parse` использован заголовок `Various Artists - Discography 2023-2026 MP3 320kbps`; он распознал ровно шесть нужных OST. Оригинальные guid, размер, proxy download URL и индексер сохранены. `/release/push` пропустил пакет через полный decision engine: approved=true, rejections=[]; принудительный `/release` и обход качества не использовались. Другие артисты, RSS и cron не менялись.
|
||
|
||
Transmission torrent 724, hash `B9D1249744F59A196728EEA12E5308DDD0D90C8F`, имя `Atomic Heart Soundtrack Collection`. Проверка 5 ноября в 13:50:57 по Бишкеку: downloading, 18,18%, downloadedEver=226 883 598 байт, haveValid=203 733 006, rateDownload=11 378 688 байт/с, 3 пира, errorString пуст. Это одна раздача с шестью grabbed-записями по альбомам, не шесть торрентов. Полный импорт на момент проверки не подтверждён. Доказательства: `geoff-atomic-grab-result.json`, `geoff-transmission-verification.json`, `geoff-atomic-metainfo.torrent` рядом с worker; JSON с приватным proxy URL хранится только на NAS.
|
||
|
||
### Скачивание Pain по отдельному запросу, 2026-11-05
|
||
|
||
После включения лайкнутых артистов без автоматического скачивания пользователь отдельно запросил скачивание Pain. Для Pain (22, MBID `84d5a9df-dd85-43e9-92f3-ed87bcd59b58`) установлены `monitored=true`, `monitorNewItems=all`, общий metadata profile 3 «Watchlist music»; общий MP3 quality profile 1 сохранён. Scoped RefreshArtist с `artistIds=[22]`, `isNewArtist=true` и ожиданием его rescan обновил каталог: 28 релизов, все monitored. ArtistSearch выполнен. Другие артисты, RSS, cron и настройки Transmission не менялись. Резервная копия: `/mnt/RED_2TB/docker/arr/lidarr-autosearch/pain-download-20261105T075334Z/`.
|
||
|
||
Подтверждены правильные загрузки: `Pain - I Am (2024)`, NoNaMe Club 1723621, MP3-320, размер 100 501 591 байт, hash `9F3DB2FC47A67845CAC508D3134B6384E04AF79D`; `Pain - Party in My Head (2021) Single`, MP3-320, hash `3948AC0B02448C12B950185751E50DF6F75B407E`. Проверка 5 ноября в 14:04:24 по Бишкеку: I Am — downloading, 212 992 байта приняты, 131 072 проверены, 1 пир, скорость 40 960 байт/с; Party in My Head — добавлен, downloading, 0 байт и 0 пиров. Основные NNM-трекеры отвечают Success, сидов 7 и 3 соответственно. Ошибок торрентов нет. Загрузку и импорт всей дискографии завершёнными не считать. Доказательство — `pain-transmission-verification.json` рядом с worker.
|
||
|
||
Во время поиска выявлено ложное сопоставление штатного Lidarr: чужой `Painkiller - Pain and Destruction (2023)` был привязан к альбому Pain (499). Торрент `BD2B0210F09A1FA887EBE3C611596FD86F7E0612` немедленно остановлен; на проверке им было принято 0 байт. Неправильная раздача помечена штатным blocklist через DELETE queue с `removeFromClient=false`, `blocklist=true`, `skipRedownload=true`, затем удалена только из Transmission с `delete-local-data=false`. Повторно проверено, что этого hash в клиенте нет. Файлы не удалялись и ошибочного импорта не было. Это блокировка конкретной неверной раздачи, не заявление об исправлении всех неоднозначных сопоставлений штатного поиска. Исходная проверка — `pain-initial-transmission-check.json`.
|
||
|
||
Дополнительно проверен MP3-пак Kinozal 859659 «Pain - Discography Metal 1997–2016». Его MP3-каталоги подтверждают несколько нужных альбомов, но в заголовке нет битрейта: обычный `/parse` определяет качество Unknown. Полный `/release/push` отклонил кандидат по Unknown, лимиту размера для этого качества и уже имеющимся VBR-V0-файлам. Битрейт не выдумывался, эти отказы не обходились, пакет не скачивался. Результат — `pain-pack-decision.json`. Сопоставление всей дискографии или загрузку всех 28 релизов не обещать; корректно утверждать запуск двух названных раздач и включение остальных релизов в дальнейший поиск.
|
||
|
||
|
||
### Защита от подмены артиста при поиске Lidarr, 2026-11-09
|
||
|
||
В штатном Lidarr 3.1.6.5079 обычный разбор `Painkiller - Pain and Destruction` извлекал артиста Painkiller. При повторном разборе в контексте ArtistSearch разделитель `(\W*|\b)` мог совпасть с пустой строкой. Lidarr выделял `Pain` из начала `Painkiller` и связывал результат с альбомом Pain. Последующая проверка сравнивала уже подставленного артиста. [Парсер исходной версии](https://github.com/Lidarr/Lidarr/blob/v3.1.6.5079/src/NzbDrone.Core/Parser/Parser.cs#L341-L401), [повторный разбор](https://github.com/Lidarr/Lidarr/blob/v3.1.6.5079/src/NzbDrone.Core/DecisionEngine/DownloadDecisionMaker.cs#L75-L104).
|
||
|
||
Общее исправление требует границ имени артиста и названия альбома. Повторный разбор сохраняет явно распознанного артиста. Сопоставление раздачи по имени допускает нормализованное каноническое имя или один точный известный псевдоним. Правила применяются в штатном поиске, RSS и `/release/push`. Импорт по файловым тегам, настройки качества, мониторинг и расписание worker сохранились.
|
||
|
||
Сборка `lidarr-artist-guard:3.1.6.5079-20261109` установлена в compose сервиса `lidarr`. Базовый LSIO образ помечен `lidarr-guard-base:3.1.6.5079`. SHA256 работающего `Lidarr.Core.dll` — `5c37fec42858c216d06dd93a8a91cb44c1d6ae8c2cb58d953b9f68487c7264aa`. Исходник, патчи, результаты API и лог тестов лежат в `/mnt/RED_2TB/docker/arr/lidarr-guard-build-20261109/`. Для сборки использован исходный тег `v3.1.6.5079` и SDK .NET 8.0.427. Анализаторы отключены для сборки из архива, имеющиеся предупреждения NuGet NU1902 и NU1903 сохранены как предупреждения. После обновления Lidarr требуется перенести патч на новый исходный тег и повторить проверки.
|
||
|
||
В `ParserFixture` прошло 104 теста, 2 пропущены. Изолированный API-тест сравнил исходный и исправленный контейнеры с одной копией каталога и без производственного blocklist. Исходный контейнер принимал Painkiller как Pain и Museums как Muse. Исправленный отклонил эти результаты и принял правильные Pain и Muse, сохранив сопоставление GeoffPlaysGuitar с Geoffrey Day. Доказательства — `parser-fixture-verified.log` и `api-regression.json`.
|
||
|
||
Для отката взять исходный compose из `deployment-before-20261109T104155Z/`, вернуть только строку `image` сервиса Lidarr, указав сохранённый `lidarr-guard-base:3.1.6.5079`. Проверить `docker compose config -q`, затем применить `docker compose up -d --no-deps --force-recreate --pull never lidarr` из каталога arr. Данные и настройки находятся в прежних bind mounts.
|
||
|
||
### Очередь скачивания и импорта Lidarr, 2026-11-09
|
||
|
||
В исходной очереди 663 строки соответствовали 121 раздаче. Диск имел около 9,7 ТБ свободного места. Transmission не показывал ошибок записи. Большинство строк относились к уже скачанным альбомам и сборникам. Типичные ошибки импорта — выбранное издание не совпадает с файлами, отсутствуют или не распознаны треки, в одном пакете несколько версий альбома. Три незавершённые раздачи без пиров — Нейромонах Феофан, Dance With The Dead и Pendulum.
|
||
|
||
Каста, «Чернила осьминога (Deluxe)» (album 861, release 4080). В торренте 23 MP3, в каталоге выбранного издания 22. Дополнительный ремикс «Врун-врун» сдвинул номера следующих бонусов. Все 22 нужных файла однозначно сопоставлены по тегам названия и длительности с допуском 2 с и скопированы штатной командой ManualImport. Проверены 22 привязки и файлы в библиотеке. Исходные 23 MP3 остались в раздаче на 100%. План и результат — `lidarr-autosearch/album-recovery-20261109T102156Z/`.
|
||
|
||
Ещё 19 предупреждений по раздачам сняты после проверки каждого запрошенного альбома по каталогу, привязанным trackFile ID и размерам файлов на диске. Использован штатный DELETE queue с `removeFromClient=false`, `blocklist=false`, `skipRedownload=true`. Повторную регистрацию того же завершённого торрента Чайфа подтвердили записи истории Lidarr. У этого торрента метка Transmission заменена на `lidarr-imported`, поэтому Lidarr пропускает его при опросе. Путь, файлы и раздача сохранены. Доказательства — `already-imported-queue-*.json`, `chaif-transmission-before.json`, `chaif-transmission-after.json` и `final-verification.json` в каталоге сборки.
|
||
|
||
Pain. Ранее начатые `I Am` (11/11) и `Party in My Head` (2/2) скачаны и импортированы. После установки защиты через штатный `/release/push` прошли проверенные MP3-релизы `Coming Home` и `You Only Live Twice`. В 16:55:56 по Бишкеку `You Only Live Twice` был полностью импортирован штатно, 18/18 файлов по изданию 3199 подтверждены на диске. `Coming Home` скачан на 28,6%. На тот момент оставалось 96 ошибок импорта по отдельным раздачам, 1 раздача ожидала импорта и 4 скачивались или ждали пиров. Ошибок Transmission не обнаружено. Доказательства — `pain-album-search-follow-up.json`, `post-scan-verification.json` и `latest-lidarr-verification.json` в каталоге сборки.
|