[2026-09-28] eagle: family/plans/lidarr-taiga-deploy.md personal/projects/balda/balda.md personal/tech/adk-hostedagent-openai-mcp.md personal/tech/flaresolverr-taiga.md

2026-09-28 15:24:26 +06:00
1 parent 5f3bdf6bff
commit f3dacaaa39
@@ -1,11 +1,12 @@
 # FlareSolverr на Тайге + обход блокировок индексеров

-> ✅ **СОСТОЯНИЕ 2026-09-28 (финал): инфраструктура готова, 2 дефекта на стороне трекеров.**
-> **Prowlarr** — `health` → `[]`, 6/6 индексеров настроены; RuTracker в карантине (капча, см. ниже).
-> **Radarr** — `health` → `[]`. **Sonarr** — `health` → `[]`.
-> **Lidarr** — SkyHook работает, 1 артист, поиск релизов отдаёт результаты.
-> ⚠️ Открыто: **RuTracker — капча на логин** (нужен ручной вход Alex), **RuTor — категории**
-> (не отдаёт фильмы/сериалы). Оба — на стороне трекеров, не инфраструктура.
+> ✅ **СОСТОЯНИЕ 2026-09-28 (поздний вечер, ФИНАЛ): ГЛАВНЫЙ ДЕФЕКТ ЗАКРЫТ — RuTracker починен Alex'ом.**
+> **Prowlarr** — `health` → `[]`, `indexerstatus` → `[]`, `caps` 1/5/6 → **200**, 6/6 настроены, RuTracker **вне карантина**.
+> **Radarr/Sonarr/Lidarr** — на момент последнего аудита держали **кэш health** со старым `RuTracker`;
+> лечится `docker restart radarr sonarr lidarr` (команда ждала апрува Alex — не выполнена в этой сессии).
+> **Lidarr** — SkyHook работает, `musicCategory=lidarr` применён (202), поиск релизов отдаёт **43** FLAC-раздачи.
+> ⚠️ Открыто **1**: **RuTor** — `no results in the configured categories` (трекер не отдаёт фильмы/сериалы,
+> не блокировка и не карантин). Всё остальное закрыто.
 > Контейнер `flaresolverr` (v3.5.2), порт `8191`, сеть `media_net`, `shm_size: 1gb`,
 > `LOG_LEVEL=warning`, **`PROXY_URL=socks5://vless-proxy:1080`**.
 > Compose — `/mnt/RED_2TB/docker/arr/docker-compose.yml` (6-й сервис).
@@ -285,6 +286,50 @@ RuTracker Auth Failed` и `Invalid Credentials for RuTracker [https://rutracker.
 каскад `429:TooManyRequests` в Radarr/Sonarr/Lidarr. Это нормальное поведение, лечится
 только восстановлением логина. См. питфолл про `429` ниже.

+## 🔑 ГЛАВНОЕ ОТКРЫТИЕ ПРО RuTracker: капча ПРИВЯЗАНА К СЕССИИ
+
+Самый запутанный пункт. Дефект выглядел как «неверный пароль», потом как «капча»,
+на самом деле — **капча выдаётся только для «холодных» сессий**.
+
+Замеры в одном ходе (скрипты `/tmp/fs_session_cmp.py`, `/tmp/fs_search_check.py`):
+
+```
+A: request.post /forum/login.php БЕЗ session      → len=13 335    ❌ форма логина вернулась
+B: request.post /forum/login.php С session=prowlarr → len=251 792 ✅ ЗАЛОГИНЕН
+C: request.get tracker.php?nm=...&f=... в той же сессии → len=254 745 ✅ выдача
+     auth_failed_in_html=False, login_form=False
+```
+
+🔴 **Вывод: логин через сессию `prowlarr` РАБОТАЕТ.** Капча отдаётся только новым
+(безымянным) сессиям — то есть `PROXY_URL` + переиспользование сессии `prowlarr` её обходят.
+Мой одиночный тест без сессии давал 13 KB и порождал ложный диагноз «капча блокирует всё».
+
+**Как проверить состояние RuTracker правильно:**
+```python
+# ВСЕГДА с session=prowlarr, иначе получишь ложную капчу
+{"cmd":"request.post","url":"https://rutracker.org/forum/login.php",
+ "postData":"login_username=...&login_password=...&login=...",
+ "session":"prowlarr","maxTimeout":240000}
+```
+Признак «залогинен» — **len ≈ 250 KB**, формы нет. 13 KB = сессия холодная, а не «пароль плох».
+
+> ⚠️ **Не делать вывод о пароле по тесту БЕЗ сессии.** Всегда `session=prowlarr`.
+
+### Как снялся карантин RuTracker (рабочая процедура)
+
+`health`/`indexerstatus` держат **кэш** (`disabledTill`), даже когда трекер уже отвечает.
+Снятие — **тем же тестом полным объектом**, что и для Kinozal:
+```bash
+docker exec prowlarr curl -s -H "X-Api-Key: $PK" http://localhost:9696/api/v1/indexer/1 > /tmp/p1.json
+docker cp /tmp/p1.json prowlarr:/tmp/p1.json
+docker exec prowlarr curl -s -X POST -H "X-Api-Key: $PK" -H "Content-Type: application/json" \
+  --data-binary @/tmp/p1.json http://localhost:9696/api/v1/indexer/test
+# → {} с HTTP=200  = карантин снят
+docker exec prowlarr curl -s -H "X-Api-Key: $PK" http://localhost:9696/api/v1/indexerstatus   # → []
+docker exec prowlarr curl -s -o /dev/null -w "%{http_code}" "http://localhost:9696/1/api?t=caps&apikey=$PK"  # → 200
+```
+Проверено: `{}` + **200** → `indexerstatus` пуст, `caps` → **200**.
+
 ## ✅ ЗАКРЫТО: пароль RuTracker — рабочий (первый диагноз был НЕВЕРЕН)

 **Итог 2026-09-28 (позже в тот же вечер):** сохранённая в Prowlarr пара
@@ -401,6 +446,44 @@ IP-литералы. Отсюда же следствие: после правк
 ⚠️ Откат: env-вариант убран из compose (бэкап
 `~truenas_admin/docker-compose.yml.bak-20260928-lidarr-proxy`).

+## ✅ ЗАКРЫТО: Lidarr — путь загрузки настроен (`musicCategory`)
+
+Отдельный дефект, найден позже в тот же вечер. Вопрос Alex: «Lidarr при добавлении будет
+качать в музыку?» — ответ был **нет**, и это подтвердилось фактами.
+
+**Было (сломано):**
+```
+musicCategory        = ""        ← пусто!
+musicDirectory       = ""
+musicImportedCategory= null
+```
+Следствие: Transmission получил бы задачу **без категории**, положил файл плоско в
+`/mnt/storage/Downloads`, а Lidarr ждал бы его в `/storage/Downloads/<категория>`.
+Скачивание прошло бы — **импорт в библиотеку упал**.
+
+**Стало (рабочий путь, проверено):**
+```
+Lidarr musicCategory = lidarr                                   ← PUT ?forceSave=true → 202
+Transmission: /mnt/storage/Downloads/lidarr                     ✅ существует (abc:abc)
+Lidarr:       /storage/Downloads/lidarr                         ✅ существует
+RemotePathMapping: /mnt/storage/Downloads/ → /storage/Downloads/ ✅
+rootFolder:   /storage/Music  (978 GB free, accessible)          ✅
+Скачается в:  /storage/Music/<Artist>/                           ✅
+Поиск релизов: 43 FLAC-раздачи (seeders 6/5/7)                    ✅
+```
+
+🔴 **`musicCategory` — дефолт `lidarr`** (не `music`!). Проверять по schema
+(`downloadclient/schema` → implementation `Transmission`) и сверять с реально
+существующим каталогом в Transmission. Radarr по той же схеме использует `radarr`,
+Sonarr — `sonarr`; каталоги `/mnt/storage/Downloads/{lidarr,radarr,sonarr}` уже созданы.
+
+Скрипт: `/tmp/lidarr_category.py` (GET downloadclient/1 → правка `musicCategory` → PUT `?forceSave=true` → 202 → read-back).
+⚠️ У полей бывает **нет ключа `value`** (`musicDirectory` = `''` без `value`) — не падать
+на `f['value']`, использовать `f.get('value')`.
+
+> ⚠️ **`monitored=false`** у добавленного артиста — Lidarr не начнёт качать, пока
+> у артиста не включён мониторинг альбомов (`Lidarr → Artist → Monitor`).
+
 ## 🔴 ПИТФОЛЛ: `test` требует ПОЛНЫЙ объект, не `{id}` → 400

 Во **всех** arr-сервисах (`Prowlarr`, `Radarr`, `Sonarr`, `Lidarr`) эндпоинт
@@ -483,12 +566,21 @@ localhost,127.0.0.1,vless-proxy,prowlarr,lidarr,radarr,sonarr,transmission,jelly
 - **~16:20** — карантин Kinozal/Kinozal(M) снят тестом полным объектом → `caps` 1/5/6 → 200.
  Radarr/Sonarr: `PUT ?forceSave=true` → 202, `docker restart` → `health` **`[]`**.
 - **~16:40** — RuTracker перестал логиниться: HTML сжался **251 KB → 13 KB**, в форме
-  найден `cap_code` + метка `Код:` → **трекер требует капчу**. Пара в Prowlarr
-  **не менялась** (сверено байт-в-байт с локальной копией) — диагноз «пароль неверен» ложный.
- **Итог:** инфраструктура Тайги чиста (Prowlarr/Radarr/Sonarr `health=[]`, Lidarr работает).
-  Открыты **2 дефекта на стороне самих трекеров**: капча RuTracker (нужен ручной вход Alex
-  браузером через тот же IP прокси) и категории RuTor (`no results in the configured
-  categories` — трекер не отдаёт фильмы/сериалы).
+  найден `cap_code` + метка `Код:` → диагноз «трекер требует капчу».
+  Пара в Prowlarr **не менялась** (сверено байт-в-байт с локальной копией) — «пароль неверен» ложный.
+- **~17:00** — Alex сам починил логин на трекере. Проверка выявила **ключевое**:
+  логин БЕЗ сессии → 13 KB (капча), логин **С `session=prowlarr`** → **251 792** ✅.
+  Капча привязана к «холодной» сессии; сессия Prowlarr её обходит. См. раздел
+  «ГЛАВНОЕ ОТКРЫТИЕ ПРО RuTracker».
+- **~17:10** — найден отдельный дефект Lidarr: `musicCategory` **пустая** → импорт
+  скачанного упал бы. Исправлено на `lidarr` (202); сверены каталоги, маппинг, root folder.
+  Поиск релизов: **43** FLAC-раздачи.
+- **~17:20** — карантин RuTracker снят тестом полным объектом → `{}` HTTP **200**,
+  `indexerstatus` → `[]`, `caps` idx1 → **200**. Prowlarr полностью чист.
+- **Итог:** инфраструктура Тайги чиста и проверена. Открыт **1** дефект — RuTor
+  (`no results in the configured categories`, на стороне трекера). Остаток-механика:
+  `docker restart radarr sonarr lidarr` для сброса **кэша health** со старым RuTracker
+  (команда ждала апрува Alex, в этой сессии не выполнена).

 ### Что делать при возврате симптома «индексера недоступны»