--- title: Lampac на TrueNAS и Konka Q85 — рабочая схема created: '2026-10-30' updated: '2026-11-01' type: tech namespace: personal tags: - lampac - truenas - konka - webos - timecode related: - '[[personal/tech/lampac-deployment]]' - '[[personal/tech/konka-q85-novosibirsk]]' - '[[family/how-to/truenas-infrastructure]]' --- # Lampac на TrueNAS и Konka Q85 — рабочая схема ## Kraken: дисковый кэш TorrServer — проверено 2026-11-01 На Kraken стандартный RAM-кэш96 МиБ заменён на **2 ГиБ кэша на диске**: `CacheSize=2147483648`, `UseDisk=true`, `TorrentsSavePath=/lampac/cache/torrserver`, `RemoveCacheOnDrop=true`. Хост-каталог: `/srv/dev-disk-by-uuid-6194539b-03e0-4f33-986b-4da09834e82f/lampac/cache/torrserver`; используется существующий постоянный cache bind mount. Настройка сохраняется в `data/ts/settings.json`. Перед переключением было около1,2 ТБ свободного места; активных раздач не было. Старые настройки и список торрентов сохранены с mode0600 в `backups/kraken-disk-cache-20261101/`. Применено через авторизованный локальный API TorrServer внутри контейнера; пароль из `data/ts/accs.db` не публикуется. Контейнер не пересоздавался, явный Docker-лимит памяти Kraken не добавлялся и не менялся. Это2 ГиБ **дискового**, а не зарезервированного RAM-кэша; рабочая память и освобождаемый файловый кэш ОС остаются. Проверены API и сохранённый конфиг. Отдельный временный Ubuntu-торрент подтвердил реальную запись8 файлов фрагментов на диск (около1,98 МБ) и чтение1 МиБ потока HTTP Range. Тестовая раздача удалена после проверки. Видео не переводилось на сетевой прокси. Штатная смена настроек MatriX.135 сбрасывает активные торренты и заново подключает движок; если фильм открыт при будущей смене режима, может потребоваться открыть его повторно. Описание общей схемы — [[personal/tech/lampac-truenas]], инструкция — [lampac-scripts/deploy/README.md](https://git.mallexxx.duckdns.org/git_admin/lampac-scripts/src/branch/main/deploy/README.md). Проверено 2026-10-30. Lampac развёрнут на TrueNAS, клиент установлен на Konka Q85 в Новосибирске. Это аддон к официальному серверу, не форк Lampac. ## Дисковый кэш TorrServer — обновление 2026-10-31 **Текущая настройка: 2 ГиБ кэша на диске**, не в RAM: `UseDisk=true`, `CacheSize=2147483648`, `TorrentsSavePath=/lampac/cache/torrserver`, `RemoveCacheOnDrop=true`. На хосте это `/mnt/RED_2TB/docker/lampac/cache/torrserver`, существующий постоянный cache bind mount. Лимит памяти контейнера возвращён с4 к **2 ГиБ**. После перехода фактическое потребление контейнера было около1 ГиБ. ОС/ZFS могут использовать освобождаемую память для файлового кэша; это не отдельная обязательная RAM-буферизация2 ГиБ в TorrServer. Первоначально оставлен стандартный RAM-кэш96 МиБ, затем просьба увеличить его была неверно интерпретирована как2 ГиБ RAM. Владелец уточнил, что не хотел занимать столько оперативной памяти. После проверки исходников MatriX.135 включён штатный дисковый backend; ограничения, мешающего писать кэш на диск, нет. Применение через оболочку Lampac `/ts/settings` вернуло500 и не изменило настройку. Повтор через авторизованный **локальный** API TorrServer `127.0.0.1:9085` внутри контейнера с приватными данными `data/ts/accs.db` сработал. Порт9085 наружу не открывался. Штатный SetSettings сбрасывает активные торренты/подключает движок заново, поэтому воспроизведение при смене режима может потребовать повторного открытия. Не обещать применение без сброса активного буфера. Проверено фактически: `UseDisk=true` в API и сохранённом `data/ts/settings.json`; появились4 файла фрагментов,16 МиБ на диске; HTTP Range-запрос видеопотока получил206 и прочитал1 МиБ. Контейнер не пересоздавался. Прежние настройки: `backups/torrserver-before-disk-cache.json`, Compose: `backups/compose-before-disk-cache.yml`. Фильм «Красота по-американски» — Remux31,37 ГиБ, средний битрейт36,9 Мбит/с. Замеры скачивания25–43 Мбит/с, запас в буфере ТВ4,8–6с. Поток шёл напрямую с `192.168.2.197:9118/ts/stream/…`; прокси обслуживал TMDB. Увеличение кэша сглаживает временные просадки после заполнения, но не устраняет постоянную нехватку скорости раздачи. Файлы кэша вручную при активном потоке не удалять. ## Серверы и исходники - TrueNAS: `truenas_admin@mallexxx.duckdns.org`, каталог `/mnt/RED_2TB/docker/lampac`, адрес приложения `http://192.168.2.197:9118`. - Обычный Docker Compose, не TrueNAS Apps. Контейнер `lampac`: официальный образ `ghcr.io/lampac-nextgen/lampac:1.87.3`, amd64, лимиты 2 ГБ RAM / 1 CPU; кэш TorrServer — 2 ГиБ на диске, порт опубликован только на LAN-адресе. GPU-транскодирование не настроено. - Kraken остаётся на официальном arm64-образе 1.87.3 и прежнем адресе `http://192.168.1.14:9118`. - Mac: `/Users/admin/Developer/lampac-scripts`, ветка `main`, [Gitea](https://git.mallexxx.duckdns.org/git_admin/lampac-scripts). - Генератор: `/Users/admin/Developer/watchlist-sync`, ветка `main`, [GitHub](https://github.com/mallexxx/watchlist-sync). - Точные Compose, init.conf, шаблоны и инструкция восстановления — [deploy/README.md](https://git.mallexxx.duckdns.org/git_admin/lampac-scripts/src/branch/main/deploy/README.md). Приватные ключи и рабочие конфиги с секретами в git не добавляются. ## Konka и встроенные постеры Konka Q85: `192.168.2.124`, webOS 7.5.6; приложение `com.lampac.tv` версии 1.0.0 установлено через существующий Homebrew Channel с проверкой SHA256 пакета. Его `lampac_url` в localStorage: `http://192.168.2.197:9118`. Настройку root/privacy не меняли; Developer Mode не устанавливали. Пустые постеры имели два отдельных условия: NAS не получал TMDB напрямую, а клиентская автоматика могла выключать прокси. На ТВ сохранены **`proxy_tmdb=true` и `proxy_tmdb_auto=false`**. Одной настройки серверного poster fetcher недостаточно: при выключенном клиентском флаге CUB обращается к `image.tmdb.org` напрямую. На NAS отдельный контейнер `lampac-egress` предоставляет SOCKS только внутри сети Lampac, без опубликованного порта. Он использует существующий авторизованный маршрут `kraken-user` через Caddy/VLESS и Kraken. Его приватный конфиг: `config-module/egress.json`, mode0640, group1000; шаблон без клиентского ID — в репозитории. Прокси `socks5://lampac-egress:1080` включён в: - `tmdb.proxyapi` и `tmdb.proxyimg` — встроенные TMDB/CUB; - `posterApi` — постеры карточек Catalog; - `serverproxy.image` — обработчик изображений. **Глобальный прокси для HTTP/видео не включён.** Проверенный тестовый видеопоток шёл напрямую с LAN-адреса NAS. Общий `vless-proxy` не меняли; при проверке его исходящие TLS-соединения обрывались. Это наблюдение на дату настройки, а не установленная причина отказа общей инфраструктуры. Внутренний вход Caddy — `192.168.2.197:8443`, TLS-имя `vpn.mallexxx.duckdns.org`. На `192.168.2.197:443` находится интерфейс TrueNAS: использовать его вместо 8443 нельзя, сертификат другой. ## Единая история без синхронизации SQLite Рабочая TimeCode находится на TrueNAS в постоянном `database/TimeCode.sql`. Kraken-клиент обращается к тому же серверу через HTTPS API. **Двусторонней репликации SQLite, rsync БД или общего сетевого файла БД нет.** История из Kraken перенесена один раз штатными `/timecode/dump` → `/timecode/set`; сохранены все 9 записей и их прогресс. Оба сервера используют одинаковый серверный `instance.uid`; профили остаются отдельными областями. Старая БД Kraken оставлена для отката. В существующем HTTPS-сайте Caddy выделен префикс `https://git.mallexxx.duckdns.org/lampac-history` с точным списком TimeCode-маршрутов. Без правильного `history_key` — 404; прочие маршруты Lampac наружу через него не открыты. Gitea продолжает работать. Выполнен reload Caddy, не перезапуск общего сервиса. Ключ транспорта называется **`history_key`, не `token`**: `token` в Lampac меняет владельца данных. В сгенерированном клиенте и чтение, и запись должны независимо передавать `uid`; это проверяется исполнением реальных URL-методов в тесте. Kraken: приватный результат `scripts/build_timecode.py` установлен в `config-module/timecode-plugin.js`, примонтирован в `/lampac/module/Sync/TimeCode/plugin.js:ro`. NAS использует штатный локальный TimeCode-клиент. Межсайтовые WebSocket-уведомления не добавлялись; прогресс читается при обновлении карточки/таймлайна. ## Каталог и отметки Obsidian Единственный генератор и писатель Obsidian остаётся на Kraken. Ночной `/home/kraken/scripts/watchlist-nightly.sh` после сборки каталога публикует готовые JSON на NAS через `publish_feed.py`. На NAS ключ приёма ограничен `restrict` и forced command `receive_feed.py --root /mnt/RED_2TB/docker/lampac`. Принимаются только файлы каталога; SQL, ссылки, пути вне разрешённого списка и код отклоняются. Файлы заменяются атомарно по одному, карточки раньше основного манифеста. Проверена публикация 544 файлов. `watchlist-sync` читает общий HTTPS dump через `LAMPAC_TIMECODE_DB` в приватном `.env`. Проверен dry-run: 9 записей, изменений списка не внесено. Второй генератор/писатель на NAS не запущен. Порог отметки фильма — 90%; существующее поведение сериалов этим изменением не расширялось. ## Данные и бэкапы Постоянные `wwwroot` и `data` при первой установке нужно заполнить из образа до запуска. Пустые bind mounts скрывают и frontend, и резервные Cloudflare IP-файлы; при недоступной сети это приводило к падению старта. Конфиги должны читаться uid1000: режим0600 после SCP для `init.conf` не подходит. Контейнер пишет от uid1000/gid1000, администратор NAS — uid950 в группе1000. **`TimeCode.sql`, `-wal`, `-shm` должны иметь mode0664 и group1000.** Read-only SQLite-подключение тоже может создавать WAL/SHM. Первый бэкап от uid950 создал их с0644, после чего сервер не мог записывать прогресс. Владельцы/права исправлены, старые подключения закрыты перезапуском только Lampac. `scripts/backup_history.py` перед открытием проверяет group write, закрывает подключения, использует SQLite online backup и проверку целостности. NAS crontab: ежедневно04:27 по времени хоста, хранение30 дней в `backups/timecode`. Часовой пояс приложения — Asia/Novosibirsk; расписание cron не следует автоматически считать этим часовым поясом. Это локальный бэкап, не синхронизация БД. После исправления проверена API-запись **до и после повторного бэкапа**; все 9 записей и значения прогресса сохранены. Для отката сохранены прежние Compose/Caddy/настройки и снимки истории. Живую БД обычным копированием не подменять. ## Что проверено - HTTP200 и окончание запуска `Configure complete`; одного Docker healthcheck недостаточно. - Реальный поиск «дюна» на Konka через экранную клавиатуру: результаты получены, JavaScript-ошибок нет, вкладка watchlist одна. - На видимом экране: 7 встроенных и28 каталожных постеров загружены, сломанных0; настройки прокси подтверждены после перезагрузки приложения. - Плеер Lampac декодировал тестовый H.264-поток640×360 с NAS: время увеличивалось, `readyState=4`, ошибки отсутствовали. Непрерывный пяти-/десятиминутный тест, реальная онлайн-раздача и звук на слух отдельно не подтверждены. - 10 автоматических тестов: 5 поиска, 3 развёртывания/истории/бэкапа, 2 чтения TimeCode API. - Изменения запушены в обе репозитории; локальные копии в Developer обновлены. Временный установщик на роутере18085, ролик и диагностические SSH-перенаправления удалены. Связано: [[personal/tech/lampac-deployment]], [[personal/tech/konka-q85-novosibirsk]], [[family/how-to/truenas-infrastructure]], [[personal/plans/lampac-watched-to-watchlist]].