Smart TV за три копейки — это отличный экран и абсолютно негодное железо. Попытка запустить на таком телевизоре торрент-клиент или локальный сервер TorrServer превращает просмотр в слайд-шоу, а интерфейс — в кирпич.

Поэтому я решил вынести TorrServer туда, где ему самое место — на домашний сервер под управлением Proxmox VE.

Ниже — подробный гайд о том, как развернуть TorrServer в легковесном Debian LXC, настроить кэширование исключительно в оперативную память (чтобы сберечь SSD хоста), написать автоматический watchdog-скрипт для контроля зависаний и подружить всё это с Lampa на телевизоре.

1. Почему TorrServer на телевизоре — это насилие над железом

Начнем с матчасти. Современный Smart TV (особенно бюджетный вроде Xiaomi Mi TV на платформе hermano или Hartens) комплектуется чипсетом из разряда «лишь бы завелась ОС». Процессор с трудом переваривает отрисовку меню лаунчера, а оперативной памяти обычно от 1 до 1.5 ГБ (из которых система и графический стек сжирают больше половины).

Когда вы запускаете TorrServer непосредственно на ТВ:

1. Сетевой шторм: Сервер начинает активно общаться с торрент-сетью. Это сотни сетевых соединений в секунду, которые перегружают сетевой стек Android и слабенький Wi-Fi чип телевизора. В итоге отваливается не только стрим, но и вообще вся домашняя сеть на устройстве.

2. Дефицит RAM: Разбор торрент-файла и буферизация тяжелого 4K-видео съедает сотни мегабайт оперативки. Android видит критический дефицит RAM, начинает агрессивно выгружать фоновые службы (включая сам плеер) или просто падает в Out of Memory (OOM).

3. Троттлинг процессора: Хеширование и сборка торрент-пакетов «на лету» грузят слабый CPU на 100%. Телевизор моментально разогревается, сбрасывает частоты ядра и уходит в троттлинг. Результат — слайд-шоу вместо фильма и пульт, реагирующий на нажатия с задержкой в 5 секунд.

Выход простой: убрать TorrServer с телевизора. Пускай ТВ работает как обычный медиаплеер (рендерит готовый HTTP-видеопоток), а всю тяжелую работу по скачиванию, хешированию и буферизации делает домашний сервер.

2. Развертывание LXC-контейнера на Proxmox

Я разворачиваю TorrServer в отдельном LXC-контейнере на базе Debian 12 на хосте Proxmox VE damba (192.168.188.66).

Изначально планировал взять свободный VMID 211, но он уже был занят инстансом Vaultwarden. Поэтому взял 212.

Для TorrServer не требуется полноценная виртуальная машина. Достаточно легковесного unprivileged LXC-контейнера. Выделяем под него скромные ресурсы:

• VMID: 212

• Hostname: torrserver

• CPU: 2 ядра (Cores) — этого достаточно для быстрого парсинга метаданных тяжелых торрентов на старте.

• RAM: 2 ГБ (для ОС и кэширования).

• Swap: 512 МБ.

• Disk: 8 ГБ на пуле local-lvm (LVM-thin).

• Сеть: статический IP 192.168.188.65/24, шлюз 192.168.188.1. DNS-сервером указал локальный AdGuard Home (192.168.188.53).

Создать контейнер можно одной командой на хосте Proxmox:

pct create 212 local:vztmpl/debian-12-standard_12.2-1_amd64.tar.zst \
  -cores 2 -memory 2048 -swap 512 \
  -net0 name=eth0,bridge=vmbr0,ip=192.168.188.65/24,gw=192.168.188.1 \
  -nameserver 192.168.188.53 -ostype debian -storage local-lvm -rootfs 8 \
  -unprivileged 1 -features nesting=1 -onboot 1

После создания запускаем контейнер и заходим в его консоль:

pct start 212
pct enter 212

Ставим стабильный релиз TorrServer MatriX.141.4. Создаем systemd-сервис для автозапуска службы:

# Скачиваем бинарник
wget -O /usr/bin/TorrServer https://github.com/YouROK/TorrServer/releases/download/MatriX.141/TorrServer-linux-amd64
chmod +x /usr/bin/TorrServer

# Создаем конфигурационный юнит systemd
cat <<EOF > /etc/systemd/system/torrserver.service
[Unit]
Description=TorrServer Media Server
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/TorrServer -d /opt/torrserver -p 8090
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

# Запускаем службу
systemctl daemon-reload
systemctl enable --now torrserver

Проверяем, что служба слушает порт 8090:

systemctl status torrserver
ss -tlnp | grep 8090

3. Сбережение SSD хоста: настраиваем RAM-кэш

Если оставить TorrServer с настройками по умолчанию, он может писать кэш на диск. Для домашнего сервера, где Proxmox часто крутится на обычном потребительском SSD, это приговор. Стриминг одного 4K-фильма генерирует до 80–100 ГБ перезаписи данных. При активном просмотре за пару месяцев можно исчерпать ресурс TBW недорогого накопителя.

Решение — кэшировать данные строго в оперативную память (RAM).

Тут обнаружился нюанс. В версиях TorrServer Matrix стандартный GET-запрос к /settings возвращает ошибку 404. Настройки теперь получаются и задаются через POST-запросы к API.

Для конфигурации RAM-кэша отправляем JSON-пакет на порт 8090:

curl -s -X POST -H "Content-Type: application/json" \
  -d '{"action": "set", "sets": {"UseDisk": false, "CacheSize": 536870912, "PreloadCache": 30, "ConnectionsLimit": 200}}' \
  http://192.168.188.65:8090/settings

Разберем ключевые параметры:

• "UseDisk": false — отключаем кэш на диске. Теперь буфер пишется только в оперативную память. Ресурс SSD в безопасности.

• "CacheSize": 536870912 — выделяем ровно 512 МБ под буфер (размер указывается в байтах). Это оптимальный объем для сглаживания скачков скорости интернета на тяжелых релизах.

• "PreloadCache": 30 — буфер предзагрузки 30% от размера кэша. Плеер начнет воспроизведение только после того, как в памяти накопится около 150 МБ данных. Это исключает затыки и подгрузки в процессе просмотра.

• "ConnectionsLimit": 200 — лимит соединений. Бюджетные роутеры начинают забивать таблицы NAT и виснуть, если торрент-клиент открывает 500+ соединений. 200 — золотая середина, обеспечивающая высокую скорость скачивания без сетевых лагов.

Проверить, что настройки применились, можно запросом:

curl -s -X POST -H "Content-Type: application/json" -d '{"action": "get"}' http://192.168.188.65:8090/settings

4. Обеспечение живучести: watchdog-скрипт на хосте PVE

Контейнер запущен, настройки применены, кино играет. Но что если служба TorrServer зависнет из-за кривого торрента или перегрузки сети? Или сам LXC уйдет в ступор? Заходить руками через SSH и перезапускать — лень. Нужен автоматический контроль.

Я написал сторожевой bash-скрипт /root/torrserver-watchdog.sh, который крутится непосредственно на хосте Proxmox VE. Он проверяет три сценария отказа:

1. LXC контейнер 212 вообще не запущен запускаем контейнер.

2. Зависла подсистема cgroups внутри ядра PVE, из-за чего контейнер числится запущенным, но команды pct exec виснут намертво принудительно останавливаем контейнер через pct stop и запускаем заново.

3. Контейнер живой, но TorrServer не отвечает на запросы по HTTP (порт 8090) перезапускаем службу systemd внутри LXC, а если не помогло — перезапускаем весь контейнер.

Вот код скрипта:

#!/usr/bin/env bash
# /root/torrserver-watchdog.sh — автоперезапуск TorrServer при зависаниях.
# Лог работы:  /var/log/torrserver-watchdog.log

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
LXC_ID=212
TORRSERVER_IP="192.168.188.65"
LOG_FILE="/var/log/torrserver-watchdog.log"

# Ротируем лог, если он превысил 100 КБ
if [ -f "$LOG_FILE" ] && [ "$(wc -c < "$LOG_FILE")" -gt 102400 ]; then
    mv "$LOG_FILE" "${LOG_FILE}.old"
fi

log_msg() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') $*" >> "$LOG_FILE"
}

# 1) Проверяем, запущен ли контейнер
STATUS=$(pct status $LXC_ID 2>&1)
if [[ "$STATUS" != *"status: running"* ]]; then
    log_msg "TorrServer LXC $LXC_ID не запущен. Старт контейнера..."
    pct start $LXC_ID 2>&1 >> "$LOG_FILE"
    exit 0
fi

# 2) Проверяем зависание cgroups (pct exec зависает по таймауту)
timeout 5 pct exec $LXC_ID -- systemctl is-active torrserver >/dev/null 2>&1
EXIT_CODE=$?
if [ $EXIT_CODE -ne 0 ]; then
    if [ $EXIT_CODE -eq 124 ]; then
        log_msg "LXC $LXC_ID завис на уровне cgroups (pct exec timeout). Перезапуск контейнера..."
        pct stop $LXC_ID 2>&1 >> "$LOG_FILE"
        sleep 2
        pct start $LXC_ID 2>&1 >> "$LOG_FILE"
        exit 0
    else
        log_msg "Служба torrserver не активна (код $EXIT_CODE). Перезапуск службы..."
        pct exec $LXC_ID -- systemctl restart torrserver 2>&1 >> "$LOG_FILE"
        exit 0
    fi
fi

# 3) Проверяем отзывчивость HTTP API
HTTP_CODE=$(curl --max-time 5 -s -o /dev/null -w "%{http_code}" "http://${TORRSERVER_IP}:8090/")
if [ "$HTTP_CODE" -ne 200 ] && [ "$HTTP_CODE" -ne 404 ]; then
    log_msg "TorrServer не отвечает по HTTP (код '$HTTP_CODE'). Перезапускаем службу..."
    pct exec $LXC_ID -- systemctl restart torrserver 2>&1 >> "$LOG_FILE"
    sleep 5
    
    # Повторная проверка
    HTTP_CODE_AGAIN=$(curl --max-time 5 -s -o /dev/null -w "%{http_code}" "http://${TORRSERVER_IP}:8090/")
    if [ "$HTTP_CODE_AGAIN" -ne 200 ] && [ "$HTTP_CODE_AGAIN" -ne 404 ]; then
        log_msg "Повторный сбой HTTP после рестарта службы. Перезапуск всего контейнера..."
        pct stop $LXC_ID 2>&1 >> "$LOG_FILE"
        sleep 2
        pct start $LXC_ID 2>&1 >> "$LOG_FILE"
    else
        log_msg "HTTP-сервис успешно восстановился после перезапуска службы."
    fi
fi

Сохраняем скрипт, делаем его исполняемым и забиваем в cron хоста Proxmox для запуска каждые 2 минуты:

chmod +x /root/torrserver-watchdog.sh
crontab -e
# Добавляем строку:
# */2 * * * * /root/torrserver-watchdog.sh

5. Мониторинг в Uptime Kuma

Чтобы визуально отслеживать график доступности TorrServer и моментально получать уведомления в Telegram при падении, я интегрировал его в существующий инстанс Uptime Kuma (LXC 200).

Для этого я обновил автоматический скрипт конфигурации Kuma:

# uptime-kuma-setup.py
# ...
# Добавляем монитор TorrServer
api.add_monitor(
    type="http",
    name="TorrServer Web",
    url="http://192.168.188.65:8090/",
    interval=60,
    retryInterval=30,
    resendInterval=0,
    maxRetries=2,
    notificationIDList=[1] # Идентификатор группы уведомлений в Telegram
)

Теперь, если TorrServer отключится, я узнаю об этом из уведомления в мессенджере раньше, чем домашние успеют дойти до телевизора.

6. Настройка Lampa на Android TV

Остался финальный шаг — привязать наш сервер к телевизорам в комнатах (у меня это tv-bana и tv-room1).

1. Устанавливаем на телевизор приложение Lampa (официальный клиент).

2. Заходим в Настройки TorrServer.

3. Устанавливаем Тип подключения в значение Основное (или сервер).

4. В поле Адрес TorrServer прописываем путь к нашему LXC-контейнеру: http://192.168.188.65:8090.

5. Нажимаем кнопку Проверить. Индикатор статуса должен загореться зеленым цветом с версией сервера (MatriX.141.4).

Настройка поиска торрентов:

Lampa сама по себе — это просто красивый каталог и удобная оболочка. Чтобы она находила раздачи, нужен парсер.

1. Заходим в Настройки Парсер.

2. Включаем опцию Использовать парсер — Да.

3. В строке Адрес парсера прописываем зеркало Jackett-враппера: jac.red (или свой инстанс, если развернули локально).

4. Включаем поиск по всем категориям и проверяем, что в карточках фильмов появилась вкладка «Торренты».

Проверяем работу: открываем любой тяжелый фильм, переходим во вкладку «Торренты», выбираем раздачу на 50–70 ГБ. Видео запускается за 3–5 секунд. Перемотка работает мгновенно. TorrServer буферизует поток в оперативную память сервера, а телевизор просто играет готовый видеопоток без малейших тормозов и перегрева.

Итог проделанной работы

Перенос TorrServer с телевизора на выделенный сервер Proxmox полностью оправдал себя:

• Стабильность: Никаких зависаний и вылетов Lampa.

• Качество: Спокойный просмотр 4K HDR релизов с высоким битрейтом без тормозов.

• Безопасность железа: Нулевая нагрузка на CPU/RAM телевизора и нулевой износ SSD-накопителей хоста виртуализации.

• Отказоустойчивость: Любые зависания службы или контейнера автоматически разруливает watchdog-скрипт за пару минут.