1.Lidarr → `api.lidarr.audio` идёт через `http://vless-proxy:1081`.
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`.
@@ -64,11 +69,17 @@ Compose:
Настройки 3x-ui находятся на Taiga в `/mnt/RED_2TB/docker/xray-admin/x-ui.db`. Для пользователя `vless-space` используется цепочка:
```text
space-master → sub1-sweden-yt
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 должен иметь:
@@ -190,6 +201,164 @@ GET индексатора возвращает `********`. Нельзя исп
## 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 оставить включённым |
**⚠️ Важный питфолл:** после правки конфига НЕ использовать `docker restart cups-splix` — он убивает avahi-daemon (defunct), перед новым подъёмом обязателен **`docker stop cups-splix && docker rm cups-splix && docker compose up -d`** (полный пересоздание, чтобы entrypoint перевыполнился с нуля).
**✅ 2026-11-07: повторный сбой после перезагрузки TrueNAS устранён.** Старый entrypoint принимал оставшийся `/run/dbus/system_bus_socket` за живой D-Bus и пропускал его запуск; Avahi завершался, CUPS продолжал работать без mDNS. Дополнительно виртуальные сети Docker исчерпали лимит multicast-групп (`IP_ADD_MEMBERSHIP failed: No buffer space available`), поэтому восстановленный Avahi не публиковал IPv4-анонс в LAN. Теперь Avahi ограничен `allow-interfaces=enp3s0`; новый entrypoint очищает runtime-файлы, проверяет готовность D-Bus → Avahi → CUPS и контролирует процессы, IPP и фактическую публикацию принтера в LAN. При отказе/зависании завершает контейнер, который восстанавливает `restart: unless-stopped`; добавлен Docker HEALTHCHECK. Обычный `docker restart cups-splix` теперь поддерживается. Проверены два перезапуска, аварийное завершение каждого из трёх сервисов и зависание Avahi; после каждого восстановлены IPP и mDNS на `enp3s0 / 192.168.2.197:631`. Подробности, бэкап и проверка печати: [[personal/tech/samsung-clx-216x]].
| **Итого по записанной истории** | **33** | **160** |
---
Дни въезда и выезда включены. Для итогового годового статуса дни считаются с 1 января по 31 декабря; переходящий визит разделён между годами. Другие поездки, если они были, не учтены.
## Подсчёт скользящего окна
[ФНС: окончательный налоговый статус определяется за календарный год](https://www.nalog.gov.ru/rn77/ip/interest/reg_ip/resident_rf/). Порог — **183 дня**; чтобы остаться ниже него, допустимо максимум **182 дня за год**. Для промежуточного определения статуса налоговым агентом в течение года применяется период из 12 последовательных месяцев.
### На дату приезда 29.11.2026
## Следующий въезд с пребыванием до 31.12.2026
Окно 29.11.2025 → 28.11.2026:
- 29.11.25 → 14.03.26 = **106 дней**
- 04.07.26 → 30.08.26 = **58 дней**
- 06.09.26 → 19.09.26 = 14 дней
- **Итого: 178 дней** (запас: **4 дня** до 183)
Остаток на 2026 год: **182 − 160 = 22 дня**.
### Динамика окна при пребывании с 29.11.2026
**Самая ранняя дата въезда — 10.12.2026:** до 31.12.2026 включительно это ровно весь остаток, и годовой итог останется ниже порога. Условие: между последним указанным визитом и этой поездкой других дней в РФ нет.
- **29.11.26 → 14.03.27:** из окна выпадают дни 29.11.25→14.03.26 — все в РФ → +1 −1 = **счётчик стоит на 177**
- **15.03.27:** из окна начинают выпадать дни с 15.03.26 (КР) → каждый день в РФ даёт **чистый +1**
- Запас 6 дней → нужно выехать до **~21.03.2027**
### ⚠️ Безопасный выезд при поездке 29.11.2026
**Выехать не позднее 20.03.2027**
С 01.01.2027 начинается отдельный годовой счётчик; дальнейшие дни этого визита относятся к 2027 году.
---
@@ -64,11 +55,3 @@ tags:
2. Подать **3-НДФЛ** в РФ, указать доход от КР-ИП, сослаться на СИДН (ст. 7 — предпринимательская деятельность)
3. Приложить: сертификат резидентства КР, квитанции об уплате налога в КР, контракты
4. Налог уплаченный в КР засчитывается — доплачивается только разница (КР ~4–6%, РФ 13%)
---
## Вывод / план
- **Сейчас:** нерезидент РФ, всё чисто
- **Поездка 29.11.2026:** можно сидеть до **20.03.2027** — счётчик нейтрален пока выпадают дни зимы 2025/26 (были в РФ), с 15.03.27 начинает расти
- **Принцип:** следить за датами, особенно после длинного лета в РФ — запас резко сокращается
Актуально после исправления 2026-11-02: `sub1-sweden` — prefix selector; `fallbackTag` ссылаются на одноимённые **outbound типа loopback**, которые через отдельные inboundTag/routing-правила передают трафик следующему balancer. Ссылка `fallbackTag` прямо на balancer не работает. Подробности и проверка обеих резервных ступеней — [[family/how-to/arr-stack-taiga]].
Не использовать общий `leastLoad` как первый уровень для RuTracker/Kinozal: он может менять egress между соединениями. `maxRTT` и `tolerance` фильтруют кандидатов, но не делают выбор sticky.
Перед изменением базы сохранять backup. После изменения проверить сгенерированный `/app/bin/config.json` и выполнить `xray -test`; не редактировать сгенерированный файл напрямую.
- Конфигурация: `/mnt/RED_2TB/docker/cups/` на TrueNAS.
- После изменения конфигурации поднимать полным пересозданием:
- После изменения Dockerfile или скриптов пересобрать образ и пересоздать контейнер:
```bash
docker stop cups-splix
docker rm cups-splix
docker compose up -d
cd /mnt/RED_2TB/docker/cups
docker compose up -d --build --force-recreate cups-splix
```
- Не использовать`docker restart cups-splix`: Avahi после него становится zombie, mDNS пропадает.
- С 2026-11-07 обычный`docker restart cups-splix` поддерживается и проверен. Старый запрет относился к ошибке прежнего entrypoint; причина устранена (см. ниже).
- Из внешней сети печать идёт через SSH в контейнер; порт `631` наружу не опубликован.
- Образ основан на Debian 12; в нём CUPS, splix, Avahi, D-Bus и USB-утилиты. Точка входа запускает D-Bus, затем Avahi, затем `cupsd`.
- Каталоги `data`, `cache`, `spool` принадлежат `root:lp` и имеют права `0700`. Бэкап делать внутри контейнера через `docker exec … tar`, затем забирать `docker cp`.
- Локально собранный образ не переживает потерю docker data-root; конфигурация и USB-очередь сохраняются в `/mnt/RED_2TB/docker/cups/`, образ нужно пересобрать.
## Исправление повторного сбоя 2026-11-07
- Проверка по SSH: USB `04e8:3425` присутствовал, очередь была idle/enabled/accepting, но D-Bus отсутствовал, его socket от 31 августа возвращал `Connection refused`, Avahi был defunct. Контейнер повторно запустился 1 ноября после перезапуска TrueNAS.
- Причина: прежний entrypoint проверял только существование socket, запускал Avahi в фоне с подавлением ошибок и не контролировал дочерние процессы. Пересоздание контейнера обходило ошибку, но следующий старт существующего контейнера воспроизводил её.
- Дополнительная причина, обнаруженная проверкой mDNS после восстановления D-Bus: Avahi присоединялся ко всем виртуальным интерфейсам Docker и на физическом `enp3s0.IPv4` получал `IP_ADD_MEMBERSHIP failed: No buffer space available`. Из-за исчерпания multicast memberships оставалась лишь IPv6-публикация на LAN. В Dockerfile установлен `allow-interfaces=enp3s0`: mDNS печати работает только в домашней сети, новые сети Docker не расходуют его multicast memberships.
- Исправлены `/mnt/RED_2TB/docker/cups/{Dockerfile,entrypoint.sh}`, добавлен `healthcheck.sh`. При старте удаляются старые container-local socket/PID-файлы; D-Bus, Avahi и CUPS запускаются последовательно с проверкой готовности. PID 1 контролирует все три процесса и каждые 5 секунд проверяет Avahi по D-Bus и очередь по IPP. После трёх неудачных проверок или выхода процесса контейнер завершается; Docker автоматически поднимает его согласно сохранённому `restart: unless-stopped`. Завершение зависших процессов ограничено по времени. Ошибки Avahi видны в `docker logs`.
- В образ добавлен Docker HEALTHCHECK (15 секунд, timeout 12 секунд, start-period 30 секунд, retries 3). `healthcheck.sh` проверяет также фактический IPv4 mDNS-анонс очереди на `enp3s0`, а не только доступность процессов. Самовосстановление обеспечивает entrypoint: один HEALTHCHECK сам по себе контейнеры не перезапускает.
- Проверка: два `docker restart`; SIGKILL отдельно Avahi, D-Bus и CUPS; SIGSTOP Avahi для имитации зависания. После каждого теста контейнер healthy, IPP отвечает, `_ipp._tcp` разрешается на физическом `enp3s0` в `192.168.2.197:631`с правильным `rp=printers/Samsung_CLX-216x_Series`. Полный reboot TrueNAS не выполнялся.
- Одностраничное тестовое задание отправлено через LAN IPP; результат CUPS — completed. Печать именно с телефона удалённо не проверялась.
- Бэкап исходных Dockerfile/entrypoint/compose: `/mnt/RED_2TB/docker/cups/backup-startup-20261107T133009Z/`; прежний образ: `cups-splix:before-startup-20261107T133009Z`. Очередь, spool и USB-настройки сохранены.
# CPM stuck-messaging project: where we are, Nov/3
Internal metrics, keep out of public PRs. Task: [CPM: root-cause the stuck embedded extension messaging](https://app.asana.com/1/137249556945/project/72649045549333/task/1216761517055116?focus=true). Details: [[cpm-post-release-analysis-2026-10-27]], [[cpm-status-2026-10-15]].
**What the project has achieved so far**
Goal: permanent failures below 1% of DAU (0.2-0.5% = success). Permanent = no answer for 5 minutes, repeated or needed a reload.
**Now (macOS 1.214, iOS 7.244, Nov/2)**
- iOS: 0.44% of DAU (0.39% on 7.243, same day). Inside the target <<1%.
- macOS: 1.89%. Above the target <<1%.
**Fixes shipped**
- [P3](https://app.asana.com/1/137249556945/task/1219643764290826?focus=true), [OS<26.6 limit](https://app.asana.com/1/137249556945/task/1220003778559448?focus=true) – improves extension startup after a restart from up to 32 s → 0.1 s on iOS/macOS 26.6+ (lab tests). iOS 26.6+: "background missing" failures 8.2% → 0.3% of DAU (users with any failure 14.6% → 8.3%). Effect on permanent not measurable yet (one day, 90k users).
- macOS: [pinned tab lost on window close](https://app.asana.com/1/137249556945/task/1219643712648486?focus=true), [tab merging](https://app.asana.com/1/137249556945/task/1218356681060823?focus=true) – real bugs fixed, UI tests added. They caused under 1% of permanent failures, about 3x fewer after the fix (macOS 1.211 → 1.213).
- [P1](https://app.asana.com/1/137249556945/task/1219531810004072?focus=true) – recovery after a slow wake of the extension. Triggers for 19% of iOS and 3% of macOS daily users (Nov/2).
- [P2](https://app.asana.com/1/137249556945/task/1219531810004072?focus=true) – retry after load error 6. Triggers for 1.7% of iOS and 0.2% of macOS daily users (Nov/2).
- [Network process crash](https://app.asana.com/1/137249556945/task/1219531810004073?focus=true) – restart after the networking process crashes. Triggers for 6.6% of iOS and 4.2% of macOS daily users (Nov/2).
- [State restoration race](https://app.asana.com/1/137249556945/task/1218744813699966?focus=true) – restored tabs wait up to 5 s for the extension to start. Init failures on restore: iOS ~20% → ~8.5% of DAU, macOS no clear change.
**Fixes not confirmed by data (to be rolled back)**
- [Deallocation race](https://app.asana.com/1/137249556945/task/1217907325352233?focus=true) ([A/B](https://app.asana.com/1/137249556945/task/1218356681060819?focus=true), [flag](https://app.asana.com/1/137249556945/task/1219036128743441?focus=true)) – flag never turned on, no effect seen in the data.
- [Reload on the stuck signal](https://app.asana.com/1/137249556945/task/1218744813699968?focus=true) – 46% of macOS cases still got no answer after the reload.
- [P4](https://app.asana.com/1/137249556945/task/1219531810004072?focus=true) (late page reload) – off by default, never triggered.
**Fixes going public next week (Nov/9)**
- [Upgrade before loading](https://app.asana.com/1/137249556945/task/1220004977087625?focus=true) – load the new extension version first on launch. Removes part of the permanent failures right after an update (macOS 0.26% of DAU, iOS 0.05%).
- [Error 6 restart](https://app.asana.com/1/137249556945/task/1219939142983214?focus=true) – restart the extension when a load error leaves it broken. Up to 0.08% of DAU permanent on iOS, negligible on macOS.
- Together: macOS 1.89% → about 1.6%, iOS 0.44% → about 0.3-0.35%. Estimates, upper bounds.
By group on the new version (1.214 / 7.244, Nov/2), % of DAU. Trend is failures from the first day of the previous version (1.213 / 7.243, Oct/26) to the new version.
| Group | Platform | Failures, % of DAU | % of all failures | Permanent, % of DAU | % of all permanent | Failures trend, % of DAU |
- Remove fix and flag (did not work or never ran): [cpmBackgroundGraveyardTreatment](https://app.asana.com/1/137249556945/task/1218860893478440?focus=true), [cpmLateBackgroundDocumentRecovery](https://app.asana.com/1/137249556945/task/1219588497257482?focus=true), [cpmMessagingHangRecovery](https://app.asana.com/1/137249556945/task/1218855001659655?focus=true), [cpmBackgroundLoadRecovery](https://app.asana.com/1/137249556945/task/1219701603183698?focus=true).
- Remove with the diagnostics: [cpmDiagnosticsRecorder](https://app.asana.com/1/137249556945/task/1218785444896174?focus=true), [cpmBackgroundDelegateProxy](https://app.asana.com/1/137249556945/task/1218782530802146?focus=true).
- Remove the flag, keep the fix (already in 1.213 and 1.214): [webExtensionSharedPinnedTabWindowClose](https://app.asana.com/1/137249556945/task/1219660990760563?focus=true).
- Keep the fix and the flag as a kill-switch for now (remove after 2-3 releases without issues): [cpmNetworkProcessRecovery](https://app.asana.com/1/137249556945/task/1219701603183695?focus=true), [cpmStableBaseURL](https://app.asana.com/1/137249556945/task/1219728649844711?focus=true), [webExtensionStateRestorationGate](https://app.asana.com/1/137249556945/task/1218931841045393?focus=true), [cpmBackgroundLoadRestart](https://app.asana.com/1/137249556945/task/1219970564251181?focus=true).
- [Pixel data cleanup](https://app.asana.com/1/137249556945/task/1220159402040630?focus=true): remove the temporary pixels and episode parameters that only served the investigation.
Next, metrics (tasks to create):
- Permanent breakage metrics, replace the temporary pixels. Goal: track the permanent failure rate against DAU after the project closes.
- Episode report, trimmed to: outcome, tabs affected, repeat count, reload state, cause group (wake, load, update, error 6, tab not connected, other), platform and OS. Same shape on iOS and macOS.
- Healthy-navigation baseline: a 1% sample of navigations reports whether the extension answered and in which time bucket. Gives failures per navigation, not only per user.
- Health indicators dashboard: permanent failures, any failures, one-tab and browser-wide, per platform and version, against the 1% target.
- Old and new reports published together for one release, so the trend is not lost. Then the old ones go.
- Extension lifecycle metrics, to find where init on wake breaks. Goal: for init on wake failures, say at which step the chain stops.
- Stage ledger: the extension reports the last step reached for each navigation. Steps: page script injected, init sent by the page, init received by the background, config read from storage, app checks done (autoconsent on, feature on), dashboard update sent to the app, answer sent to the page, answer received by the page, response received by the app.
- Added to the failure report: last step reached and time spent in it.
- Background probe at failure time: is the background alive, does it answer a ping, how fast. Needs a spike first: does the probe see the background's state, and does it keep the background awake.
- Background lifecycle counters in the report: why it started (wake or load), age bucket, number of wakes in the session.
- Work: extension JS changes to send the steps, app changes to collect them, privacy review, extension and app releases. Data in 1-2 release cycles.
- Data check of the Nov/9 fixes: [Analyze attribution data after stage 3].
Open:
- No fix for macOS wake failures and tab not connected. If the new metrics show nothing actionable, close the project and reset the target.
Reference in new issue
Block a user
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