[2026-09-24] eagle: family/how-to/arr-stack-kraken.md personal/tech/lampac-torrserver.md personal/tech/prowlarr-flaresolverr-cloudflare.md

family/how-to/arr-stack-kraken.md

@@ -369,6 +369,20 @@ Alex: **ожидаемое поведение**; если фильм нужен
 - **17 фильмов в Radarr `hasFile=False`** — ждут подходящего релиза в Prowlarr. Scream (1996) в процессе загрузки.
 - **Prowlarr** — если долго не находит релизы, проверить статус индексеров (`/api/v1/health`). ⚠️ health врёт, реальную причину блокировки смотреть в `config/logs/prowlarr.debug.txt` — см. секцию «🔴 Индексера Prowlarr — починка Cloudflare (2026-09-20)» ниже.
 - ✅ **2026-09-20: все индексера Prowlarr починены (6/6), Radarr 4/4 и Sonarr 5/5 зелёные.** Причины были: сеть (`docker_default` вместо `media_net`), непривязанный tag у FlareSolverr-прокси, и блокировки в `IndexerStatus`. Детали и команды — в секции ниже.
+- 🔴 **2026-09-24: РЕЦИДИВ — «6/6» больше не действует.** RuTracker (1), Kinozal (5), Kinozal (M) (6)
+  снова заблокированы, `EscalationLevel=9`, `disabledTill=2026-09-25T10:17Z` — то есть **сутки**.
+  Первопричина не Cloudflare и не теги (они на месте), а **FlareSolverr в crash-loop**:
+  Chrome не поднимается под chromedriver (`session not created: cannot connect to chrome at
+  127.0.0.1:PORT`), HTTP `:8191` не отвечает. Симптом в UI: `error IndexerProxyStatusCheck:
+  All indexer proxies are unavailable due to failures`. Диагноз и незавершённый фикс
+  (`shm_size: 1gb` + снятие `IndexerStatus`): [[personal/tech/prowlarr-flaresolverr-cloudflare]]
+  §«2026-09-24». ⚠️ Ни `GET /api/v1/health`, ни `/api/v1/indexerstatus` пустотой не отделались —
+  на этот раз они **показали** блокировки; но авторитет всё равно за `prowlarr.debug.txt`
+  и таблицей `IndexerStatus`.
+- 🔴 **2026-09-24: swap на Кра́кене может быть МЁРТВ.** `/proc/swaps` пуст при живом
+  `/var/swap` (512 MB), `dphys-swapfile` не поднимает его автоматически, строки в `/etc/fstab`
+  нет. Лечение: `sudo swapon /var/swap` (⚠️ `swapoff -a && swapon -a` даёт `SwapFree: 0 kB`).
+  Без swap Chrome-контейнеры падают при пике старта. Проверка: `cat /proc/swaps`.
 - **🔴 2026-09-04: 4K UHD Remux при Direct Play подтормаживает на ТВ (webOS).** Симптом у `Неистовый (Unhinged 2020)` — 60.9GB `...Remux.2160p.mkv` avg ~99 Мбит/с. После фикса eth0 Kraken → 1G (был 100M, см. [[kraken-network]]) торможение **сохранилось**. Подтверждено по логу Jellyfin `log_20260904.log`: сессия 10:18→10:28 «Jellyfin for WebOS 1.2.2», Stop at 400916ms (~6:40), **ни одной строки transcode → это Direct Play**, не CPU-рендер субтитров.
 - **🔴🔴 2026-09-04 (вживую): тормозит Direct Play даже лёгкого 4K → пока шло по Wi-Fi, причина не сервер/диск.** В живом воспроизведении по Wi-Fi `Project Hail Mary (2026)` (`...2160p.iT.WEB-DL...mkv`, HEVC Main10 4K HDR10+, avg ~24.5-25.7 Мбит/с, 30.2GB, Direct Play) подёргивание было, при этом: транскода нет (0 ffmpeg, CPU Kraken load 0.1), сервер отдаёт всего ~21 Мбит/с, Wi-Fi ТВ «чист» по MAC-счётчикам (0 CRC/0 retries, -53 dBm), линки с запасом ×10+. 
 - ✅ **2026-09-04 РАЗРЕШЕНИЕ (проверено пользователем вживую):** после двух правок — (1) eth0 Kraken возвращён на **1G** (замена патч-корда) и (2) **ТВ переведён на проводной Ethernet** (100M downshift-линк) — и `Unhinged` (remux, ~89 Мбит/с), и `Project Hail Mary` (лёгкий 4K) **идут без тормозов**. Вывод: причиной были НЕ пропускная способность и НЕ декодер-клиента, а **нестабильный Wi-Fi-линк последней мили ТВ** (даже при чистых MAC-счётчиках — джиттер/переупорядочивание в зашумлённом эфире). Провод (даже 100M) стабильно отдаёт. Профиль `WEB-4K (no remux)` остаётся разумной страховкой, но не был обязательной причиной тормозов.