[2026-09-28] eagle: family/plans/lidarr-taiga-deploy.md personal/plans/flaresolverr-taiga-deploy.md personal/tech/flaresolverr-taiga.md

personal/plans/flaresolverr-taiga-deploy.md

@@ -1,8 +1,11 @@
 # FlareSolverr на Тайге + обход блокировок индексеров — план/отчёт
 
-> **Статус: ✅ ВЫПОЛНЕНО 2026-09-28. Итог 6/6 индексеров, `health` → `[]` (пусто).**
-> Поиск «matrix» → **256 результатов** (RuTor 100, RuTracker 50, NoNaMe 50, Kinozal 50, Byrutor 6).
-> **RuTracker впервые `valid` за всё время стека (с 2026-05-20).**
+> **Статус 2026-09-28 (конец дня): инфраструктура готова, 1 пункт открыт.**
+> FlareSolverr развёрнут, все 6 индексеров настроены, поиск «matrix» → **256 результатов**
+> (RuTor 100, RuTracker 50, NoNaMe 50, Kinozal 50, Byrutor 6). **RuTracker впервые `valid`
+> за всё время стека (с 2026-05-20).**
+> 🔴 **Открыто:** `IndexerStatus` в `prowlarr.db` — RuTracker `EscalationLevel=9` до +24 ч.
+> Снимается **только SQL** (план ниже), карантин даёт warning каскадом во все четыре сервиса.
 > Полный разбор, все питфоллы и команды — [[personal/tech/flaresolverr-taiga]].
 > Связано: [[personal/plans/lidarr-taiga-and-indexer-unblock]],
 > [[family/projects/media-toolbox-taiga]], [[family/how-to/arr-stack-kraken]],
@@ -12,6 +15,8 @@
 > навсегда остаётся без прокси → `ERR_NAME_NOT_RESOLVED` → Prowlarr пишет ложное
 > «blocked by CloudFlare» (симптом маскируется под таймаут CF). Лечится
 > `sessions.destroy` + `session:"prowlarr"`; пересоздаётся сама.
+> 🔴 **Второй питфолл:** `POST /indexer/test` карантин **НЕ снимает, а продлевает** —
+> каждая «попытка починить тестом» удлиняла `DisabledTill`. Карантин живёт в `IndexerStatus`.
 
 ## ФАКТИЧЕСКОЕ СОСТОЯНИЕ (2026-09-28, после деплоя)
 
@@ -234,14 +239,90 @@ GET https://rutracker.org/forum/login.php  через socks5h://vless-proxy:1080
   `Downloads/{radarr,sonarr}` (Radarr/Sonarr их ждали), выявлен **неверный пароль RuTracker**.
   Детали — [[family/plans/lidarr-taiga-deploy]], [[personal/tech/flaresolverr-taiga]].
 
+## 🔴 2026-09-28 (ночь): НАЙДЕНА ИСТИННАЯ ПРИЧИНА ЗАЛИПА — таблица `IndexerStatus`
+
+Итог долгой петли: «снять карантин тестом → warning возвращается → тест падает заново».
+Петля не сходилась, потому что **причина лежит в БД Prowlarr, а не в прокси/FlareSolverr**.
+
+**Пруф — прямой дамп таблицы (хост Тайги, `sqlite3` в контейнере НЕТ, на хосте ЕСТЬ):**
+```bash
+DB=/mnt/RED_2TB/docker/arr/prowlarr/prowlarr.db
+sqlite3 "file:$DB?mode=ro" \
+  "SELECT Id, ProviderId, InitialFailure, MostRecentFailure, EscalationLevel, DisabledTill FROM IndexerStatus;"
+```
+
+```
+Id  ProviderId  InitialFailure            EscalationLevel  DisabledTill
+1   5 Kinozal      2026-09-28 09:43:24    2                2026-09-28 10:08
+2   6 Kinozal M    2026-09-28 09:32:45    2                —
+3   4 NoNaMe       2026-09-28 07:57:42    0                —
+4   2 RuTor        2026-05-20 05:45:18    0                —
+5   1 RuTracker    2026-09-28 09:04:28    9                2026-09-29 09:46   ← СУТКИ
+6   3 Byrutor      —                      0                —
+```
+
+🔴 **RuTracker: `EscalationLevel = 9` (максимум), `DisabledTill` = +24 ч.** Prowlarr сам
+выключил индексер на сутки. Пока запись держится, `caps` отдаёт **429**, Prowlarr не делает
+новых попыток, фоновый health-чек Radarr/Sonarr/Lidarr бьёт по 429 → **warning каскадом во все
+четыре сервиса**. Отсюда «Radarr health чист, а warning живёт» — он живёт не у Radarr.
+
+⚠️ **Тест индексера карантин НЕ снимает, а ПРОДЛЕВАЕТ.** Наблюдалось вживую: `DisabledTill`
+`15:44` → `21:45` после одного `POST /indexer/test`. То есть каждая попытка «починить тестом»
+удлиняла блокировку. **Это и была петля.**
+
+### ✅ РАБОЧИЙ ПЛАН СНЯТИЯ (согласован, 2 команды + бэкап)
+
+На Кра́кене применялся тот же приём — см. [[family/how-to/arr-stack-kraken]]
+§«(3) Блокировки индексера в БД — рестарт их НЕ сбрасывает».
+
+**1. Бэкап через `.backup`, НЕ `cp`** (БД в WAL-режиме):
+```bash
+DB=/mnt/RED_2TB/docker/arr/prowlarr/prowlarr.db
+TS=$(date +%Y%m%d-%H%M%S)
+sqlite3 "file:$DB?mode=ro" ".backup /home/truenas_admin/prowlarr.db.bak-$TS"
+shasum -a 256 "$DB" "$OUT"        # сверить, что копия снята
+```
+✅ **Сделано:** `~/prowlarr.db.bak-20260928-032611` — 581 632 байт,
+sha256 исходника `d792777c3545969dba57339d1b956f11aef40da91596b266839068a1a1af7845`.
+
+**2. Стоп → очистка → старт** (⚠️ `docker stop` требует апрува Alex — истёк дважды):
+```bash
+docker stop prowlarr
+sqlite3 "$DB" "DELETE FROM IndexerStatus WHERE ProviderId IN (1,5,6);"
+docker start prowlarr
+```
+
+**3. Проверка:**
+```bash
+PK=$(cat /home/truenas_admin/pk.txt)
+curl -s -H "X-Api-Key: $PK" http://localhost:9696/api/v1/indexerstatus   # → пусто
+for I in 1 5 6; do curl -s -o /dev/null -w "idx$I=%{http_code}\n" \
+  "http://localhost:9696/$I/api?t=caps&apikey=$PK"; done               # → 200
+```
+
+**Таблицы в `prowlarr.db` (для справки):** `Indexers`, `IndexerStatus`, `IndexerProxies`,
+`ApplicationIndexerMapping`, `IndexerDefinitionVersions`.
+
+> ⚠️ **Урок:** health-эндпоинты arr-сервисов **не являются источником истины** о блокировках.
+> На Кра́кене это записано отдельно: «`GET /api/v1/health` и `/api/v1/indexerstatus` НЕ показывают
+> причины блокировки» — авторитет за `prowlarr.debug.txt` и таблицей `IndexerStatus`.
+> На Тайге `indexerstatus` причины показывал, но **снятие через API не срабатывало** — только SQL.
+
 ## Остаток после сессии 2026-09-28 (не блокирует Prowlarr/FlareSolverr)
 
-1. 🔴 **Пароль RuTracker неверен** — POST-логин через FS возвращает форму логина + «неверные
-   данные» + капча. Нужен верный пароль от Alex. Даёт `Auth Failed` в `testall` Prowlarr.
-2. **Radarr/Sonarr:** каталоги `Downloads/{radarr,sonarr}` созданы, но `RemotePathMappingCheck`
-   в health держится — нужен `docker restart radarr sonarr` (кэш проверки). ⏳ не выполнен.
-3. Indexer-warnings в Radarr/Sonarr снимаются `POST /api/v3/indexer/testall`
-   (отдаёт **400** с телом-массивом по индексеру — парсить тело, не код).
-4. Приёмка Alex в UI: `https://prowlarr.mallexxx.duckdns.org` → 6 зелёных;
-   `https://lidarr.mallexxx.duckdns.org` → поиск артиста работает.
-   Открытый вопрос по swap закрыт Alex (не нужен — RAM 21 GB).
+1. ⏳ **Снять `IndexerStatus` через SQL** — план выше, шаг 2 ждёт апрува на `docker stop prowlarr`.
+   Единственный незакрытый пункт, дающий warning каскадом во все четыре сервиса.
+2. ✅ **Пароль RuTracker — вопрос закрыт: пароль ВЕРНЫЙ.** Проверено `request.post` через FS:
+   `len=251 792`, форма логина не вернулась. Первый диагноз «пароль неверен» был ложным —
+   признак «форма вернулась» проверять по **`final_url` + длине HTML**, а не по подстроке
+   `login_username` (она есть и на залогиненной странице). Подтверждено и через сессию
+   `prowlarr`: логин `254 410`, поиск `254 745`, `Auth Failed` в HTML отсутствует.
+   `Auth Failed` в Prowlarr при живом логине = **следствие `IndexerStatus`**, а не пароля.
+3. ✅ **Radarr/Sonarr:** `docker restart radarr sonarr lidarr` выполнен → `RemotePathMappingCheck`
+   ушла, health **пуст** у обоих.
+4. ⚠️ **RuTor:** `no results in the configured categories` — не блокировка. На Кра́кене тот же
+   дефект, лечение известно: RuTor не фильтрует по категориям, ему нужна **`8000(Other)`**,
+   не `5000`. На Тайге не применено.
+5. **Приёмка Alex в UI:** `https://prowlarr.mallexxx.duckdns.org` → 6 зелёных;
+   `https://lidarr.mallexxx.duckdns.org` → поиск артиста работает. Alex подтвердил:
+   **«все зеленое, логин починен»**. Открытый вопрос по swap закрыт Alex (не нужен — RAM 21 GB).