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

2026-09-28 14:02:20 +06:00
1 parent 02bff81fa8
commit e8addc7298
@@ -1,8 +1,10 @@
 # Lidarr на Taiga — деплой в связке с arr-стеком и Navidrome

 **Дата:** 2026-09-28
-**Статус:** 🟢 ДЕПЛОЙ ВЫПОЛНЕН, health ЧИСТЫЙ. ⏳ Не закрыта приёмка: поиск артиста блокирован
-403 Cloudflare на `api.lidarr.audio` (метаданные). Решение — прокси, скрипт готов, не применён.
+**Статус:** 🟡 ДЕПЛОЙ ВЫПОЛНЕН, контейнер жив, `health` ЧИСТЫЙ (`[]`) — **НО ФУНКЦИОНАЛЬНО
+НЕ РАБОЧИЙ**. ⏳ Приёмка не закрыта: SkyHook (`api.lidarr.audio`) → **403 Cloudflare**,
+в библиотеке **0 артистов**, добавить артиста невозможно. Решение — прокси, скрипт готов,
+не применён. Перепроверено 2026-09-28 вечером — блокер в силе.
 **Namespace:** family
 **Решения Alex:** (1) переименование — **вариант A**: `Rename Tracks=ON`, `Rename Folders=ON`,
 раскладка `Music/<Artist>/<Album>/<track> - <title>`, `Write Metadata Tags=ON`;
@@ -47,6 +49,36 @@ via http 1081 : 200  ✅
 via socks5 1080: 200  ✅
 ```

+### 🔁 ПЕРЕПРОВЕРЕНО 2026-09-28 (вечер, после деплоя FlareSolverr)
+
+Блокер **подтверждён живым запросом** — не устарел, ничего не изменилось:
+
+```
+GET http://localhost:8686/api/v1/artist/lookup?term=radiohead
+ → {"message":"Search for 'radiohead' failed. Unable to communicate with LidarrAPI.
+     HTTP request failed: [403:Forbidden] [GET] at
+     [https://api.lidarr.audio/api/v0.4/search?type=artist&query=radiohead]"}
+
+GET /api/v1/artist          → []            ← В БИБЛИОТЕКЕ 0 АРТИСТОВ
+GET /api/v1/release?artistId=0 → "Artist with ID 0 does not exist"
+```
+
+🔴 **Уточнение диагноза: это ЧИСТО Cloudflare, НЕ DNS.** Раньше формулировка «режется по гео IP»
+оставляла место для DNS-версии. Факт:
+
+```bash
+docker exec lidarr sh -c 'nslookup api.lidarr.audio'   # → 2606:4700:3031::ac43:df35 (Cloudflare)
+docker exec lidarr sh -c 'curl -w "%{http_code}" https://api.lidarr.audio/...'                 # → 403
+docker exec lidarr sh -c 'curl -w "%{http_code}" -x socks5h://vless-proxy:1080 https://api.lidarr.audio/...'  # → 200
+```
+
+Домен **резолвится** из контейнера (в отличие от трекеров, где был NXDOMAIN) — значит
+`PROXY_URL`-подход FlareSolverr здесь ни при чём, Lidarr ходит в SkyHook **сам**, и ему нужен
+**свой** прокси на уровне процесса. Только env `HTTP_PROXY`/`HTTPS_PROXY`.
+
+⚠️ **Побочный факт:** деплой FlareSolverr на этот блокер **не повлиял** — FlareSolverr
+обслуживает только Prowlarr, а SkyHook зовёт сам Lidarr. Не путать эти два маршрута.
+
 **Готовая заготовка (НЕ применена):** `/tmp/add_proxy_env.py` — впишет в сервис `lidarr`:
 ```yaml
      - HTTP_PROXY=http://vless-proxy:1081
@@ -20,17 +20,20 @@ status: deployed
 ---
 # *arr Stack на Тайге — Setup & Config

-> ✅ **STATE 2026-09-28: LIDARR РАЗВЁРНУТ — 7-й сервис стека, music-менеджер.**
-> Live: **`https://lidarr.mallexxx.duckdns.org`** → HTTP 200, TLS Let's Encrypt, **health ЧИСТЫЙ**.
+> 🟡 **STATE 2026-09-28: LIDARR ДЕПЛОЙ ЕСТЬ, НО ФУНКЦИОНАЛЬНО НЕ РАБОЧИЙ.**
+> Live: **`https://lidarr.mallexxx.duckdns.org`** → HTTP 200, TLS Let's Encrypt, `health` → `[]`.
 > Контейнер `lidarr` **v3.1.0.4875-ls42**, порт 8686, uid 950, `media_net` + `caddy_default`.
 > API-ключ `166654ac3f054096ae0e8393fb1bf940`. Compose — в общем `/mnt/RED_2TB/docker/arr/docker-compose.yml`.
 > Root folder `/storage/Music` (accessible) — **та же папка, что читает Navidrome**.
 > Download client Transmission (тест связи 200), naming: `{Artist Name}/{Album Title}/{track:00} - {Track Title}`.
 > Prowlarr: Application `Lidarr` id=3 `fullSync`, `syncCategories=[3000…3060]`.
+> 🔴 **`health: []` ≠ «работает»** — проверять поиск. Факт: `GET /api/v1/artist` → **`[]`,
+> 0 артистов**; `artist/lookup?term=radiohead` → **403**. Артиста добавить невозможно.
 > ⏳ **Приёмка НЕ закрыта:** `api.lidarr.audio` (метаданные SkyHook) → **403 Cloudflare**
 > прямым запросом, через `vless-proxy` → **200**. Заготовка `/tmp/add_proxy_env.py` (HTTP_PROXY/
 > HTTPS_PROXY + NO_PROXY) — НЕ применена. ⚠️ FlareSolverr тут НЕ помогает: Lidarr ходит
-> в SkyHook сам, не через FS → нужен именно `HTTP(S)_PROXY`-подход.
+> в SkyHook сам, не через FS → нужен именно `HTTP(S)_PROXY`-подход. Домен при этом
+> **резолвится** (это не DNS-блок) — план фикса в [[personal/tech/flaresolverr-taiga]] §Открытые пункты.
 > 🔴 **Индексеры для музыки (проверено 2026-09-28):** аудио отдают только **RuTracker(1)**,
 > **NoNaMe(4)**, **Kinozal(5,6)**. **RuTor и Byrutor — `music-search available="no"`, музыки НЕТ.**
 > ✅ Все 4 аудио-индексера разблокированы 2026-09-28 (FlareSolverr) — [[personal/tech/flaresolverr-taiga]].
@@ -224,3 +224,18 @@ CPU 0.68%); канал прокси нормальный (kinozal через soc
  Заготовка `/tmp/add_proxy_env.py` (HTTP_PROXY/HTTPS_PROXY) — **не применена**;
  Lidarr ходит в SkyHook сам, НЕ через FS. Разбирать отдельно —
  [[family/plans/lidarr-taiga-deploy]].
+  🔴 **Проверено 2026-09-28:** домен `api.lidarr.audio` **резолвится** из контейнера
+  (`2606:4700:3031::ac43:df35`) — значит это **чисто Cloudflare, НЕ DNS** (в отличие от
+  трекеров, где был NXDOMAIN). Следствие важное: **`PROXY_URL`/FlareSolverr здесь бесполезны** —
+  FS обслуживает только Prowlarr, а SkyHook зовёт сам Lidarr. Нужен отдельный прокси
+  на уровне процесса Lidarr (env `HTTP_PROXY`/`HTTPS_PROXY` в `arr/docker-compose.yml` +
+  `NO_PROXY` для внутренних имён, иначе сломается связь с Transmission/Prowlarr).
+  Состояние: в библиотеке **0 артистов** (`GET /api/v1/artist` → `[]`), приёмка не закрыта.
+
+  **План фикса (2 шага, ~5 мин, ждёт «go» Alex):**
+  1. `HTTP_PROXY=socks5h://vless-proxy:1080`, `HTTPS_PROXY=socks5h://vless-proxy:1080`,
+     `NO_PROXY=localhost,127.0.0.1,lidarr,prowlarr,radarr,sonarr,transmission,jellyfin,navidrome,caddy`
+     → бэкап compose → правка **локально** → `scp` → `docker compose up -d lidarr` (конфиг в
+     `/config` не трогается).
+  2. Проверка: `GET /api/v1/artist/lookup?term=radiohead` → должен вернуть массив, не 403.
+  - Fallback, если .NET Lidarr не поймёт `socks5h`: `socks5://` либо HTTP-прокси `vless-proxy:1081`.