Tdarr в Docker Compose: готовый файл

MAATRIX

Библиотека в 5–10 ТБ смешанных кодеков — H.264 из старых рипов, H.265 из новых, где-то AV1, где-то остатки MPEG2 — это боль при прямом воспроизведении на слабых клиентах и лишний расход места на диске. Tdarr решает это автоматически: сканирует библиотеку, находит файлы, не соответствующие вашему стандарту, и перекодирует их по очереди или параллельно на нескольких узлах. Ниже — рабочий docker-compose.yml, который можно поднять за 10 минут, и объяснение, почему на выделенном сервере эта штука раскрывается лучше, чем на домашнем NAS.

Что такое Tdarr и зачем он нужен

Tdarr — это сервер очереди перекодирования плюс один или несколько «нод» (node), которые реально жуют файлы через ffmpeg или HandBrakeCLI. Архитектура разделена намеренно:

• Server — веб-интерфейс, база данных задач, библиотечные сканы, плагины (flow-логика: «если кодек не HEVC — перекодировать», «если контейнер не MKV — remux» и т.д.).
• Node — воркер, который тянет задания с сервера и выполняет их. Нод может быть несколько, в том числе на разных машинах — распределённое перекодирование в чистом виде.

Типовой сценарий: у вас скопилась медиатека Plex или Jellyfin с разнородными файлами. Часть — старые H.264 1080p по 8–12 ГБ на серию, часть — свежие релизы в HEVC 10-bit. Вы хотите привести всё к одному стандарту (например HEVC CRF 23, AAC-звук, MKV-контейнер), чтобы сэкономить место и снизить нагрузку на транскодирование при стриминге. Related: Jellyfin или Plex — что выбрать для сервера.

Важный нюанс: Tdarr не «магически» сжимает без потерь — это перекодирование с потерей качества (lossy), пусть и контролируемой. Если оригиналы вам дороги, держите бэкап до первого прогона на реальных данных.

Готовый docker-compose.yml

Вот рабочая конфигурация — сервер и один нод в одном файле, с NVIDIA-ускорением опционально (закомментировано, включается при наличии GPU):

version: "3.8"

services:
  tdarr:
    image: ghcr.io/haveagitgat/tdarr:latest
    container_name: tdarr
    restart: unless-stopped
    network_mode: bridge
    ports:
      - "8265:8265"   # веб-интерфейс
      - "8266:8266"   # порт для нод (internal node)
    environment:
      - TZ=Europe/Moscow
      - PUID=1000
      - PGID=1000
      - UMASK_SET=002
      - serverIP=0.0.0.0
      - serverPort=8266
      - webUIPort=8265
      - internalNode=true
      - inContainer=true
      - ffmpegVersion=6
      - nodeName=internalNode
      # для NVIDIA-ускорения раскомментируйте runtime ниже
    volumes:
      - ./server:/app/server
      - ./configs:/app/configs
      - ./logs:/app/logs
      - /mnt/media:/media
      - /mnt/transcode-cache:/temp
    # deploy:
    #   resources:
    #     reservations:
    #       devices:
    #         - driver: nvidia
    #           count: 1
    #           capabilities: [gpu]

  tdarr-node2:
    image: ghcr.io/haveagitgat/tdarr_node:latest
    container_name: tdarr-node2
    restart: unless-stopped
    network_mode: bridge
    environment:
      - TZ=Europe/Moscow
      - PUID=1000
      - PGID=1000
      - nodeID=node2
      - serverIP=tdarr
      - serverPort=8266
      - inContainer=true
      - ffmpegVersion=6
    volumes:
      - ./configs:/app/configs
      - ./logs:/app/logs
      - /mnt/media:/media
      - /mnt/transcode-cache:/temp
    depends_on:
      - tdarr

Обратите внимание на два тома: /media (сама библиотека) и /temp (кэш перекодирования). Второй должен быть на быстром диске — если это NVMe, скорость обработки одного файла ощутимо выше, чем на медленном сетевом хранилище.

Настройка библиотек и плагинов после запуска

После docker compose up -d откройте http://<ip-сервера>:8265. Первые шаги:

1. Libraries → Add new library — укажите путь /media/movies или /media/tv, source/output folder можно оставить одинаковыми (перезапись на месте) либо развести, если хотите сохранить оригиналы отдельно.
2. Plugins — это сердце Tdarr. Стандартный набор для «привести всё к HEVC»:

• Tdarr_Plugin_MC93_Migz1FFMPEG — базовая нормализация под HEVC.
• Или сборка через Flow (новый визуальный конструктор в актуальных версиях) — узлы «Check video codec» → «если не hevc» → «Transcode Video» с параметрами CRF/preset.

1. Transcode options: для CPU-перекодирования разумная точка старта — libx265, preset medium, crf 23. Для GPU (NVIDIA) — hevc_nvenc, preset p5, cq 23.

Таблица ориентировочных соотношений (у вас цифры будут отличаться в зависимости от контента и настроек — это не бенчмарк, а грубый ориентир для планирования):

Правило простое: не перекодируйте то, что уже в целевом кодеке — Tdarr это умеет проверять сам через condition-плагины, но проверьте логику flow перед массовым запуском на всей библиотеке.

CPU vs GPU: что реально нужно для перекодирования

Здесь развилка, которая определяет и выбор сервера, и скорость всего процесса.

Программное перекодирование (libx265 на CPU) даёт лучшее качество на бит, но требует много ядер и времени. Для очереди из тысяч файлов на 4-ядерном VPS это может растянуться на недели непрерывной работы.

Аппаратное ускорение (NVENC на NVIDIA, QSV на Intel) — на порядок быстрее, но при агрессивных настройках качество на тот же битрейт обычно чуть хуже, чем у x265 software-энкодера. Для домашней библиотеки разница часто малозаметна на глаз, особенно при разумном CQ/CRF.

Если у вас плотная библиотека и хочется закончить перекодирование за разумное время, а не за месяц, GPU-сервер с NVENC — практичный выбор. Мы подробно разбирали смежную тему в статье про основы GPU passthrough — тот же принцип пробрасывания карты в контейнер актуален и для Tdarr в Docker.

Если задача больше про масштаб и параллелизм (несколько нод сразу жуют очередь), выделенный сервер с несколькими ядрами и высокой пропускной способностью диска для /temp окупается быстрее, чем попытки уместить это на домашнем NAS с двумя ядрами ARM.

Распределённое перекодирование на нескольких нодах

Главная сила Tdarr — не в одном контейнере, а в кластере нод. Схема:

• Сервер (tdarr) стоит один раз, хранит очередь и статистику.
• Каждый дополнительный нод — отдельный контейнер tdarr_node, который может жить хоть на другой машине, лишь бы был сетевой доступ до serverIP:serverPort и общий доступ к файлам библиотеки (через NFS/SMB-монтирование одного и того же пути).

Пример второго физического сервера, монтирующего ту же библиотеку по NFS:

# на втором сервере — монтируем ту же медиатеку
sudo mount -t nfs 10.0.0.5:/mnt/media /mnt/media

# и поднимаем только нод, без сервера
docker run -d --name tdarr-node-remote \
  -e serverIP=10.0.0.5 -e serverPort=8266 \
  -e nodeID=remote-gpu-node -e inContainer=true \
  -v /mnt/media:/media -v /mnt/transcode-cache:/temp \
  ghcr.io/haveagitgat/tdarr_node:latest

Так можно держать «дешёвый» CPU-сервер для общей очереди и хранения, а тяжёлое перекодирование гонять на отдельном GPU-узле — классическая связка для тех, кто уже смотрел в сторону выделенного сервера под медиатеку.

Мониторинг очереди и типичные проблемы

Веб-интерфейс на :8265 показывает вкладку Queue с прогрессом по каждому файлу и вкладку Statistics с общей экономией места. Полезные команды для диагностики со стороны контейнера:

# логи сервера
docker logs -f tdarr

# логи конкретного нода
docker logs -f tdarr-node2

# проверить, что ffmpeg внутри контейнера видит GPU (для NVIDIA)
docker exec -it tdarr nvidia-smi

Частые проблемы:

• Файл завис в статусе "Transcoding" навсегда — обычно нехватка места в /temp (кэш перекодирования не поместился) или права PUID/PGID не совпадают с владельцем файлов на хосте. Проверьте id пользователя, под которым лежат файлы, и выставьте те же PUID/PGID в environment.
• Нод не подключается к серверу — чаще всего сетевой конфликт: если сервер и нод в разных docker network, serverIP=tdarr (имя сервиса) работать не будет между хостами — используйте реальный IP.
• NVENC не подхватывается — нужен nvidia-container-toolkit на хосте и правильно указанный runtime: nvidia (или deploy.resources в Compose v2, как в примере выше).

Автоматизация: from watch folder до готового файла

Чтобы не запускать сканы вручную, включите в Tdarr Scan on start и Watch folder for changes в настройках библиотеки — тогда новые файлы, попавшие в медиатеку (например, из Radarr/Sonarr), автоматически встают в очередь. Если у вас уже настроен автообновляемый стек контейнеров, посмотрите статью про автообновление Watchtower на VPS — Tdarr тоже можно держать под автообновлением образов, только учитывайте, что смена мажорной версии иногда меняет формат flow-плагинов.

Для полной автоматизации связки «скачал → перекодировал → досмотрел в Jellyfin» удобно держать все сервисы в одной docker-сети и на одном сервере, чтобы диск с медиатекой был общим для Sonarr/Radarr, Tdarr и медиасервера без сетевых прослоек NFS — так быстрее и меньше точек отказа.

Частые вопросы