[2026-09-04] eagle: family/how-to/arr-stack-kraken.md family/how-to/hermes-kraken-api.md family/how-to/kraken-access.md family/how-to/kraken-network.md family/how-to/kraken-portainer-access.md family/how-to/openmediavault-rpi5.md family/how-to/router-bishkek-asus.md family/projects/watchlist-automation.md personal/tech/cloudflare-tunnel-ssh-published-route.md

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

@@ -1,7 +1,7 @@
 ---
 title: Arr Stack — Kraken
 created: '2026-05-23'
-updated: '2026-05-27'
+updated: '2026-09-04'
 type: tech
 namespace: family
 tags: [arr, radarr, sonarr, prowlarr, transmission, jellyfin, infra, kraken]
@@ -128,6 +128,52 @@ All services accessible at `kraken:<port>`:
 
 - **17 фильмов в Radarr `hasFile=False`** — ждут подходящего релиза в Prowlarr. Scream (1996) в процессе загрузки.
 - **Prowlarr** — если долго не находит релизы, проверить статус индексеров (`/api/v1/health`).
+- **🔴 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 → причина в клиенте webOS, НЕ в сети/диске.** Вживую при воспроизведении `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 ТВ чист (0 CRC / 0 retries за стрим, -53 dBm), все линки с запасом ×10+. **Значит низкоуровневая причина — программный декодер/буфер «Jellyfin for WebOS 1.2.2» при Direct Play 4K HEVC 10-bit HDR, не инфраструктура.** Вывод для стратегии качества: даже лёгкий 4K Direct Play не гарантирует плавности на этом ТВ-клиенте — вопрос не столько в remux, сколько в клиенте. Кандидаты фикса: настройки буфера/декодера клиента, DirectStream (ремукс), тянуть через HTPC/Kodi на HDMI, либо транскод аудио. **Решение НЕ принято — продолжить в след. сессии.**
+
+## Radarr Quality Profiles на Kraken (проверено 2026-09-04)
+
+Via `http://kraken:7878/radarr/api/v3/qualityprofile` (X-Api-Key из config.xml; **UrlBase=`/radarr`**). Radarr v6.1.1.10360, Linuxserver image, net `docker_default`.
+
+| id | Профиль | Разрешённые качества | Cutoff |
+|----|---------|----------------------|--------|
+| 1 | **Any** | весь диапазон CAM..BR-DISK, вкл. все 2160p | Remux-1080p |
+| 2 | SD | до Bluray-576p | — |
+| 3 | HD-720p | до Bluray-720p | — |
+| 4 | HD-1080p | HDTV/Bluray/Remux-1080p | Bluray-1080p |
+| 5 | **Ultra-HD** | HDTV/Bluray/**Remux-2160p** (BR-DISK не allowed) | **Remux-2160p** |
+| 6 | HD-720p/1080p | 1080p и ниже | — |
+
+- **Корень «почему новые качаются в любой жир»:** `watchlist-sync` (который добавляет фильмы/сериалы из watchlist в Radarr/Sonarr) жёстко прописывает `"qualityProfileId": 1` (= профиль `Any`) в `arr.py`:
+  - Реальный путь репо: `/srv/dev-disk-by-uuid-6194539b-03e0-4f33-986b-4da09834e82f/watchlist-sync` (НЕ `~/Developer/watchlist-sync`, хотя симлинк `~/Developer/watchlist-sync` → `.../49e8.../watchlist-sync` есть; 49e8 — симлинк на 6194).
+  - `watchlist_sync/arr.py` → `radarr_add()` (~стр 77) и `sonarr_add()` (~стр 112), обе `"qualityProfileId": 1`. Radarr POST `/api/v3/movie` c `addOptions.searchForMovie:true`; Sonarr POST `/api/v3/series`.
+- **Как изменить «качество для новых фильмов» глобально:** сменить зашитый `qualityProfileId` в `arr.py` на другой профиль (напр. id=5 Ultra-HD), ИЛИ создать профиль «2160p без Remux» и указать его. Это правка кода репо watchlist-sync на Кракене + профили в Radarr API. ⚠️ Алекс ещё НЕ утвердил направление (4K лёгкий vs 1080p, и нужно ли для сериалов). НЕ менять без явного ok.
+- ⚠️ **Решение по стратегии качества (пользователь прошлые строки уточнял) НЕ принято — продолжить в след. сессии.** Приоритет — разобраться, что делает webOS-клиент на Direct Play лёгкого 4K (см. «Известные проблемы»), т.к. если клиент виноват, смена профиля Radarr не решит подёргивание.
+
+### Реальный состав жирного remux (пример Unhinged, ffprobe 2026-09-04)
+
+Важно для понимания «что даёт remux» перед выбором профиля. Файл `Неистовый.2020.UHD.Blu-Ray.Remux.2160p.mkv` = **60.9GB, 1:31:05, контейнер 89.17 Мбит/с средний**.
+
+FFprobe потоки:
+| idx | тип | кодек | каналы | язык / роль |
+|----|-----|-------|--------|------|
+| 0 | video | **HEVC Main10, 3840×2160, 24fps** | — | HDR10 (BT.2020, PQ smpte2084) |
+| 1 | audio | AC3 | 5.1(side) 384k | rus «Dub, iTunes» |
+| 2 | audio | **DTS-HD MA** | 7.1 | rus «Д. Есарев» |
+| 3 | audio | **TrueHD** | 7.1 | eng |
+| 4 | audio | AC3 | 5.1 640k | eng |
+| 5 | audio | DTS | stereo 320k | eng Commentary (реж. Деррик Борте) |
+| 6-8 | sub | SRT/SPU | — | rus / eng full / eng SDH |
+
+Вывод: размер 60GB раздувает НЕ видео (HDR10 HEVC-часть типичная), а **множество звуковых дорожек (lossless DTS-HD MA + TrueHD) + аудиокомментарий**. «Что даёт remux» на бытовом ТВ: видео-выигрыш против аккуратного 4K-рипа почти незаметен с дивана; бонус реализуется только при lossless-прокачке звука (AVR/eARC). Если ТВ играет через собственные динамики/стерео или делает audio-transcode — плюс remux теряется, а вес/сеть/лаг остаются. Это аргумент за профиль «2160p без Remux» для бытового просмотра на webOS-TB.
+
+### Бенчмарк WEB-4K (замерено по библиотеке Kraken, 2026-09-04)
+
+«Поддерживаемое качество» для сравнения с жирным remux — это кодированные 2160p. Замер файлов с `WEB`+`2160` в имени в `/media`:
+- Полнометражки (2ч): `Project Hail Mary` 28.1GB, `The Drama` 19.2GB, `The Crow` 17.4GB, `They Will Kill You` 17.2GB, `Кот в сапогах` 19.9GB → **range 17–28GB, медиана ~19GB**.
+- 45-50 мин эпизоды док-сериалов (`prehistoric.planet` s01): ~7.2–7.7GB каждый.
+- Статсводка по всем 10 файлам: min 7.2 / median 12.5 / mean 13.9 / max 28.1 GB. Средний битрейт ~20–40 Мбит/с.
+- **Практичный floor benchmark: «нормальная» копия 4K для этого ТВ ≈ 17–28GB/фильм** (в 2.5–3× меньше remux). ⚠️ Однако см. «Известные проблемы»: даже такой лёгкий 4K Direct Play у webOS-клиента может подёргиваться — дело в клиенте, а не в размере файла.
 
 ## Notes
 

family/how-to/hermes-kraken-api.md

@@ -1,7 +1,7 @@
 ---
 title: Hermes Kraken — OpenAI-Compatible API Server
 created: '2026-05-29'
-updated: '2026-05-29'
+updated: '2026-09-04'
 type: tech
 namespace: personal
 tags: [hermes, kraken, infra, agent, how-to]
@@ -24,7 +24,7 @@ assistant.
 
 ```
 Android (Aide)
-  └── HTTPS → hermes.kraken.qentra.top/v1/chat/completions
+  └── HTTPS → kraken.qentra.top/v1/chat/completions
                     ↓ Cloudflare Tunnel
               cloudflared (Kraken, host network)
                     ↓ localhost:8642
@@ -67,8 +67,7 @@ Tunnel name: `kraken`. Public hostname (CF Zero Trust dashboard):
 - **Type:** HTTP (not SSH)
 - **URL:** `localhost:8642`
 
-SSH to Kraken still works via VPS reverse tunnel (port 2223) — the CF
-hostname change does not affect SSH access.
+`kraken.qentra.top` — HTTP-маршрут на Hermes API (8642). SSH через Cloudflare Tunnel идёт **отдельным** hostname **`ssh-kraken.qentra.top` → `ssh://localhost:22`** (рабочий с 2026-09-04; вход `ssh kraken@ssh-kraken.qentra.top`, разовый `cloudflared access login ssh-kraken.qentra.top`, см. [[kraken-access]]). Альтернативный SSH-путь — VPS reverse tunnel `91.207.28.205:2223`. ⚠️ Двухуровневый `ssh.kraken.qentra.top` НЕ работает (нет edge-TLS на 2-уровневом subdomain) — подробности/питфол в [[kraken-access]].
 
 ## Aide Android Client Config
 

family/how-to/kraken-access.md

@@ -1,6 +1,6 @@
 # Kraken — Внешний доступ
 
-> Обновлено: 2026-09-01
+> Обновлено: 2026-09-04
 
 > Updated: 2026-09-01 23:00 — диск/докер кракена восстановились после перезагрузки.
 
@@ -40,8 +40,67 @@ EP=3  # endpoint ID на Кракене = 3, не 1!
 
 | Имя | Заметки |
 |-----|---------|
-| xray-reverse-bridge | развёрнут 2026-09-01 (единственный активный) |
-| flaresolverr / hermes-kraken / homeassistant / jellyfin / portainer / prowlarr / radarr / rclone / sonarr / transmission / cloudflared / watchtower | образы есть, контейнеры потеряны — пересоздать при необходимости |
+| xray-reverse-bridge | развёрнут 2026-09-01 |
+| cloudflared | ✅ UP (2026-09-04), remote-managed по TUNNEL_TOKEN — пересоздан после сбоя |
+| flaresolverr / hermes-kraken / homeassistant / jellyfin / portainer / prowlarr / radarr / rclone / sonarr / transmission / watchtower | образы есть, контейнеры потеряны — пересоздать при необходимости |
+
+## Cloudflared туннель — публичные маршруты (состояние на 2026-09-04)
+
+Туннель `kraken` в Zero Trust, remote-managed по `TUNNEL_TOKEN`, `network_mode: host`, образ `cloudflare/cloudflared:latest`. Актуальный ingress конфиг (виден в логах cloudflared на Kraken, `INF Updated to new configuration`):
+```
+{"ingress":[
+  {"hostname":"kraken.qentra.top",     "originRequest":{"httpHostHeader":"kraken.qentra.top"},"service":"http://localhost:8642"},  ← Hermes API
+  {"hostname":"ssh-kraken.qentra.top",  "service":"ssh://localhost:22"},                                                          ← SSH (published application route)
+  {"service":"http_status:404"}                                                                                                    ← default catch-all
+]}
+```
+
+⚠️ **Важно (путаница была!):** `kraken.qentra.top` — это **HTTP-маршрут на `localhost:8642` (Hermes API)**, НЕ SSH. Поэтому SSH к `kraken.qentra.top:22` и не шёл. Под SSH создан отдельный hostname **`ssh-kraken.qentra.top`**.
+
+### ✅ SSH-доступ работает через `ssh-kraken.qentra.top` (РАБОЧИЙ, 2026-09-04)
+
+**Вход (проверено, работает):**
+```bash
+ssh kraken@ssh-kraken.qentra.top
+```
+
+`~/.ssh/config` блок:
+```
+Host ssh-kraken.qentra.top
+  HostName ssh-kraken.qentra.top
+  User kraken
+  ProxyCommand cloudflared access ssh --hostname %h
+```
+
+Первый раз — авторизация cloudflared в Access-приложение:
+```bash
+cloudflared access login ssh-kraken.qentra.top
+```
+
+Маршрут на Kraken (UP, контейнер) подхвачен ingress `ssh-kraken.qentra.top → ssh://localhost:22`; sshd на Kraken — `0.0.0.0:22`. DNS проксировано CF (104.21.x / 172.67.x).
+
+### ⚠️ Питфол: почему `ssh.kraken.qentra.top` (двухуровневый) НЕ сработал
+
+Изначально под SSH добавлялся hostname `ssh.kraken.qentra.top` (`ssh.kraken` + `qentra.top`) → `ssh://localhost:22`, + Access Application (type SSH) + Service Token. Вход НЕ заработал. Решающий факт — на edge Cloudflare у этого hostname **НЕТ SSL/TLS-терминации**, в отличие от одиночных subdomain:
+```
+openssl s_client -connect ssh.kraken.qentra.top:443 → SSL alert 40 (handshake failure), no peer certificate
+curl https://ssh.kraken.qentra.top → ssl=1 handshake failure
+```
+Любой `cloudflared access login/ssh` и Service Token к чистому двухуровневому SSH-hostname не помогают — клиент не доходит даже до авторизации из-за отсутствия edge-TLS.
+
+**Решение, которое сработало:** использовать **одиночный subdomain через дефис** — `ssh-kraken.qentra.top` (покрывается Universal SSL `*.qentra.top`). На нём размещены тот же `published application route` SSH → `ssh://localhost:22` + Access Application. Вошло сразу.
+
+> Почему так: Universal SSL зоны покрывает `*.qentra.top` (1 уровень) и `qentra.top`, но НЕ `*.kraken.qentra.top` (2 уровня). Для 2-уровневого нужен Advanced Certificate — проще взять одиночный subdomain.
+
+### Диагноз IPv4/IPv6 «жив, но шумит» (актуально для обоих hostname)
+
+- В логах cloudflared — часть `Registered tunnel connection ... protocol=quic`, но постоянные `ERR ... write udp [::]->198.41.x.x:7844: sendmsg: network is unreachable`.
+- **Причина: на Kraken НЕТ глобального IPv6** (только `::1` и link-local `fe80::`; роутер `192.168.1.1` IPv6 не выдаёт → `ping6 2606:4700::1111` = `Network is unreachable`). cloudflared пробует QUIC и по IPv6 → каналы падают; туннель выживает по IPv4-QUIC.
+- **Возможный фикс:** заставить cloudflared QUIC только по IPv4, чтобы убрать IPv6-шум.
+
+### SSH через VPS reverse (независимо от cloudflared)
+
+Остаётся рабочим внешним путём: reverse SSH туннель через VPS `91.207.28.205:2223` (см. ниже), НЕ cloudflared.
 
 ## Связанные заметки
 
@@ -49,4 +108,5 @@ EP=3  # endpoint ID на Кракене = 3, не 1!
 - [[wireguard-vpn]] — полное описание WG (⚠️ VPS-звено мёртво на 2026-09-01)
 - [[kraken-portainer-access]]
 - [[openmediavault-rpi5]]
+- [[tech/cloudflare-tunnel-ssh-published-route]] — генерализуемое руководство: SSH через Cloudflare Tunnel (1-уровневый subdomain + Universal SSL), питфолы
 

family/how-to/kraken-network.md

@@ -1,12 +1,17 @@
 ---
 title: Kraken Network & Infra
 created: '2026-05-23'
-updated: '2026-09-02'
+updated: '2026-09-04'
 type: tech
 namespace: personal
-tags: [infra, kraken, ssh, wireguard, network]
+tags:
+  - infra
+  - kraken
+  - ssh
+  - wireguard
+  - network
 related:
-  - "[[tech/arr-stack-kraken]]"
+  - '[[tech/arr-stack-kraken]]'
 ---
 
 # Kraken Network & Infra
@@ -29,10 +34,37 @@ SSH alias `kraken` resolves via `~/.ssh/config`.
 | **wlan0** (WiFi) | `192.168.1.15/24` (DHCP) | `2c:cf:67:64:03:f4` | fallback — metric 600 |
 
 - Ethernet link на boot: **1000 Mbit/s full duplex** (как и ожидалось для Gigabit-порта RPi5), carrier up.
-- ⚠️ **2026-09-02 ~16:30: eth0 ПЕРЕСОГЛАСОВАЛСЯ ВНИЗ до 100 Mbit/s full** (dmesg: `Link is Down → Link is Up - 100Mbps/Full`), с тех пор стабильно висит на 100M (на момент ~19:00 всё ещё 100). Счётчики eth0 чистые (rx_errors=1 суммарно, свежих CRC нет) — не электрический шум, а downshift линка (обычно кабель/коннектор/порт роутера). **Симптом:** 4K UHD Blu-ray Remux (~99 Mbit/s) при Direct Play дёргается — 99M видео по 100M линку = ~100% занятие канала без запаса. Ожидается boot-link 1G (перепроверить / возможно требует переподключить патч).
+- ⚠️ **2026-09-02 ~16:30: eth0 ПЕРЕСОГЛАСОВАЛСЯ ВНИЗ до 100 Mbit/s full** (dmesg: `Link is Down → Link is Up - 100Mbps/Full`) и стабильно висел на 100M (проверялось 2026-09-04 по SSH: speed=100). Счётчики eth0 чистые (rx_errors=1 суммарно, свежих CRC нет) — не электрический шум, а downshift линка (кабель/коннектор/порт роутера). **Симптом:** 4K UHD Blu-ray Remux (~99 Mbit/s) при Direct Play дёргался — 99M видео по 100M линку ≈ 100% занятие канала без запаса.
+- ✅ **РЕШЕНО 2026-09-04: замена патч-корда вернула eth0 на 1000 Mbit/s full duplex** (проверено по SSH: speed=1000, duplex=full, carrier=up). Причина — неисправный/некачественный кабель, а не порт роутера или настройки. Carrier_changes = 5 на момент проверки. 4K Remux больше не должен дёргаться.
 - Router/gateway: `192.168.1.1` (`f0:79:59:77:9b:70`). eth0 MAC соответствует static lease в доке [[family/how-to/openmediavault-rpi5|openmediavault-rpi5]].
 - ⚠️ Ранее эта заметка утверждала «wlan0 = .15 primary» — устарело (см. таблицу выше).
 
+## Хранилище Kraken — USB (проверено 2026-09-04)
+
+Единственный диск `sda` (Toshiba **MQ01UBB200**, 1.8TB) подключён **напрямую в порт USB3/SS RPi5, НЕ через хаб** — Sysfs путь `/.../xhci-hcd.0/usb2/2-1`, speed **5000 Mbps**. lsusb -t: Dev 2 на Bus 02 (5000M). Линк USB3 настоящий (не USB2).
+
+**Скорость чтения диска ~95 МБ/с** (dd direct + buffered, по remux-файлу): это не USB-узкое место, а **физический предел 5400rpm 2.5" ноутбучного HDD** (максимум ~100–110 МБ/с на внешних дорожках). Для сравнения потолок USB2 ≈ 35–40 МБ/с. USB3.0 линк подтверждён (5000M). Вывод: для скорости >200 МБ/с нужен SSD/7200rpm, текущий механик упрется в ~95–110 МБ/с.
+
+Хабы (Super Top `1-1.2`, Huasheng «USB2.0 HUB» `1-1`) висят на **Bus 01 (USB2, 480M)** и **пустые** — к ним ничто не подключено.
+
+Монтирование: `/dev/sda1` (ext4, UUID `6194539b-03e0-4f33-986b-4da09834e82f`) → `/srv/dev-disk-by-uuid-6194539b-...`; старый путь `49e8f586...` — **symlink** на него.
+
+## Клиент — LG webOS TV (192.168.1.75 WiFi / 192.168.1.70 Ethernet) (проверено 2026-09-04)
+
+По SSH `root@192.168.1.75` или `root@192.168.1.70` (`~/.ssh/config` .75, id_rsa; выводит post-quantum warning — ок). Host LGwebOSTV, ядро 4.4.84 armv7 (webOS). ТВ имеет **два MAC**: WiFi `54:77:87:ce:fb:b3`, Ethernet `ac:5a:f0:25:11:c6` (этот = static lease в роутере `.75`).
+
+**Состояние на конец сессии 2026-09-04:** ТВ переведён на **провод** (пользователь воткнул патч-корд в роутер) → WiFi `wlan0 DOWN`, `eth0 UP`. После этого IP сменился: проводной интерфейс получил **`192.168.1.70`** (старый `.75` больше не отвечает, ping 100% loss). ⚠️ **eth0 ТВ линк = 100 Mbit/s full duplex** (carrier up, speed=100) — то есть **тот же downshift на 100M**, какой был у Kraken (см. ниже). Провод 100M **медленнее**, чем WiFi (867 PHY ≈ 400+ реальных Мбит/с) → переключение на полуживой кабель — регресс., если не поменять патч-корд ТВ↔роутер на рабочий гигабитный.
+
+**Сводка по линкам ТВ (до переключения на провод, WiFi .75):**
+- Wi-Fi клиент был: SSID **ASUS5**, BSSID `f0:79:59:77:9b:74`, **канал 153 / 5765MHz / width 80MHz (5 GHz, 802.11ac)**, **signal -53 dBm** (отличный), **TX link rate 867.0 MBit/s PHY** (2-поток 80MHz AC — потолок карты), txpower 15 dBm.
+- Реальный TCP-пропуск ≈ 50–60% PHY ≈ **400–500 Мбит/с** при таком сигнале — это в разы больше 99 Мбит/с remux'а, так что **WiFi ТВ не узкое место**. Торможение 4K сохранялось и на WiFi, и позже подтверждено на сотне-проводе.
+
+**Forensics торможения (проведено вживую при воспроизведении Project Hail Mary, Direct Play):**
+- Транскода НЕТ: 0 ffmpeg-процессов, `/config/transcodes` пуст, CPU Kraken load ~0.1 — сервер простаивает.
+- Сервер отдаёт всего ~21 Мбит/с (eth0 tx) при файле ~27 Мбит/с — сеть и диск с запасом ×10+.
+- Wi-Fi ТВ-интерфейс за время стрима: **rx_crc_errors=0, tx_retries delta=0**, signal постоянно -53 dBm — радио чистое, не деградирует.
+- **Вывод: все сетевые/дисковые/радио-счётчики чисты, линки имеют запас, а Direct Play НИЗКОбитрейтного (24-27 Мбит/с) 4K всё равно подёргивается** → причина в **программном декодере/буфере клиента «Jellyfin for WebOS 1.2.2»**, а не в инфраструктуре. См. [[arr-stack-kraken]] «Известные проблемы». Плюс если смотреть через провод — линк ТВ сейчас 100M (тоже слабое место для remux).
+
 ## WireGuard Topology
 
 Split-tunnel: Eagle ↔ VPS ↔ Kraken. Full details: [[tech/wireguard-vpn]].

family/how-to/kraken-portainer-access.md

@@ -61,7 +61,7 @@ curl -s -X DELETE -H "X-API-Key: $KEY" \
 
 ## Cloudflared — деплой (выполняет Кракен)
 
-CF Tunnel уже создан Alex'ом (`kraken` в Zero Trust), hostname настроен: `kraken.qentra.top → SSH → localhost:22`.
+CF Tunnel уже создан Alex'ом (`kraken` в Zero Trust), ingress настроен. ⚠️ Актуальные маршруты (2026-09-04): **`kraken.qentra.top` → HTTP `localhost:8642`** (Hermes API, НЕ SSH) и отдельный **`ssh-kraken.qentra.top` → `ssh://localhost:22`** (published SSH application route; вход `ssh kraken@ssh-kraken.qentra.top`, работает с 2026-09-04). Полная картина и статус — [[kraken-access]].
 
 **CF Tunnel Token:**
 ```

family/how-to/openmediavault-rpi5.md

@@ -5,7 +5,7 @@ tags:
   - openmediavault
   - how-to
 created: '2026-05-11'
-updated: '2026-07-03'
+updated: '2026-09-04'
 status: hermes-pending
 ip: 192.168.1.15
 ---
@@ -160,7 +160,7 @@ sudo update-initramfs -u -k all < /dev/null
 ## Шаг 6 — USB HDD
 
 1. Подключить HDD к синему (USB 3.0) порту Pi
-2. Проверить скорость: `sudo apt install hdparm && sudo hdparm -t --direct /dev/sda` → должно быть ~200-250 MB/s
+2. Проверить скорость: `sudo apt install hdparm && sudo hdparm -t --direct /dev/sda` → ориентир ~200-250 MB/s **только для быстрых дисков** (SSD / 7200rpm). См. ⚠️ ниже про 5400rpm.
 3. Разметить: `sudo parted -s /dev/sda mklabel gpt mkpart primary 0% 100%`
 4. Форматировать (агент не может — только вручную или через скрипт):
    ```bash
@@ -171,6 +171,22 @@ sudo update-initramfs -u -k all < /dev/null
 
 > ⚠️ Не монтировать вручную через fstab — OMV должен управлять монтированием сам
 
+### ⚠️ Скорость диска Toshiba 1.8TB (проверено 2026-09-04)
+
+**Не путать медленный HDD с USB2-линком.** Реальный замер чтения на Kraken (по SSH, смонтированная ФС, `dd` из remux-файла, 1GB × прогоны):
+- direct (обход page cache): **95.3 / 95.7 MB/s**
+- buffered: 92.7 MB/s
+- **Итог: ~95 MB/s стабильно.**
+
+Диагностика «а диск не на USB2 ли?» (2026-09-04) завершилась **отрицательно**:
+- USB2-потолок ≈ **35-40 MB/s** (480 Мбит/с минус накладные). 95 MB/s в 2.5× выше → линк **точно USB3**.
+- sysfs топология sda: `/…/xhci-hcd.0/usb2/2-1 → sda`, `speed=5000 Mbps`, подключён **напрямую** в синий (USB3) порт Pi, **не через хаб**.
+- Оба хаба на Kraken (Huasheng USB2.0 HUB + Super Top) висят на Bus 01 (**USB 2.0, 480M**) и на момент проверки **пустые** (к ним ничего не подключено) — к диску отношения не имеют.
+- 95 MB/s — это **физический предел** Toshiba **MQ01UBB200: 5400 rpm 2.5"** HDD (~100-110 MB/s внешние дорожки). Упирается в механику, а не в USB.
+- `hdparm` и прямой доступ к `/dev/sda` под `kraken` недоступны (sudo требует пароль, hdparm не установлен, user не в группе disk) — тест чтения шёл через смонтированную ФС.
+
+Для скорости >200 MB/s нужен SSD или 7200rpm; текущий 5400rpm не быстрее. Тест записи на боевом диске без явного разрешения не проводился.
+
 ### CLI-альтернатива: регистрация диска в OMV через config.xml
 
 Если Web UI недоступен, можно зарегистрировать диск через прямой редактор config.xml и deploy:

family/how-to/router-bishkek-asus.md

@@ -48,6 +48,8 @@ address=/tv/192.168.1.75
 |-----|----|-----|------------|
 | htpc | 192.168.1.86 | — | Bazzite, статический IP, RX 570 |
 | tv / LGwebOSTV | 192.168.1.75 | ac:5a:f0:25:11:c6 | LG TV |
+
+> ⚠️ **2026-09-04:** LG TV подключён по **проводу** (вместо WiFi). Проводная часть использует Ethernet-MAC `ac:5a:f0:25:11:c6` и на конец сессии получал **`192.168.1.70`** (DHCP), а статический lease `.75` перестал отвечать по этому MAC (на .75 когда-то был WiFi-MAC `54:77:87:ce:fb:b3`). Если `.75` вдруг «пропал» из сети — телевизор просто переключился на провод и его теперь надо искать по .70 или заново в DHCP-lease. Линк eth0 ТВ на 2026-09-04 = **100 Mbit/s** (downshift, кабель не тянет 1G).
 | Mac | 192.168.1.57 | 5a:fe:e7:bb:b3:d1 | |
 | MacBookPro | 192.168.1.43 | 76:88:0d:b9:6a:cd | |
 | zhimi-airpurifier (1) | 192.168.1.58 | b4:04:29:38:6a:63 | Xiaomi очиститель воздуха |

family/projects/watchlist-automation.md

@@ -1,6 +1,6 @@
 ---
 created: '2026-05-20'
-updated: '2026-05-27'
+updated: '2026-09-04'
 status: active
 tags:
   - kraken
@@ -77,7 +77,7 @@ Jellyfin (8096) → rescan → виден контент
 
 **Пути на Кракене (HDD UUID 49e8f586-3839-4c5d-a1e1-58bfc3579ade):**
 - `/home/kraken/obsidian` → symlink на `/srv/dev-disk-by-uuid-.../obsidian`
-- watchlist-sync: `/srv/dev-disk-by-uuid-.../Developer/watchlist-sync`
+- `~/Developer/watchlist-sync` → symlink. **Реальный корень репо** (проверено 2026-09-04): `/srv/dev-disk-by-uuid-6194539b-03e0-4f33-986b-4da09834e82f/watchlist-sync` — находится **в корне диска, НЕ под `Developer/`** (в доке ранее путь был ошибочный). Внутри: `watchlist_sync/` (cli.py, arr.py, sync_down.py, sync_up.py, resolver.py, parser.py, discover.py, jellyfin.py), `.venv` (py3.11+httpx+click), `.resolve_cache.json`, pyproject.toml.
 
 ## Discover — Фильтрация
 
@@ -136,8 +136,17 @@ Jellyfin library mapping: Movies → `movies`, Cartoons → `mixed` (movies + ep
 ### KP API Endpoint
 `api.kinopoisk.dev` редиректит на `api.poiskkino.dev/v1.4/movie`. Использовать destination redirect напрямую.
 
-## Open Tasks (2026-05-20)
+### 🔴 Жёстко зашитый `qualityProfileId: 1` в arr.py (корень жирных remux)
+Найдено 2026-09-04. В `watchlist_sync/arr.py` **`qualityProfileId: 1` захардкожен** и для Radarr, и для Sonarr:
+```python
+# radarr_add  (~стр. 77) / sonarr_add (~стр. 112)
+"qualityProfileId": 1,
+```
+Профиль 1 (Radarr) = **'Any'** — разрешает ВСЁ вплоть до Remux-2160p и BR-DISK. Поэтому **каждый новый фильм/сериал, добавляемый watchlist-sync, попадает в «Any»** и Radarr скачивает самый жирный доступный релиз (60GB remux'ы). Готового профиля «2160p, но без Remux» на Kraken нет (нужно создавать). Решение по стратегии — открыто (см. ниже). Чтобы новые шли в поддерживаемое качество: либо создать профиль «2160p без Remux/BR-DISK» и поменять `qualityProfileId` в `arr.py` (Radarr+Sonarr), либо сузить сам профиль 1, либо зашить `4` (HD-1080p).
 
+## Open Tasks
+
+- 🔴 **[2026-09-04] Решить стратегию качества загрузки новых фильмов** (см. профили в [[arr-stack-kraken]]). Корень — захардкоженный `qualityProfileId: 1` (`Any`) в `watchlist_sync/arr.py`. Пока НЕ менялось (НИЧЕГО не правилось, ждём решение Alex). Вопрос юзеру: сохранить 4K (→ создать профиль «2160p без Remux/BR-DISK» и сменить id в arr.py) или опустить до 1080p (id 4); и менять ли и для Sonarr (сериалы) тоже.
 - 🟡 Передавать Transmission locations через router script при каждом импорте (сейчас вручную)
 - 🔴 rsync невыполненных фильмов с HTPC на Кракен (`Фильмы не перенесенные с htpc на кракен.md`)
 - 🟡 Watchlist sync-up: добавить перенесённые фильмы в нужные разделы

personal/tech/cloudflare-tunnel-ssh-published-route.md

@@ -0,0 +1,62 @@
+# Cloudflare Tunnel: SSH через Published Application Route
+
+> Обновлено: 2026-09-04 (итог отладки захода на Kraken)
+> Рабочий case с полными командами: `family/how-to/kraken-access.md`
+
+Генерализуемые выводы про то, как сделать **SSH через Cloudflare Tunnel** (`published application route`), чтобы вход работал `ssh user@host — через cloudflared на клиенте`.
+
+## Ключевое правило: hostname должен быть 1-уровневым subdomain (БЕЗ точки до домена)
+
+**Симптом:** двухуровневый subdomain вида `ssh.kraken.qentra.top` (`ssh.kraken` + точка + `qentra.top`) НЕ работает как SSH/TLS через Cloudflare.
+
+Проверка (решающий факт) — на edge НЕТ TLS-терминации для 2-уровневого hostname:
+```bash
+openssl s_client -connect ssh.kraken.qentra.top:443 -servername ssh.kraken.qentra.top
+# → SSL alert number 40 (handshake failure), "no peer certificate available"
+curl -s https://ssh.kraken.qentra.top   # ssl=1 handshake failure
+```
+В отличие от 1-уровневого hostname (`kraken.qentra.top`), который отвечает:
+```bash
+openssl s_client -connect kraken.qentra.top:443 ...  # CN=qentra.top, verify ok
+```
+
+**Почему:** Universal SSL Cloudflare-зоны покрывает только `*.domain` (1 уровень wildcard) и сам `domain`. Он НЕ покрывает `*.sub.domain` (2 уровень). Для 2-уровневых нужен Advanced Certificate (SAN на полный двухуровневый wildcard) — обычно проще взять **одиночный subdomain**.
+
+> ⚠️ ПИТФОЛ: Cloudflare-точка в hostname (`a.b.domain`) = 2 уровня по SSL, точка НЕ безобидна. Рабочая замена — один уровень с дефисом: `ssh-kraken.qentra.top` (покрывается `*.qentra.top`).
+
+## Правильная схема SSH через Tunnel (по доке Cloudflare)
+
+**На сервере/туннеле (Zero Trust):**
+- Tunnels → туннель → **Routes → Add route → Published application**
+- Service: **SSH** → `localhost:22` (или `<ip>:22`)
+- hostname использовать **одиночный** subdomain (`ssh-kraken.qentra.top`, не `ssh.kraken...`)
+
+**В Zero Trust Access:**
+- Access → **Applications → Add self-hosted** (тип SSH, browser rendering off) на тот же hostname, с политикой (Allow / Service Token).
+- SSH-route без Access Application не даёт клиенту пройти даже до авторизации: `cloudflared access login <ssh-host>` → `failed to get app info: ... tls: handshake failure`.
+
+**На клиенте** (cloudflared установлен):
+`~/.ssh/config`:
+```
+Host ssh-kraken.qentra.top
+  HostName ssh-kraken.qentra.top
+  User kraken
+  ProxyCommand cloudflared access ssh --hostname %h
+```
+Первый раз — авторизация: `cloudflared access login ssh-kraken.qentra.top` (откроет SSO/браузер). Дальше `ssh kraken@ssh-kraken.qentra.top`.
+
+## Client-side подводные камни
+
+- `cloudflared access login <ssh-hostname>` нельзя проверить по `HEAD https://<ssh-host>` — SSH-kind hostname НЕ терминирует HTTP/TLS, поэтому `failed to get app info: tls: handshake failure` — ожидаемо, если на маршруте нет Access App.
+- `~/.cloudflared/*-org-token` = `not-available` означает, что cloudflared НЕ авторизован в Access org — разовый `cloudflared access login` обязателен.
+- Сам ssh к hostname:22 напрямую (без cloudflared в ProxyCommand) к проксированному DNS не работает — hostname за Cloudflare-Anycast, в туннель трафик попадает только через cloudflared-клиент.
+- `network_mode: host` (container cloudflared) — сервис напрямую видит локальные порты (sshd на `0.0.0.0:22`).
+
+## Общий паттерн «жив, но шумит» cloudflared на origin без IPv6
+
+Если у origin нет глобального IPv6 (роутер не выдаёт), cloudflared пытается поднять QUIC и по IPv6 → в логах постоянные `ERR ... write udp [::]->198.41.x.x:7844: sendmsg: network is unreachable`, соединения падают/retry. Туннель продолжает работать по IPv4-QUIC. Возможный фикс — заставить cloudflared использовать только IPv4.
+
+## Связанные заметки
+
+- `family/how-to/kraken-access.md` — рабочий живой пример (hostname `ssh-kraken.qentra.top`, ingress, команды)
+- `family/how-to/kraken-portainer-access.md` — деплой cloudflared-контейнера и логи туннеля