@@ -208,3 +208,53 @@ GET индексатора возвращает `********`. Нельзя исп
- [[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 релизов не обещать; корректно утверждать запуск двух названных раздач и включение остальных релизов в дальнейший поиск.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Taiga committed