[2026-09-04] eagle: family/how-to/arr-stack-kraken.md family/how-to/jellyfin-transcode-rpi5.md family/how-to/router-bishkek-asus.md
This commit is contained in:
Alexey Martemyanov
@@ -99,6 +99,19 @@ Prowlarr → Radarr + Sonarr → Transmission → Jellyfin
|
||||
|
||||
(Full keys truncated — retrieve from each service's settings page.)
|
||||
|
||||
## Качество загрузки для НОВЫХ фильмов/сериалов (2026-09-04)
|
||||
|
||||
`watchlist-sync` (автодобавление из watchlist) использует профиль **`WEB-4K (no remux)`** (Radarr id **7**, Sonarr id **7**) вместо бывшего `Any`/id=1.
|
||||
|
||||
Что разрешает профиль (в порядке предпочтения, кодированные, БЕЗ remux/BR-DISK):
|
||||
- 2160p: HDTV / WEBDL / WEBRip / BluRay-2160p (кодир.)
|
||||
- fallback 1080p: HDTV / WEBDL / WEBRip / BluRay-1080p (кодир.)
|
||||
- fallback 720p: HDTV / WEBDL / WEBRip / BluRay-720p (кодир.)
|
||||
- **Запрещены:** Remux-1080p, Remux-2160p, BR-DISK, Raw-HD, SDTV/DVD/480/576.
|
||||
- cutoff = **Bluray-2160p (кодир.)**; upgrade выключен после скачивания.
|
||||
|
||||
**Где менять:** `watchlist-sync/watchlist_sync/arr.py` строки `qualityProfileId: 7` (radarr_add ~L77, sonarr_add ~L112). НЕ редактировать профили вручную иначе watchlist-sync надо обновить на новый id. Создать/править профиль «WEB-4K (no remux)» — Radarr/Sonarr → Settings → Quality Profiles.
|
||||
|
||||
## Ports (default Docker network)
|
||||
|
||||
All services accessible at `kraken:<port>`:
|
||||
@@ -129,7 +142,8 @@ 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, либо транскод аудио. **Решение НЕ принято — продолжить в след. сессии.**
|
||||
- **🔴🔴 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)` остаётся разумной страховкой, но не был обязательной причиной тормозов.
|
||||
|
||||
## Radarr Quality Profiles на Kraken (проверено 2026-09-04)
|
||||
|
||||
@@ -143,12 +157,16 @@ Via `http://kraken:7878/radarr/api/v3/qualityprofile` (X-Api-Key из config.xml
|
||||
| 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 и ниже | — |
|
||||
| **7** | **WEB-4K (no remux)** ✅ создан | кодир. HDTV/WEB/BluRay **2160p+1080p+720p** | **Bluray-2160p (кодир.)** |
|
||||
| 8 | (если появится из id авто-инкремента — перепроверить) | — | — |
|
||||
|
||||
Профиль id=7 разрешает код HDTV/WEBDL/WEBRip/BluRay в 2160/1080/720; **запрещает** Remux-1080p, Remux-2160p, BR-DISK, Raw-HD, SDTV/DVD/480/576. upgrade выключен. Sonarr: аналогичный профиль тоже id=7.
|
||||
|
||||
- **Корень «почему новые качаются в любой жир»:** `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 не решит подёргивание.
|
||||
- ✅ Решение принято и применено (см. выше): профиль `WEB-4K (no remux)` (Radarr/Sonarr id 7), fallback 1080→720, remux запрещён. Применено 2026-09-04.
|
||||
- ✅ **2026-09-04: стратегия качества РЕШЕНА И ПРИМЕНЕНА.** Новые фильмы/сериалы (через watchlist-sync) добавляются с профилем **`WEB-4K (no remux)`** (Radarr id 7, Sonarr id 7) — см. секцию «Качество загрузки для НОВЫХ». Fallback: если нет 2160p-кодированного — 1080p → 720p; remux не берётся никогда. Было принято так (fallback=1080, если нет — 720). Существующие файлы НЕ трогаются.
|
||||
|
||||
### Реальный состав жирного remux (пример Unhinged, ffprobe 2026-09-04)
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ tags:
|
||||
- subtitles
|
||||
- pitfalls
|
||||
created: '2026-05-18'
|
||||
updated: '2026-05-18'
|
||||
updated: '2026-09-04'
|
||||
---
|
||||
# Jellyfin Транскод на RPi5 — PGS/Subtitle Pitfalls
|
||||
|
||||
@@ -102,6 +102,19 @@ ls -la | cat -v # покажет NFD-escape символы как ^ escape seq
|
||||
python3 -c "import os; [print(repr(f)) for f in os.listdir('.')]"
|
||||
```
|
||||
|
||||
## 2026-09-04: 4K при чистых Direct Play подтормаживал по Wi-Fi — РЕШЕНО переводом ТВ на провод
|
||||
|
||||
**Наблюдение (важно для диагностики стриминговых тормозов):** сервер/диск могут быть «невиноваты», даже если клиент (Jellyfin for WebOS) дёргает картинку. Нужно проверить не только MAC-счётчики Wi-Fi (они могут быть «чистыми»), но и попробовать провод.
|
||||
|
||||
Симптомы на Kraken + LG webOS TV:
|
||||
- И тяжёлый `Неистовый (2020)` Remux-2160p (~89 Мбит/с), и лёгкий `Project Hail Mary (2026)` WEB-DL 4K (~25 Мбит/с, HEVC Main10 HDR10+) подтормаживали при чистых Direct Play **по Wi-Fi**.
|
||||
- При воспроизведении: `0 ffmpeg`-процессов, транскода нет, CPU Kraken `load 0.1`, сервер отдавал лишь `~21 Мбит/с`, Wi-Fi ТВ был «чист» по MAC-счётчикам (`0 CRC`, `0 retries`, `-53 dBm`) — т.е. локально сервер И клиентские линки выглядели здоровыми.
|
||||
- ⚠️ **Ловушка:** чистые MAC-счётчики не исключают джиттер/переупорядочивание пакетов на Wi-Fi в зашумлённом эфире — это и был реальный источник микрозазоров.
|
||||
|
||||
**Разрешение (2026-09-04):** (1) eth0 Kraken возвращён на 1G (замена патч-корда) + (2) **ТВ переведён на проводной Ethernet** (на тот момент линк 100M downshift). После этого и remux-4K (~89 Мбит/с), и лёгкий WEB-4K **идут без тормозов**. → Причина — нестабильный Wi-Fi последней мили ТВ, не пропускная способность и не декодер клиента.
|
||||
|
||||
Стратегия качества (профиль `WEB-4K (no remux)` в Radarr/Sonarr, benchmark размеров): см. `[[how-to/arr-stack-kraken]]` → «Качество загрузки».
|
||||
|
||||
## Связанные страницы
|
||||
|
||||
- [[concepts/kraken-media-stack]] — полный медиастек: *arr + Jellyfin + media-pipeline
|
||||
|
||||
@@ -49,7 +49,12 @@ 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).
|
||||
> ⚠️ **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; Wi-Fi ТВ к тому моменту был 867 PHY — быстрее).
|
||||
>
|
||||
> **TODO (если ТВ остаётся на проводе):** обновить stale-ссылки на `.75` → `.70`:
|
||||
> - dnsmasq `address=/tv/192.168.1.75` (`/jffs/configs/dnsmasq.conf.add`) → `192.168.1.70`
|
||||
> - `~/.ssh/config` на Mac (хост `192.168.1.75`, user root) → host IP `.70`
|
||||
> - Выполнить только по явной команде пользователя (правки `.ssh/config`/роутера).
|
||||
| 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 очиститель воздуха |
|
||||
|
||||
Reference in New Issue
Block a user