[2026-09-27] eagle: personal/plans/music-artist-albumartist-repair.md personal/tech/batch-data-edit-review-loop.md personal/tech/music-tags-repair-truenas.md personal/tech/skill-truenas-administration.md

2026-09-27 20:44:17 +06:00
1 parent cb60ba12f9
commit f3c44270c5
@@ -414,6 +414,42 @@ RC-сверка (`/tmp/rc_verify.py` → `RC-VERIFY.csv`) дала **7861 рас
 `track_number = 0` = «номер не проставлен» — сравнивать с пустым значением из плана
 с учётом этого, иначе 1699 ложных расхождений.

+### 33. 🔴🔴 ПЕРЕГЕНЕРАЦИЯ «С НУЛЯ» ТЕРЯЕТ РУЧНЫЕ ПРАВКИ — строить от прошлого плана, не от скрипта
+
+Продолжение урока 29, но глубже. Мало найти генератор — надо понять, **чем он НЕ является**.
+
+`Sbornik_Novij_Rok` дал регрессию **второй раз**: генератор `build_fix_plan2.py`, запущенный
+с нуля, переписал верный `album = 'Сборник нового рока'` на имя папки на **200 файлов**.
+
+**Причина оказалась НЕ в отсутствии защиты.** Форензика Zulip DB показала: папка правилась
+**руками** 26 сентября — тремя прогонами (`patch mode=patch` по целым строкам,
+`source = manual (user decision)`): транслит ~55 строк (`Kontrabandy`→`Контрабанды`),
+треки из имени файла 199, срезанные `!`/`?`. **Все эти решения жили в `tag-fix-plan.csv`
+и `APPLY-PLAN.csv`, а НЕ в генераторе** — генератор воспроизводит только механику 38-й волны.
+
+**Правило:** новый план строить **от `new_*` предыдущего плана как базы**, дописывая только
+целевое правило. Перегенерация из исходного инвентаря «с нуля» **обязательно** теряет ручные
+решения, потому что они нигде в коде не записаны.
+**Проверка перед генерацией:** взять 3-5 известных ручных правок из прошлого плана и убедиться,
+что генератор даёт для них то же значение. Иначе — не генерировать.
+
+### 34. 🔴 Стоп-список обязан содержать ЛАТИНСКУЮ ТРАНСЛИТЕРАЦИЮ
+
+`Sbornik_Novij_Rok` **не ловился ни одним из трёх механизмов** генератора (проверено кодом,
+`/tmp/check_sbornik.py`): `NON_ARTIST` → `False`, `CATEGORY_DIRS` → `False`,
+`is_release_folder` → `False`, `has_word(norm, EVENT_WORDS)` → `False`.
+Причина: во всех списках слово `сборник` есть **только по-русски**, а папка названа
+**латиницей** (`sbornik_novij_rok`).
+
+В этой библиотеке транслит — норма, не исключение: `Sbornik_Novij_Rok`, `Df1`, `ZabuGor`,
+`RacinG_Portal`, `PaDoNkÈ[NTL]`. Любой `grep` по русскому стоп-слову их пропускает.
+
+**Правило:** каждый стоп-список дублировать латиницей (`sbornik`, `sborka`, `raznoe`,
+`izbrannoe`, `hity`, `luchshee`, `novoe`, `staroe`, …); для конкретных папок-контейнеров —
+отдельное множество точных имён (`CONTAINER_FOLDERS`).
+**Проверка:** прогнать стоп-списки по реальным именам папок и убедиться, что известные
+контейнеры дают `True`, а известные артисты (`5'nizza`, `Little Big`) — `False`.
+
 ## Связанное

 - [[personal/tech/music-tags-repair-truenas]] — волновой лог канонического инстанса
@@ -49,6 +49,20 @@ related:
 > генератор это поле не заполняет) и `track` 3505 (`0` ↔ `''` нормализовать).
 > **Диф НЕ готов к показу Alex.**
 >
+> ✅ **БЛОКЕР ЗАКРЫТ (продолжение 29-секси, 2026-09-27):** форензика Zulip DB доказала, что
+> `Sbornik_Novij_Rok` правился **РУКАМИ** 26 сен (3 прогона: транслит ~55, треки 199, баг 3)
+> через `patch` в `tag-fix-plan.csv` — **в генераторе защиты не было никогда**, т.к. списки
+> содержат только русское `сборник`, а папка названа латиницей. Фикс: новое множество
+> `CONTAINER_FOLDERS` (`sbornik_novij_rok`, `df1`, …) + проверка в `derive_from_path` перед
+> `return only, only`; `EVENT_WORDS` дополнен латинской транслитерацией. Перегенерация:
+> `fix` 5079 → **4878**. Диагноз кодом — `/tmp/check_sbornik.py`.
+> 🔑 **МЕТОД-УРОК: любой стоп-список обязан содержать латинскую транслитерацию** — папки тут
+> транслитерированы (`Sbornik_Novij_Rok`, `Df1`, `ZabuGor`), русское написание не срабатывает.
+> 🔑 **АРХИТЕКТУРА: генератор воспроизводит только механику 38-й волны.** Все ручные решения Alex
+> живут в `APPLY-PLAN.csv`, НЕ в генераторе → **новый план строить от `new_*` плана, дописывая
+> целевое правило, а НЕ перегенерацией «с нуля»** (иначе ручные правки теряются).
+> Подробно — [[personal/plans/music-artist-albumartist-repair]] § ЗАКРЫТИЕ БЛОКЕРА.
+>
 > Подробно — [[personal/plans/music-artist-albumartist-repair]] § СЕССИЯ 29-СЕКСИ.
 >
 > ⚠️ **НОВОЕ (сессия 28): детектор «файл в корне папки артиста» сравнивал на РАВЕНСТВО
@@ -52,7 +52,8 @@ ssh truenas_admin@mallexxx.duckdns.org "cd /mnt/RED_2TB/storage/Music && ls -d *
 scp /tmp/ndignore-new truenas_admin@mallexxx.duckdns.org:/tmp/ndignore-new
 ssh truenas_admin@mallexxx.duckdns.org "cp /tmp/ndignore-new /mnt/RED_2TB/storage/Music/.ndignore"
 ```
-Navidrome подхватывает файл по рестарту; после скана проверить, что игнор сработал —
+Затем **`docker restart navidrome`** (в контейнере `curl /api/scanner/status` → `404`, эндпоинта
+нет; подхват идёт по рестарту + watcher). После скана проверить, что игнор сработал —
 игнорируемые получают **`missing=1`, их НЕ удаляют**:
 ```bash
 sqlite3 /mnt/RED_2TB/docker/navidrome/data/navidrome.db \
@@ -61,12 +62,15 @@ sqlite3 /mnt/RED_2TB/docker/navidrome/data/navidrome.db \
   SELECT COUNT(*) FROM media_file WHERE missing=0 AND path NOT LIKE 'backup%';"  -- живая музыка
 ```
 **Контрольное число:** живая музыка = числу строк плана (**7861** на 2026-09-27).
-Факт после фикса: всего **8396**, `missing=1` **535**, живая **7861** ✅.
+Факт после фикса: всего **8396**, `missing=1` **535**, живая **7861** ✅ (до фикса было 8167/306).

 > 🔴 **ОБЯЗАТЕЛЬНЫЙ ФИЛЬТР в ЛЮБОМ запросе к `media_file`:**
 > `missing=0 AND path NOT LIKE 'backup%'`
 > Без него читаешь бэкап-копии и делаешь ЛОЖНЫЕ выводы. Эта ошибка дала неверный отчёт
 > «скобки не исправлены» — бэкап был выдан за живое дерево.
+> 🔑 **Правило на будущее (Alex: «Да»):** любой новый `backup*` под библиотекой — в `.ndignore`
+> **в том же прогоне, что его создал**. Файл создан 03:49, бэкапы — 05:17 и 06:19; список
+> просто не обновили. Скрипты бэкапа обязаны дописывать себя сами.

 ## 1. Создание НОВОГО каталога под `/mnt/<POOL>/docker/` — из контейнера