Tdarr автоматизирует обслуживание медиатеки: сканирует папки с видео и аудио, по заданным правилам выполняет транскодирование и ремультиплексирование через FFmpeg или HandBrake, удаляет и упорядочивает потоки, проверяет файлы на повреждения и распределяет обработку между CPU- и GPU-воркерами на одном или нескольких узлах.

Программа рассчитана не на разовую конвертацию нескольких роликов, а на постоянное приведение большой коллекции к определённым требованиям. Для каждой библиотеки задаются источник, транскод-кэш, фильтры, расписание и логика обработки. После сканирования Tdarr помещает файлы в очереди проверки и транскодирования, а подключённые Nodes забирают подходящие задания с учётом типа воркера, доступного оборудования и ограничений конкретного потока.

Ключевая особенность Tdarr — условная обработка. Правильно собранный стек Classic Plugins или Flow не должен повторно кодировать всё подряд: он анализирует контейнер, видеокодек, аудиодорожки, язык, разрешение, битрейт и другие свойства, выполняет только необходимые действия и оставляет уже соответствующие политике файлы со статусом Not required. Поэтому настройка начинается не с выбора одного пресета, а с формулировки правил, которым должна соответствовать медиатека.

Что именно делает Tdarr

Tdarr объединяет каталогизацию медиатеки, условную обработку и распределённое выполнение. Сервер хранит сведения о библиотеках и очередях, формирует задания и показывает состояние системы в WebUI. Nodes выполняют ресурсоёмкие операции. Один Node может работать на той же машине, что и сервер, а дополнительные узлы можно разместить на других компьютерах, если они имеют доступ к исходникам и транскод-кэшу либо настроены как unmapped-узлы для поддерживаемых сценариев.

На практике программа решает несколько классов задач: массовый переход с H.264 на HEVC или AV1 при наличии подходящей конфигурации; унификацию контейнеров; удаление лишних аудио- и субтитровых потоков; добавление совместимой аудиодорожки; перестановку потоков; очистку метаданных; изменение разрешения или частоты кадров; контроль целостности; выполнение собственных FFmpeg-команд; работу с файлами и каталогами внутри Flow. Эти действия можно соединять в последовательность с условиями и несколькими ветками.

Важно разделять перекодирование и remux. Если меняется видеокодек, качество, битрейт, разрешение или другой параметр с повторным сжатием, идёт транскодирование. Если кодеки потоков сохраняются, а меняется только контейнер, задача сводится к remux и выполняется заметно быстрее. Для крупных коллекций это принципиально: не стоит кодировать видео только ради перехода, например, из MKV в MP4, если нужные потоки совместимы с новым контейнером.

Как устроен рабочий цикл

Типичный цикл начинается с библиотеки. Tdarr сканирует указанный Source, извлекает технические сведения, обновляет базу и ставит новые элементы в очереди. После этого воркер получает файл, запускает требуемую проверку или логику транскодирования, создаёт промежуточный результат в Transcode Cache и передаёт управление следующему шагу. Если поток завершается успешно, рабочий файл либо заменяет оригинал, либо перемещается в предусмотренное сценарием место.

При Classic Plugin Stack последовательность устроена циклически: после изменения файл возвращается через стек и снова проверяется условиями, пока все правила не будут удовлетворены. Именно поэтому любой классический стек обязан иметь ясные условия остановки. Если правило кодировать в HEVC не исключает уже HEVC-файлы, система может снова и снова считать результат подходящим для повторной обработки. Документация отдельно предупреждает о необходимости исключать целевой кодек в простых правилах.

Flows работают иначе визуально и концептуально: пользователь строит граф из блоков с входами и одним или несколькими выходами. Ветка может проверить свойство файла, выбрать аппаратный или программный путь, сформировать FFmpeg-команду, выполнить её, оценить размер результата, провести health check, вернуть задание другому типу воркера и только затем заменить исходник. Такая схема лучше подходит для сложной логики, где одного линейного стека недостаточно.

Задания видны в секциях очередей и Staging. Для завершённых и проблемных операций доступны отдельные статусы, а Job Report сохраняет подробный ход конкретной работы. При корректной политике конечное состояние библиотеки — отсутствие необработанных файлов: при повторном проходе элементы должны получать Not required, потому что уже отвечают установленным требованиям.

Основные разделы интерфейса

Навигация Tdarr построена вокруг нескольких рабочих областей. Home/Tdarr показывает сервер, узлы, воркеры, Staging и статусные очереди. Search предназначен для поиска по проиндексированным свойствам. Stats визуализирует структуру коллекции и результаты обработки. Libraries хранит конфигурации источников и правил. Flows служит редактором графов. Classic Plugins даёт доступ к традиционным плагинам. Tools, Options и Logs нужны для переменных, ключей API, общих параметров и диагностики.

Раздел	Для чего используется	Что проверять в первую очередь
Tdarr / Home	Очереди, узлы, воркеры, Staging, активные задания	Есть ли свободный подходящий воркер и не остановлена ли обработка расписанием
Libraries	Источник, кэш, фильтры, health check, расписание, transcode options	Пути, Process Library, контейнеры сканирования и правила
Flows	Визуальные многошаговые сценарии	Есть ли Input File, корректные ветки, Execute и финальная работа с оригиналом
Classic Plugins	Поиск и настройка классических плагинов	Источник Community/Local, входные параметры, порядок стека
Search	Фильтрация базы и инспекция конкретных файлов	Контейнер, кодеки, разрешение, размер, потоки и история заданий
Stats	Сводка по библиотекам и результатам	Доли кодеков, контейнеров, ошибок, выполненных health checks
Logs / Job Reports	Диагностика сервера, узла и отдельного задания	Команда FFmpeg/HandBrake, код возврата, путь к файлу, сообщение об ошибке

Добавление библиотеки

Библиотека в Tdarr — это не просто папка, а самостоятельный набор правил. У каждой библиотеки свой Source, Transcode Cache, параметры сканирования, список контейнеров, health check, расписание и логика обработки. Благодаря этому фильмы, сериалы, домашнее видео и аудиоколлекции можно обрабатывать по разным политикам, даже если они обслуживаются одним и тем же набором Nodes.

При первом создании библиотеки полезно разделить две задачи: индексацию и фактическое изменение файлов. Сначала стоит указать источник, убедиться, что сканирование корректно видит нужные элементы, проверить технические свойства через Search и только затем включать Process Library с рабочими правилами. Такой порядок особенно важен для каталогов, где оригиналы нельзя легко восстановить.

Кнопка Options у библиотеки содержит операции Scan (Find new), Scan (Fresh), повторную постановку всех элементов в очередь транскодирования или health check, сброс статистики, дублирование настроек, очистку базы конкретной библиотеки и удаление самой библиотеки. Clear library и Delete library работают с записями Tdarr и конфигурацией, а не предназначены для удаления исходных медиафайлов с диска.

Source и сканирование

Source указывает корень медиатеки, которую Tdarr должен индексировать. В параметрах источника задаются папки или шаблоны, которые следует игнорировать, число потоков сканера, поведение folder watcher и задержка после обнаружения файла. При работе на быстром SSD увеличение File scanner threads может ускорить первичное считывание библиотеки, но на HDD или сетевом хранилище слишком большая параллельность способна только увеличить случайные обращения и ухудшить общую отзывчивость.

Folder watcher можно настроить на периодические проверки или использовать события файловой системы. Событийный режим уменьшает постоянную активность накопителя, но сетевые и удалённые файловые системы не всегда корректно передают такие уведомления. Если новые файлы или удаления пропускаются, для библиотеки можно включить почасовой Scan (Find new), который сверяет фактическое содержимое источника с базой.

Параметр Hold files after scanning оставляет обнаруженный файл в Hold на заданное число секунд. Это полезно, когда в ту же папку пишет загрузчик, медиаменеджер или программа, которая ещё перемещает, переименовывает и дописывает данные. Без задержки Tdarr может получить файл до завершения внешней операции, из-за чего появляются ошибки чтения, несовпадение размера или конфликт при замене.

Контейнеры для сканирования

В настройках Containers задаётся перечень расширений, которые библиотека должна считать медиаданными. Это фильтр входа в базу, а не выбор формата результата. Если в Source лежат сопутствующие файлы — изображения, текст, метаданные медиасервера, обложки, архивы, — их не следует включать в список контейнеров только потому, что они находятся рядом с видео.

Для смешанной библиотеки имеет смысл перечислить только реально обрабатываемые расширения. Это сокращает объём ненужной индексации и делает Search понятнее. При этом контейнер и кодек нельзя смешивать: MKV, MP4 и MOV — оболочки, а H.264, HEVC, AV1, AAC, AC-3 и другие кодеки находятся внутри. Один и тот же видеокодек может встречаться в нескольких контейнерах.

Transcode Cache и работа с промежуточными файлами

Transcode Cache обязателен для обычной схемы обработки. Node создаёт туда рабочий файл, а после успешного завершения сервер или последующие шаги Flow решают, что делать с результатом. Кэш нельзя воспринимать как резервную копию: его задача — временное хранение. Для больших библиотек место следует рассчитывать так, чтобы одновременно помещалось несколько наиболее крупных исходников и их временные копии с запасом на параллельные воркеры.

Отдельный SSD для кэша снижает конкуренцию за чтение и запись с дисками медиатеки. Однако при распределённой схеме важнее доступность путей: mapped-Node должен видеть и Source, и Cache как те же физические данные, которые видит Server. Если сервер обращается к файлу как к /media/movie.mkv, а Windows-узел видит ту же шару как W:/media/movie.mkv, разницу нужно описать Path Translators.

Не стоит размещать Transcode Cache внутри папки Source без крайней необходимости. Иначе folder watcher может начать индексировать промежуточные Tdarr-файлы как новые элементы библиотеки, особенно если фильтры и исключения настроены неточно. Раздельные каталоги также упрощают очистку после ошибки и позволяют контролировать свободное место отдельно от основного массива.

Очереди, Staging и статусы

После сканирования новые элементы попадают в очереди транскодирования и health check. Свободный воркер забирает только задание, которое соответствует его типу и находится внутри разрешённого расписания библиотеки. Если Process Library выключен, запуск воркеров сам по себе ничего не изменит: очередь останется, но обработка не начнётся.

Staging — промежуточная зона, где видны файлы, уже находящиеся в логике обработки или ожидающие следующего действия. В сложных Flows элемент может возвращаться в Staging с требованиями к типу воркера или тегам. Это нормальный механизм маршрутизации, но если файл остаётся там без прогресса, нужно открыть Job Report и проверить, какого ресурса или условия он ждёт.

Статус Success/Not required объединяет две разные ситуации. Success означает, что файл действительно изменялся и обработка завершилась успешно. Not required означает, что текущие правила не потребовали изменений. Для стабильной библиотеки второй статус важен не меньше первого: он показывает, что условия построены идемпотентно и повторный проход не провоцирует лишнее перекодирование.

Nodes и распределённая обработка

Tdarr разделяет координацию и вычисление. Server хранит библиотечное состояние, а Node получает конкретные задания и запускает FFmpeg, HandBrake и другие требуемые инструменты. Несколько Nodes позволяют задействовать разные компьютеры и ускорители: например, основной сервер может только индексировать NAS, рабочая станция — выполнять тяжёлый CPU encode, а машина с NVIDIA или Intel GPU — аппаратное транскодирование.

В интерфейсе узла отображаются его состояние, использование памяти и CPU, активные воркеры, название задания, прогресс и ETA. Через Options настраиваются аппаратный тип, лимиты, теги и связанные параметры; через Logs открывается журнал конкретного Node. Для автоматизированных развёртываний число воркеров также можно задавать переменными окружения, а затем при необходимости изменить через интерфейс.

При распределении нагрузки нельзя исходить только из количества ядер или GPU. Один быстрый NVENC-воркер может одновременно читать с сетевого массива сотни мегабит в секунду, а несколько CPU-воркеров — активно писать большие временные файлы. Реальное ограничение нередко находится в сети, дисковой подсистеме или кэше, поэтому увеличение Workers полезно делать постепенно.

Четыре типа воркеров

Тип	Назначение	Особенности
Transcode CPU	Программное транскодирование и CPU-задачи	Не берёт команды, в которых Tdarr распознаёт GPU-термины вроде nvenc, cuda или vaapi
Transcode GPU	Аппаратное транскодирование	Обрабатывает задания с GPU-параметрами; при отдельной опции может выполнять и CPU-задачи
Health Check CPU	Quick и Thorough проверки	Quick доступен только CPU-воркерам
Health Check GPU	Thorough health check с аппаратным ускорением	Требует корректно настроенного аппаратного пути декодирования

Кнопки лимитов у Node задают, сколько воркеров каждого типа Tdarr должен поддерживать активными. Если выключить уже работающий воркер, он завершит текущий элемент и только затем остановится. Отмена конкретного задания не уничтожает сам Worker: тот переходит к следующему подходящему элементу очереди.

Node priority и теги

Узлам можно задавать приоритет. Это полезно, если один компьютер должен получать задания раньше других, например потому что он быстрее или находится рядом с хранилищем. Приоритет — не замена тегам. Теги описывают пригодность Node для конкретного этапа: наличие определённого GPU, доступ к отдельному каталогу, способность работать с mapped-файлами или специальным инструментом.

Flow-плагин Tags: Worker Type способен вернуть элемент в Staging, если текущий воркер не соответствует требуемому CPU/GPU-типу и набору Node Tags. Tags: Requeue позволяет сформировать собственные требования к следующему запуску. Так один и тот же Flow может, например, отдать тяжёлое кодирование GPU-узлу, а финальную файловую операцию — mapped-узлу с доступом к исходной директории.

Mapped и Unmapped Nodes

Mapped Node — стандартный вариант. Он должен видеть те же Source и Transcode Cache, что и Server, напрямую либо через сетевые шары и Path Translators. Это наиболее предсказуемая схема для замены оригиналов, перемещения сопутствующих файлов и других операций с файловой системой, потому что сервер и узел оперируют одними и теми же данными.

Unmapped Node предназначен для ситуации, когда дать удалённой машине общий файловый путь неудобно. Такой узел может получать рабочий файл через механизм Tdarr и возвращать результат, но для операций вне текущего working file есть ограничения. В частности, действия вроде Replace Original File и другие шаги, затрагивающие серверную файловую систему, разумно выполнять на mapped-узле. В Flow это делается сменой типа Worker через теги.

Для unmapped-схемы особенно важно учитывать объём передаваемых данных. Даже если вычислительная машина значительно быстрее, копирование многогигабайтного исходника по медленной сети, затем обратная передача результата и повторный health check могут свести преимущество на нет. Quick и Thorough health check на unmapped-Node также требуют передачи файла узлу для анализа.

Path Translators: как связать разные пути

Path Translators нужны, когда Server и Node обращаются к одному физическому ресурсу по разным строкам пути. Типичный пример — Linux-сервер видит библиотеку как /media, а Windows-Node монтирует ту же сетевую папку как W:/media. Переводчик заменяет серверную часть пути на узловую перед запуском задания и выполняет обратное преобразование для созданного в кэше файла.

Сопоставление нужно сделать и для Source, и для Transcode Cache. Частая ошибка — перевести только библиотеку: Node успешно читает оригинал, но не может создать или вернуть cache file. Вторая типичная ошибка — сопоставить визуально похожие папки, которые на самом деле находятся на разных физических ресурсах. И Server, и Node должны видеть одни и те же данные, а не две независимые копии с одинаковой структурой.

• Проверяйте путь к исходнику на Server и на Node отдельно.
• Проверяйте права чтения и записи в Cache с учётной записью, под которой реально работает процесс.
• Для сетевых шар используйте постоянное монтирование; временная пользовательская буква диска в Windows-службе может быть недоступна.
• После изменения переводчиков тестируйте один небольшой файл до массовой очереди.

CPU и GPU: выбор стратегии

CPU-кодирование обычно даёт больше свободы в выборе кодека и параметров и нередко позволяет получить лучшее соотношение качество/размер при сопоставимой визуальной цели, но требует значительно больше процессорного времени. GPU-кодирование полезно, когда приоритетом являются пропускная способность, быстрое приведение большой библиотеки к совместимому формату или использование простаивающего аппаратного блока.

В Tdarr аппаратный путь определяется не только типом Worker. Сама команда должна содержать соответствующий энкодер или аппаратные параметры. GPU-воркер не превращает обычный libx265 в NVENC автоматически. И наоборот, CPU-воркер не должен брать команду с hevc_nvenc или другой явно аппаратной веткой. Поэтому при смешанном парке машин правила нужно строить так, чтобы каждая ветка имела подходящий fallback или отдельный маршрут.

Flow-плагин Set Video Encoder умеет задать выходной кодек, preset, качество, аппаратное кодирование, тип оборудования, аппаратное декодирование и Force Encoding. Force Encoding следует включать только осознанно: если файл уже находится в целевом кодеке, повторное сжатие обычно ухудшит качество и потратит время без необходимости.

NVENC, QSV, VAAPI и другие аппаратные пути

На практике Tdarr опирается на возможности установленного FFmpeg и доступного драйвера. NVIDIA обычно используется через NVENC/NVDEC, Intel — через Quick Sync Video, на Linux распространён VAAPI, а другие платформы могут предоставлять собственные аппаратные интерфейсы. Наличие GPU в системе ещё не гарантирует поддержку конкретного профиля, глубины цвета или кодека.

Перед созданием массового Flow стоит проверить одну короткую команду на том же Node. Если FFmpeg не видит энкодер, Tdarr не сможет исправить это на уровне очереди. Для контейнерных развёртываний дополнительно требуется проброс устройства и соответствующий runtime/драйвер. Ошибки вида no CUDA-capable device, unknown encoder или отказ инициализации QSV/VAAPI нужно решать на уровне доступа FFmpeg к оборудованию.

Аппаратное декодирование и аппаратное кодирование — независимые этапы. Можно кодировать на GPU, но декодировать на CPU; это иногда помогает с редкими форматами или неподдерживаемой глубиной цвета. Обратная комбинация встречается реже, но технически также возможна. В сложном Flow лучше явно понимать, где выполняется каждый этап, чем полагаться на слово GPU как на единый режим.

Classic Plugins

Classic Plugins — JavaScript-модули, которые задают фильтры и команды обработки. Community-плагины загружаются из общего репозитория, Local хранятся в локальной папке пользователя. Стек выполняется по порядку, а файл после изменения может снова пройти через ту же последовательность. Поэтому приоритет плагинов влияет не только на результат, но и на то, сколько промежуточных циклов потребуется.

Классический плагин может относиться к pre-processing или post-processing. Pre-processing решает, нужно ли обрабатывать файл и с какими аргументами. Filter способен остановить дальнейшее прохождение стека, если условие не выполнено. Post-processing применяется после основной операции и подходит для действий, которые должны выполняться уже над полученным результатом.

Сильная сторона Classic Plugin Stack — большое количество готовых задач: фильтрация по кодеку или свойству, remux, удаление лишних дорожек, аппаратные схемы HEVC, работа с метаданными. Ограничение — линейная модель и зависимость от конкретной реализации плагина. Перед массовым использованием Community-плагина нужно читать его Inputs и описание: два плагина с похожими названиями могут по-разному трактовать битрейт, языки и условия повторного запуска.

Порядок плагинов

Порядок особенно важен, когда один шаг меняет свойства, на которые опирается следующий. Если сначала remux перевести файл в MP4, а затем плагин попытается сохранить неподдерживаемый поток, обработка может завершиться ошибкой. Если сначала удалить или преобразовать несовместимые потоки и только потом сменить контейнер, тот же сценарий становится корректным.

Практическая последовательность часто выглядит так: сначала фильтры и быстрые проверки, затем операции над потоками, после них собственно видеотранскодирование, потом remux/контейнер и финальные проверки. Это не универсальное правило, но оно уменьшает вероятность дорого перекодировать файл, который позже будет отброшен простым условием.

Flows: визуальная логика обработки

Flows дают более выразительный способ описать обработку. Каждый блок имеет один вход и один или несколько выходов. Выходы могут означать условие выполнено/не выполнено, успех/ошибка, файл существует/не существует и другие ветки. Благодаря этому можно строить логические деревья: например, кодировать HEVC только H.264-файлы выше определённого разрешения, отдельно обрабатывать HDR, иначе пропускать видеопоток без изменения.

Flow начинается с Input File. У него есть проверки доступа к входному файлу и кэшу, а также возможность поставить Node на паузу, если проверки не проходят. Такой старт удобен для распределённой среды: ошибка монтирования обнаруживается до длинного encode, а не после часа обработки, когда Node внезапно не может записать результат.

Входные поля Flow Plugins поддерживают templating. Через выражения можно получить путь working file, сведения MediaInfo, FFprobe, пользовательские переменные, свойства библиотеки и другие данные. Глобальные переменные задаются в Tools, библиотечные — в настройках конкретной Library. Это позволяет использовать один Flow для разных библиотек и менять, например, качество или целевой профиль без копирования всего графа.

Working file и original file

Для понимания Flow важно различать original file и working file. Original — исходный элемент библиотеки. Working file — текущий файл, передаваемый от блока к блоку; после транскодирования это уже cache file. Replace Original File заменяет исходник текущим working file, если тот действительно изменился. Set Original File, наоборот, может снова сделать оригинал рабочим объектом.

Файловые блоки позволяют копировать или перемещать данные, проверять наличие файла, вычислять хэш, работать с содержимым соседней папки и очищать временные данные. Это делает Flow пригодным не только для кодирования, но и для сопровождающих операций. Однако чем больше действий затрагивает файловую систему, тем критичнее mapped-доступ и тестирование на отдельной библиотеке.

FFmpeg Command в Flow

Группа ffmpegCommand собирает команду из отдельных блоков. Можно задать видеокодек, контейнер, разрешение, частоту кадров, битрейт, аудиодорожку, порядок потоков, удаление субтитров, custom arguments и другие параметры. После формирования команды блок Execute запускает её. Такая схема удобнее огромной ручной строки, потому что отдельные решения видны в графе и могут включаться условно.

Set Container меняет контейнер результата и имеет Force Conform для ситуаций, когда не все входные потоки поддерживаются целевой оболочкой. Эта опция требует осторожности: привести к контейнеру может означать удаление или изменение несовместимого потока. Перед использованием на большой библиотеке нужно точно знать, какие типы субтитров, data streams и аудиоформаты встречаются в источниках.

Set Video Bitrate может использовать фиксированное значение либо процент от входного битрейта с fallback, если исходное значение не определено. Такой подход удобен для технической нормализации, но процент битрейта не равен проценту качества: H.264, HEVC и AV1 по-разному используют заданный поток, а сложность сцен существенно отличается. Для постоянного визуального качества предпочтительнее управлять качественным параметром энкодера, если выбранная ветка это позволяет.

Set Video Framerate не поднимает частоту выше исходной: если исходник ниже заданного предела, сохраняется исходная частота. Это защищает от бессмысленного создания дублированных кадров в простом сценарии. Для настоящей интерполяции движения нужны другие инструменты; Tdarr сам по себе не превращает обычный лимит FPS в генерацию промежуточных кадров.

Аудиодорожки, субтитры и порядок потоков

Медиатека часто требует нормализации не только видео. Один файл может содержать основную дорожку, комментарии, несколько дубляжей, lossless-аудио, стерео-совместимую копию, текстовые и графические субтитры, вложенные изображения и служебные data streams. Tdarr получает подробности через FFprobe, MediaInfo и другие анализаторы и может использовать эти сведения в фильтрах и Flow.

Ensure Audio Stream проверяет наличие аудиодорожки с заданными кодеком, языком и количеством каналов и при необходимости создаёт подходящий поток. Это удобно для медиасервера, которому нужен, например, стерео AAC fallback рядом с многоканальной дорожкой. При этом важно не путать добавить совместимую дорожку и заменить всё аудио: сохранение оригинального трека может быть желательным для качества, а дополнительный поток решает вопрос совместимости устройств.

Reorder Streams позволяет упорядочить потоки по кодекам, каналам, языкам и типам. Сам порядок полей тоже имеет значение: плагин последовательно применяет критерии, поэтому наиболее важный параметр следует располагать там, где он получит нужный приоритет. Такая перестановка не улучшает качество, но может сделать поведение проигрывателей и медиасерверов предсказуемее.

Remove Subtitles удаляет субтитровые потоки из рабочего файла. Использовать его на всякий случай не стоит: принудительное удаление всех субтитров необратимо после замены оригинала. Если задача состоит только в повышении Direct Play, лучше сначала определить, какие типы субтитров действительно вызывают транскодирование на целевых клиентах, и удалить или вынести только их.

Языки и тегирование

Языковой тег потока не всегда надёжен. В старых или плохо размеченных файлах дорожки могут иметь und, отсутствующий язык или неверное значение. Поэтому правило оставить только русский и английский следует сначала проверить поиском по реальной библиотеке. Если часть ценных дорожек не имеет корректного тега, жёсткий фильтр способен удалить их как неподходящие.

То же относится к default и forced-флагам субтитров и аудио. Контейнер может содержать несколько потоков с одинаковым языком, но разными ролями. Для сложной коллекции полезнее строить правила по нескольким признакам: язык, codec, channels, title и disposition. Tdarr предоставляет подробные структуры FFprobe/MediaInfo, поэтому Flow или собственный плагин может принимать решение гораздо точнее, чем простое сравнение расширения файла.

Health Check: проверка целостности

Health Check в Tdarr не заменяет резервное копирование, но помогает автоматически находить файлы, которые не удаётся нормально прочитать. Есть два основных режима. Quick использует HandBrake для проверки заголовков и доступен CPU-воркерам. Thorough проходит файл кадр за кадром через FFmpeg и способен обнаружить ошибки, проявляющиеся только глубже в потоке.

Режим	Что проверяет	Нагрузка	Когда использовать
Quick	Структуру и заголовки, без полного прохода	Низкая	Регулярная быстрая проверка большой библиотеки
Thorough CPU	Полный проход по файлу через FFmpeg	Высокая по времени и чтению	Архивы, подозрительные файлы, контроль после миграции
Thorough GPU	Полный проход с аппаратным декодированием, если оно поддерживается	Меньше CPU, но зависит от GPU и драйвера	Большие объёмы при корректно настроенном ускорителе

Полный health check интенсивно читает хранилище. Если одновременно запустить несколько проверок и несколько транскодов на одном массиве HDD, скорость всех задач может ухудшиться. Расписания позволяют развести эти операции: например, ночью выполнять Thorough, а в часы активного просмотра разрешать только лёгкие задачи или вообще останавливать библиотеку.

Результат Health Check нужно интерпретировать вместе с Job Report. Ошибка чтения не всегда означает физически испорченный файл: причиной может быть временно недоступная шара, сбой аппаратного декодера, права доступа или проблема конкретной сборки FFmpeg. Прежде чем удалять медиа как битое, стоит повторить проверку на CPU и убедиться, что файл действительно не декодируется.

Расписание библиотеки

Для каждой Library можно задать недельное 24-часовое расписание. Оно определяет, когда воркерам разрешено брать задания этой библиотеки. Это полезно на домашнем сервере: тяжёлое кодирование можно оставить на ночь, а днём освободить CPU, GPU и диски для Plex, Jellyfin, монтажа или резервного копирования.

Расписание работает совместно с Process Library. Если библиотека отключена, разрешённые часы сами по себе не запустят обработку. Если расписание закрыто, воркер может оставаться активным, но не получит элементы этой библиотеки. В диагностике почему очередь не движется это один из первых пунктов после проверки наличия Node.

При нескольких библиотеках расписания могут быть разными. Например, небольшую коллекцию новых загрузок можно обрабатывать сразу, а архивный массовый HEVC-переход запускать только ночью. Такой подход эффективнее глобального выключения всех воркеров и помогает сохранить предсказуемое время реакции на свежие файлы.

Search: инспекция и выборочная работа

Search позволяет проверить, что Tdarr фактически знает о файлах. Для каждого элемента доступны технические свойства: контейнер, видео- и аудиокодеки, разрешение, размер, битрейт, продолжительность, потоки и другие извлечённые данные. Поиск особенно полезен до создания правила: сначала можно выяснить, сколько файлов действительно H.264, какие контейнеры встречаются и есть ли неожиданные 10-/12-битные или interlaced-источники.

Свойства из Search помогают отлаживать условия. Если Flow проверяет video_codec_name, а конкретный файл не попадает в нужную ветку, следует открыть его объект и посмотреть фактическое значение. Аналогично с языками и контейнерами: реальная метаинформация важнее предположений, основанных на названии файла.

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

Stats и аналитика библиотеки

Stats агрегирует состояние библиотек и показывает распределение по кодекам, контейнерам, разрешениям и результатам обработки. Такие диаграммы полезны как контроль политики. Если после проекта по переходу на HEVC доля H.264 перестала снижаться, это сигнал открыть Search и выяснить, какие файлы блокируются условиями, ошибками или неподходящими воркерами.

Показатель Space saved следует рассматривать как операционную статистику, а не как гарантию качества. Сильное уменьшение размера может быть как желаемым результатом эффективного кодека, так и следствием слишком агрессивного качества. Поэтому итоговую политику нужно оценивать на репрезентативных примерах до массового запуска, а Stats использовать для контроля масштаба выполненной работы.

Диаграммы также помогают обнаружить хвосты — небольшие группы редких контейнеров и кодеков, которые обычное правило не затрагивает. Не обязательно приводить их к общему виду любой ценой. Иногда редкий формат — это единственный корректный способ сохранить определённый тип дорожки, и его разумнее оставить исключением.

Job Reports и журналы

Job Report — главный инструмент разбирательства с конкретным файлом. Он показывает последовательность шагов, выбранный Node и Worker, решения плагинов, сформированные команды, возвраты из subworker и вывод FFmpeg или HandBrake. История отчётов хранит записи и для transcode, и для health check, поэтому при повторных попытках важно открыть именно тот запуск, который соответствует ошибке.

Отчёт можно открыть из активного Worker, Staging, статусных таблиц и Search. По умолчанию вывод FFmpeg/HandBrake сокращён, чтобы отчёты не разрастались. Если проблема появляется только в середине длинной команды, в Staging можно включить полный лог вывода и повторить один тестовый файл.

Серверные и узловые Logs отвечают на другой круг вопросов. Если Node вообще не подключается, Job Report ещё не существует, поэтому нужно смотреть сетевое соединение, конфигурацию serverURL, API key и лог Node. Если интерфейс работает, но очередь не выдаётся воркеру, полезны и серверный лог, и состояние расписания/тегов.

Как читать ошибку FFmpeg

Начинать следует с самой первой содержательной ошибки, а не с финального Conversion failed. Например, сообщение о неподдерживаемом пиксельном формате указывает на несовместимость энкодера; Permission denied — на файловые права; No such file or directory — на путь или переводчик; Unknown encoder — на возможности конкретного FFmpeg; Invalid argument при muxing часто означает несовместимый поток или параметр контейнера.

Далее нужно сравнить фактическую команду с предположениями в Flow. Если ожидался hevc_nvenc, а запускается libx265, проблема в ветке или настройке энкодера, а не в GPU. Если input path верный, но output path ведёт в несуществующий кэш, проверяется библиотечный Cache и права. Такой пошаговый подход быстрее случайного переключения параметров.

Аутентификация и API-ключи

Если интерфейс или сервер доступен из сети, целесообразно включить Authentication. После активации Tdarr предлагает создать учётные данные для WebUI. Nodes при этом должны использовать API key, созданный в Tools. Без подходящего ключа узел не подключится, даже если адрес и порт корректны.

Для автоматизированного развёртывания ключ можно подготовить через соответствующую переменную среды при выполнении требований к формату. Это удобнее ручной настройки большого числа Nodes, но секрет всё равно следует хранить как credential, а не помещать в общедоступный compose-файл или скриншот.

Особое внимание требуется при включении unmapped Nodes: в этой конфигурации данные библиотек и кэша участвуют в сетевом обмене Tdarr. Документация прямо рекомендует использовать аутентификацию. Сам факт, что WebUI предназначен для домашней сети, не делает открытый порт безопасным для публикации напрямую в интернет.

Практический сценарий: H.264 в HEVC

Самый распространённый сценарий — сокращение объёма H.264-библиотеки с переходом на HEVC. Правильная политика начинается с фильтра: HEVC-файлы не должны перекодироваться повторно. Затем выбирается энкодер — программный x265 либо аппаратный вариант — и качество. После этого решается судьба аудио и субтитров: их можно копировать без изменений, нормализовать или удалить выборочно.

Для первой настройки лучше создать отдельную тестовую Library с несколькими типичными файлами: быстрые сцены, тёмные эпизоды, анимация, 720p/1080p/4K, разные аудиодорожки. На них проверяют визуальный результат, поддержку клиентами, изменение размера и время. Лишь после этого те же правила применяются к основной коллекции.

1. Отфильтровать видео, которые уже находятся в HEVC, чтобы избежать повторного encode.
2. Задать целевой encoder и quality/preset, соответствующие CPU или GPU-ветке.
3. Явно определить, копируются ли исходные аудио и субтитры.
4. Выбрать контейнер, способный хранить требуемые потоки.
5. После Encode выполнить проверку размера и, при необходимости, health check.
6. Заменять оригинал только после успешного завершения всех критических шагов.

Не стоит ожидать одинакового процента экономии от каждого файла. Уже эффективно сжатый источник, зернистое видео или низкий исходный битрейт могут уменьшиться совсем немного. Если результат оказывается больше оригинала, Flow может проверить размер и отказаться от замены. Это полезнее, чем принимать каждый успешный encode автоматически.

Практический сценарий: повышение Direct Play

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

Такой Flow необязательно перекодирует видео. Если видеопоток уже совместим, достаточно remux и работы с аудио. Например, сохранение основной многоканальной дорожки плюс добавление стерео AAC может решить больше проблем, чем повторный H.264 encode. Аналогично, смена MKV на MP4 имеет смысл только если клиенту действительно нужен MP4 и все необходимые потоки совместимы.

Direct Play зависит от конкретного медиасервера, приложения, устройства, контейнера, профиля кодека, уровня, битности, аудио и субтитров. Поэтому универсального плагина Direct Play для всех устройств нет. Tdarr даёт механизм реализации политики, но требования нужно взять из реальной клиентской среды.

Практический сценарий: очистка аудио и субтитров

В больших коллекциях лишние дорожки могут занимать заметный объём, особенно если в каждом фильме сохранено несколько lossless-аудиотреков и дубляжей. Tdarr позволяет оставить выбранные языки, preferred codec или количество каналов, удалить комментарии по названию и переставить основную дорожку первой. Однако это один из самых рискованных классов автоматизации, потому что потерянный поток нельзя восстановить без резервной копии.

Перед массовой очисткой стоит выполнить аналитический проход: найти через Search файлы с большим числом streams, посмотреть реальные language/title tags и определить исключения. Для сериалов и аниме особенно часто встречаются forced subtitles, signs/songs и альтернативные дорожки, которые нельзя оценивать только по языку.

Безопасный Flow сначала работает в кэше, затем проверяет, что видео- и обязательные аудиопотоки присутствуют, и только после этого заменяет оригинал. При сложных условиях собственный Flow или кастомный plugin обычно надёжнее единственного удалить всё кроме X.

Практический сценарий: проверка архива после переноса

После миграции большого массива на новый NAS Tdarr можно использовать как систематический health-checker. Библиотека сканируется без изменения кодеков, а воркеры выполняют Thorough health check по расписанию. Ошибочные элементы остаются в соответствующем статусе и получают Job Report, по которому можно отличить повреждение от сетевого сбоя.

Чтобы проверка не конкурировала с обычным просмотром, её удобно назначить на ночные часы и ограничить число Health Check Workers. Если сервер и медиа находятся на HDD-массиве, один или два последовательных читателя часто дают более стабильную производительность, чем большое число случайных параллельных проходов.

Повторный контроль на другом Node полезен для спорных случаев. Если GPU Thorough падает, а CPU Thorough успешно проходит тот же файл, это указывает на декодер/драйвер, а не обязательно на повреждение медиаданных. Если оба способа стабильно останавливаются на одном и том же месте, вероятность реальной проблемы выше.

Практический сценарий: несколько машин

При наличии нескольких компьютеров Tdarr может превратить их в общий пул. На сервере остаются библиотеки и очереди, а Nodes получают задания по мере доступности. Для mapped-схемы все машины должны иметь доступ к одним и тем же данным. В смешанной ОС Path Translators преобразуют пути; для специализированных задач Node Tags ограничивают маршрутизацию.

Например, узел с Intel iGPU получает тег qsv, машина с NVIDIA — nvenc, а сервер без GPU — только CPU. Flow может сначала отправить H.264 1080p на любой быстрый GPU, но редкие 10-/12-битные источники или неподдерживаемые профили направить CPU-ветке. Финальную Replace Original File выполняет mapped-Node, который гарантированно видит исходник.

Увеличение количества машин не означает линейного роста скорости. Общий NAS, 1-Gbit Ethernet или один SSD-кэш могут стать узким местом. Важно смотреть не только на FPS энкодера, но и на очередь I/O: если GPU простаивает между чтением блоков или сеть загружена полностью, добавлять Workers бессмысленно.

Качество, CRF, QP и битрейт

Tdarr не вводит собственную модель качества поверх FFmpeg и HandBrake: результат определяется выбранным энкодером и его параметрами. Для software encoders часто используют постоянное качество, например CRF, а аппаратные реализации могут применять QP, CQ или собственные quality-параметры. Одинаковое числовое значение между разными энкодерами нельзя считать эквивалентным.

Preset регулирует в первую очередь соотношение скорости кодирования и эффективности сжатия. Более медленный preset обычно тратит больше вычислений на поиск лучшего представления при той же целевой метрике качества, но конкретный эффект зависит от кодека. Для массовой библиотеки самый медленный режим не всегда рационален: выигрыш в размере может не оправдать многократный рост времени.

Фиксированный bitrate нужен, когда размер или пропускная способность должны быть предсказуемыми. Для архива с разной сложностью сцен постоянное качество часто естественнее: простой материал получит меньше битов, сложный — больше. Если Flow использует процент от исходного bitrate, это скорее техническое правило бюджета, а не универсальная гарантия визуального качества.

Особое внимание требуется HDR, 10-bit и цветовым метаданным. Не каждый hardware encoder поддерживает нужную глубину и не каждый Flow сохраняет HDR-параметры автоматически при сложной обработке. Если исходники HDR ценны, нужно отдельно проверить color_primaries, transfer_characteristics, matrix_coefficients и поведение целевого контейнера/клиента.

Как избежать повторного перекодирования

Повторный encode — одна из самых дорогих ошибок политики. Каждый lossy-проход дополнительно теряет информацию, а Tdarr может выполнять его автоматически на тысячах файлов. Условие должно проверять конечное состояние до запуска дорогого шага: целевой видеокодек, контейнер, разрешение, наличие требуемой аудиодорожки и другие признаки.

В простых Audio/Video rules документация прямо советует указывать кодеки, которые не нужно транскодировать. Во Flow аналогичная логика строится явными проверками: если уже HEVC — перейти к следующему шагу, если контейнер уже MKV — не remux, если AAC stereo уже есть — не добавлять второй такой поток.

Ещё один источник циклов — несоответствие между условием и результатом. Например, Flow считает, что требуется язык eng, а новый поток создаётся без language tag. На следующем проходе проверка снова не находит eng и повторяет действие. Поэтому финальные свойства нужно проверять на фактическом output, а не только предполагать, что FFmpeg поставит нужные метаданные.

Размер результата и автоматическое принятие

Успешное завершение FFmpeg означает лишь то, что команда отработала без фатальной ошибки. Это не гарантирует, что новый файл меньше, качественнее или полезнее оригинала. Если задача — экономия места, логично проверять old/new size или ratio до финальной замены. Неэффективный результат можно отправить в ошибку, отклонить или вернуть оригинал в зависимости от Flow.

Автоматическое принятие всех успешных транскодов удобно после отладки, но на этапе построения политики лучше наблюдать Staging и отчёты. Особенно это касается новых GPU-настроек, AV1, изменения bit depth и сложного аудио. Несколько десятков проверенных примеров дешевле, чем повторное восстановление многотерабайтной коллекции.

Форматы и контейнеры: чего ожидать

Фактический набор декодеров и энкодеров определяется FFmpeg/HandBrake на Node, поэтому Tdarr не имеет закрытого списка поддерживаемых видеоформатов в бытовом смысле. Контейнерный фильтр библиотеки задаёт, что сканировать, а plugins/flows решают, что делать с найденными потоками. Для распространённых медиатек это обычно MKV, MP4, MOV, M4V, TS/M2TS и различные аудиоформаты, но редкие комбинации следует тестировать отдельно.

MKV гибок по типам потоков и поэтому часто удобен для архивных библиотек. MP4 лучше поддерживается рядом устройств, но не принимает некоторые типы субтитров и data streams. Force Conform помогает привести файл к ограничениям контейнера, однако это именно изменение состава, а не волшебная совместимость. Пользователь должен понимать, что будет удалено или преобразовано.

Remux не исправляет несовместимый кодек сам по себе. Если устройство не декодирует HEVC, перенос HEVC из MKV в MP4 не решит проблему. И наоборот, если устройство понимает H.264/AAC, но не конкретный контейнер, remux может быть достаточным и намного быстрее полного transcode.

Ошибки доступа к файлам и прав

Большая доля проблем Tdarr связана не с кодированием, а с файловой системой. Node может видеть папку, но не иметь права создать cache file; сервер может читать кэш, но не иметь права заменить оригинал; Docker-контейнер может использовать другой UID/GID; сетевой путь может быть смонтирован только для интерактивного пользователя.

Симптом	Вероятная причина	Что проверить
Input File access check failed	Node не видит Source или Cache	Монтирование, Path Translators, UID/GID, read/write
Permission denied при output	Нет записи в кэш/каталог	Права каталога от имени процесса Node
No such file or directory	Неверный путь на конкретной машине	Переводчик server→node и фактический mount
Файл кодируется, но не заменяется	Server не видит cache result или нет прав на Source	Обратный путь к кэшу, mapped-доступ, Replace Original File
Folder watcher не видит новые файлы	Сетевая ФС не передаёт события	Почасовой Scan (Find new), интервал watcher

Самый надёжный тест — выполнить чтение и запись от того же пользователя и в том же окружении, где запущен Tdarr Node. Успех через файловый менеджер администратора не доказывает, что контейнер или служба имеет те же права.

Node не подключается к Server

По умолчанию WebUI и серверный API/канал Nodes используют разные порты. Интерфейс работает на 8265, а Server — на 8266, если значения не изменены. Ситуация в браузере вижу Tdarr_Server, но не интерфейс обычно означает, что открыт порт сервера, а не WebUI.

Если Node пишет, что Server not alive, нужно проверить serverURL и доступность 8266 с той машины, где работает Node. Для удалённого узла localhost указывает на сам Node, а не на Tdarr Server. 0.0.0.0 применяется для bind, но не является универсальным адресом назначения для соединения.

Node инициирует исходящее соединение к Server; отдельный входящий порт Node для обычной схемы не требуется. Firewall, reverse proxy и сетевые политики должны пропускать устойчивое Socket.IO-соединение или HTTP polling. Если Authentication включена, дополнительно проверяется API key.

Проблемы GPU

Ошибка GPU сначала разделяется на три уровня: устройство не передано процессу; FFmpeg не содержит нужного энкодера; конкретный файл/профиль не поддерживается аппаратным блоком. Tdarr лишь запускает команду и не может компенсировать отсутствие драйвера или энкодера.

CUDA_ERROR_NO_DEVICE указывает на то, что CUDA/NVIDIA-устройство недоступно процессу. Unknown encoder означает, что текущая сборка FFmpeg не знает указанного энкодера. Сообщения о неподдерживаемом 10-bit или профиле показывают, что устройство найдено, но не умеет требуемую конфигурацию.

Для Docker нужно проверять проброс GPU и устройства, а не только переменные Tdarr. На Intel/AMD Linux распространён доступ через /dev/dri; NVIDIA требует корректного контейнерного runtime/toolkit. После изменения среды полезно выполнить минимальный encode на самом Node, а затем возвращаться к Flow.

Файл завис в Staging

Staging сам по себе не является ошибкой. Flow может намеренно вернуть задание туда, чтобы его забрал Worker с другим типом или тегом. Проблема возникает, если подходящего воркера никогда не появится. В этом случае Job Report обычно показывает требование requireCPU, requireGPU или кастомный тег.

Проверьте четыре вещи: включён ли нужный Worker; совпадают ли Node Tags; разрешено ли расписание библиотеки; не превышен ли Staged file limit. Если всё выглядит корректно, откройте последний отчёт и найдите шаг, который сделал Requeue. Иногда условие Flow постоянно отправляет файл с GPU на CPU и обратно из-за несовместимых требований.

Почему файл кодируется снова и снова

Если один и тот же элемент постоянно возвращается в очередь, почти всегда конечный файл не удовлетворяет условию, которое запускает действие. Возможные причины: целевой codec не исключён; контейнер после remux не тот, который проверяет фильтр; языковой tag не записан; plugin использует свойство, которое не обновилось ожидаемым образом; output снова попадает в Source как новый файл.

Сначала откройте Search и сравните свойства до/после, затем Job Report. Не исправляйте проблему увеличением Hold или отключением watcher — это может лишь замедлить цикл. Правильное решение делает Flow идемпотентным: повторный запуск над успешным результатом должен быстро пройти без изменений.

Ошибка контейнера или muxing

Если encode завершился, но FFmpeg падает на финальном muxing, проверьте совместимость всех потоков с целевым контейнером. Частая причина — субтитры или data stream, которые нельзя просто скопировать в MP4/MKV в выбранной комбинации. Set Container с Force Conform способен автоматически подстроить состав, но использовать его стоит только после понимания последствий.

В сложной политике лучше явно решить судьбу каждого типа: видео copy/encode, аудио copy/convert, субтитры keep/convert/remove, attachments/data keep/remove. Тогда ошибка контейнера становится предсказуемым исключением, а не случайностью на тысячном файле.

FFmpeg или HandBrake

Tdarr умеет использовать оба инструмента. HandBrake удобен готовыми пресетами и понятными аргументами для типового encode; FFmpeg предоставляет более прямой контроль над потоками, фильтрами, hardware acceleration и muxing. Выбор зависит от задачи и существующей экспертизы, а не от того, что один из инструментов всегда лучше.

В простых правилах FFmpeg разделяет input и output arguments маркером <io>. Это важно, потому что некоторые опции должны стоять до -i, а другие — после. В Flow-конструкторе Custom Arguments разделены на Input Arguments и Output Arguments явно, что уменьшает риск поставить параметр не в ту часть команды.

HandBrake Preset JSON, если он используется на нескольких Nodes, должен быть доступен каждому узлу. Path Translators применимы и к пути такого preset-файла. Сама ссылка на preset на Server бесполезна, если Node не может открыть тот же файл по преобразованному пути.

Простые Audio/Video rules

Для базовой задачи необязательно сразу строить большой Flow. Simple Video/Audio rules позволяют задать контейнер, CLI tool, arguments, фильтр кодеков, диапазон размера и геометрии. Такой режим подходит, когда правило линейное: например, все H.264 1080p в определённом диапазоне размеров перекодировать в HEVC.

Его слабое место — сложные исключения. Как только появляются отдельные ветки для HDR, аудио, контейнеров, нескольких GPU, проверок размера и финального health check, Flow становится понятнее и безопаснее. Простое поле аргументов не должно превращаться в нечитаемую команду с десятками условий, которые сам Tdarr не видит как отдельные решения.

Собственные плагины и переменные

Если готовых действий недостаточно, Classic Plugins можно изменять или создавать на JavaScript, а Flow Plugins пишутся на TypeScript/JavaScript. Это даёт почти полный контроль над логикой, но переносит ответственность за корректность на автора. В собственном коде особенно важно обрабатывать неожиданные значения метаданных и всегда иметь условие завершения.

Глобальные и библиотечные переменные помогают не клонировать Flow. Например, одна Library может иметь quality=20, другая quality=24, а блок Custom Arguments подставит нужное значение. Аналогично можно хранить язык, целевой контейнер, максимальный размер или адрес внешнего webhook.

Секреты лучше хранить в предназначенных для этого переменных/настройках и не выводить в Job Report без необходимости. Templating способен подставлять значения в запросы и команды, поэтому ошибочно сформированный лог может раскрыть API key так же легко, как обычный shell script.

Automations в Flows

Tdarr поддерживает автоматизированный запуск Flow по cron для задач, которые не привязаны к обычному появлению медиаданного файла. Для каждой комбинации выбранной библиотеки и Node создаётся отдельная automation job, которая использует существующую систему Flow и Job Report. Сценарий может запускаться по расписанию или при старте сервера.

Automations помечены как экспериментальная возможность, поэтому критические операции с файлами стоит строить консервативно. Входом служит временный dummy-файл в служебной папке библиотеки, а payload позволяет передать дополнительные параметры. Есть опции немедленного запуска и обхода обычных worker limits, которые следует использовать осознанно, чтобы automation не вытеснила основное транскодирование.

Производительность и масштабирование

Оптимальное число Workers определяется всей цепочкой: декодирование, фильтры, энкодер, диски, сеть и кэш. Документация приводит примерно три воркера как типичную отправную точку, но это не норматив. На слабом CPU эффективнее один тяжелый x265; на современном GPU могут быть полезны несколько параллельных сессий; на HDD-массиве лишние воркеры могут только увеличить seek.

Наблюдать нужно не только загрузку CPU/GPU. Если GPU держится на 20%, а NAS показывает максимальную сеть или диск, проблема находится до энкодера. Если кэш заполнен, новые задания будут падать независимо от числа Nodes. Если один файл использует все CPU threads, второй воркер может не дать прироста.

Большая библиотека также создаёт нагрузку при сканировании. Scanner threads стоит увеличивать только там, где носитель способен обслужить параллельное чтение метаданных. Для миллионов файлов индексация сама становится отдельной задачей, поэтому её лучше не совмещать с массовым encode в момент первичной настройки.

Load balancing между библиотеками и дисками

Tdarr может распределять работу между библиотеками и узлами, но физическую топологию всё равно следует учитывать. Если две Library находятся на разных дисках, параллельный worker на каждой способен дать больше, чем два воркера, конкурирующие за один HDD. Теги и расписания позволяют приблизить программную очередь к реальной архитектуре хранения.

Безопасность оригиналов

Главный риск любой автоматической медиаконвертации — не ошибка качества, а массовое необратимое изменение оригиналов. Tdarr рассчитан на замену файлов после успешной обработки, поэтому резервная копия и тестовая Library являются частью разумного процесса, а не дополнительной осторожностью.

Если оригиналы особенно ценны, Source можно временно предоставить только на чтение и настроить Flow, который пишет результат в другую структуру. Однако все используемые блоки должны соответствовать такой модели: Replace Original File закономерно не сможет работать с read-only источником. В этом сценарии копирование/перемещение результата следует описать явно.

Перед включением Auto accept успешных transcodes полезно проверить: сохраняются ли нужные потоки; остаются ли chapter/metadata, которые вам нужны; совпадает ли длительность; корректен ли seek; не меняется ли HDR/цвет; действительно ли новый размер приемлем. После подтверждения на репрезентативной выборке автоматизация становится оправданной.

Резервное восстановление и откат

Tdarr не следует рассматривать как систему версионирования медиа. Кэш временный, а успешная замена оригинала не создаёт долгосрочный rollback сама по себе. Если возможность отката обязательна, её нужно обеспечить на уровне файловой системы, snapshots, backup или отдельной выходной библиотеки.

Для NAS со snapshot-механизмом удобно сделать снимок перед изменением крупной коллекции и держать его до выборочной проверки. Это особенно важно при массовом удалении потоков: качество видео можно оценить визуально, а отсутствие редкой forced-субтитровой дорожки иногда обнаруживается только спустя недели.

Интеграция с Sonarr, Radarr и медиасерверами

Tdarr часто работает рядом с Sonarr/Radarr, но его роль отличается. Sonarr и Radarr управляют поиском, именованием и библиотекой эпизодов/фильмов, а Tdarr приводит сами файлы к технической политике. Folder watcher или периодический scan позволяет подхватывать новые элементы после импорта.

Чтобы две системы не боролись за один файл, Hold after scanning даёт время завершить перемещение и переименование. Если Sonarr/Radarr ещё выполняет import, а Tdarr уже пытается заменить файл, возможны конфликты. В сложной инфраструктуре полезно определиться, какая система последняя меняет имя и расположение.

Plex, Jellyfin и Emby не управляются Tdarr напрямую в основном рабочем цикле. Их требования используются как цель политики совместимости. После замены файла медиасервер обычно обнаруживает изменение своим механизмом сканирования; конкретное поведение зависит от его настроек.

Что проверять перед запуском на всей медиатеке

• Source и Transcode Cache физически доступны Server и всем mapped Nodes.
• Path Translators проверены в обе стороны на реальном файле.
• У каждого Node есть подходящий FFmpeg/HandBrake и доступ к GPU, если он нужен.
• Flow или Plugin Stack не перекодирует уже соответствующие файлы.
• Целевой контейнер совместим со всеми сохраняемыми потоками.
• Проверены языковые теги и исключения для субтитров/аудио.
• Свободного места в кэше хватает на параллельные задания.
• Расписание не блокирует тест и не создаёт неожиданную ночную массовую обработку.
• Есть способ восстановить оригиналы после ошибочной политики.
• На нескольких разнородных файлах проверены размер, качество, длительность и воспроизведение.

Типовые неисправности и решения

Проблема	Что обычно означает	Практическое действие
WebUI не открывается, но сервер отвечает	Открыт serverPort вместо webUIPort	Проверить 8265 и опубликованный порт контейнера
Node постоянно регистрируется	Нестабильное соединение, proxy или несовпадение конфигурации	Проверить serverURL, firewall, Socket.IO и логи
Очередь не движется	Нет Worker, закрыто расписание или Process Library OFF	Проверить Library Schedule, Workers и состояние библиотеки
Require CPU/GPU Worker	Flow ждёт другой тип ресурса	Запустить подходящий Worker или исправить Tags/Requeue
Transcode loop	Output не удовлетворяет исходному условию	Сравнить свойства результата и условия фильтра
Output больше input	Параметры не подходят материалу	Добавить size check и настроить quality/preset
GPU out of memory / session error	Слишком много сессий или неподдерживаемый режим	Снизить GPU Workers, проверить ограничения GPU
FFmpeg Unknown encoder	Энкодер отсутствует в сборке FFmpeg	Проверить FFmpeg на конкретном Node
Permission denied	Нет прав на Source/Cache	Исправить UID/GID, ACL или mount options
Новые файлы не обнаруживаются	Folder watcher не получает события	Включить периодический Scan (Find new)
Health check падает только на GPU	Проблема аппаратного декодирования	Повторить Thorough на CPU и сравнить отчёт
Remux падает	Поток несовместим с контейнером	Изменить/удалить несовместимый stream или контейнер

Как Tdarr получает свойства файла

Условия Tdarr опираются не на имя файла, а на технические данные, извлечённые при сканировании. В объекте элемента объединяются сведения FFprobe, MediaInfo и ExifTool. Поэтому в правилах доступны не только верхнеуровневые поля вроде container, video_resolution и video_codec_name, но и детальная структура streams: codec_name, profile, width, height, pix_fmt, frame rate, цветовые характеристики, channels, language, disposition и другие значения.

Это особенно важно для неоднородной коллекции. Два файла с расширением MKV могут радикально отличаться: один содержит H.264 8-bit и AAC stereo, другой — HEVC 10-bit, TrueHD, PGS-субтитры и вложенные изображения. Политика по расширению не различит их, тогда как Flow может проверить свойства каждого потока и выбрать отдельную ветку.

MediaInfo и FFprobe иногда называют одни и те же характеристики по-разному или представляют их на разных уровнях объекта. При создании кастомного plugin сначала стоит открыть конкретный файл в Search и посмотреть фактическую структуру данных. Не следует считать, что поле обязательно присутствует у всех контейнеров: например, bitrate или language может быть пустым, а частота кадров иногда хранится как дробь.

ExifTool полезен для контейнерной и файловой метаинформации, но его данные также зависят от формата. В собственных условиях нужно предусматривать отсутствие значения. Правило, которое сравнивает числовое поле без fallback, может корректно работать на девяти тысячах файлов и неожиданно упасть на одном редком контейнере.

Фильтрация по свойствам

Classic Plugin Filter By File Property умеет сравнивать верхнеуровневое свойство с набором значений и решать, продолжать ли стек. Это удобный способ отсечь неподходящие контейнеры, media type, разрешения или кодеки до дорогого шага. Во Flow ту же идею можно реализовать специализированными проверками или templating.

Хороший фильтр по возможности отвечает на один вопрос. Например: видеокодек не HEVC?, высота больше 1080?, размер больше заданного порога?. Когда несколько независимых критериев скрыты в одной длинной строке custom arguments, отладка становится сложнее, потому что Job Report не показывает, какое именно бизнес-условие привело к выбору ветки.

Для диапазонов учитывайте единицы. Размер может фигурировать в байтах, мегабайтах или гигабайтах в разных контекстах; bitrate — в бит/с или кбит/с; frame rate — как число или дробная строка. Перед массовым запуском полезно проверить граничные значения: файл ровно 1080 строк, ровно минимального размера, пустой bitrate и отсутствующий language tag.

Файловые операции внутри Flow

Flow может делать больше, чем запускать энкодер. Check File Exists проверяет наличие файла по абсолютному или сформированному через templating пути и имеет отдельные выходы существует и не существует. Это позволяет, например, не создавать вторую прокси-копию, если нужный вариант уже лежит в выходном каталоге, или выбрать разные действия для ранее обработанных материалов.

Calculate File Hash вычисляет хэш указанного original или working file и сохраняет значение в переменную. Такой шаг полезен для сценариев, где нужно сравнить два файла или зафиксировать контрольное значение в рамках Flow. Хэш не говорит ничего о визуальном качестве и не заменяет health check: даже идеально читаемый перекодированный файл по определению имеет другой хэш, чем исходник.

Copy/Move Folder Content работает с сопутствующими файлами каталога, исключая текущий original и working file. Это может пригодиться при переносе внешних субтитров, обложек или NFO в новую структуру. Опция сохранения относительного пути помогает повторить иерархию, но любое массовое перемещение следует сначала проверять на тестовом дереве: ошибка в Output Directory затронет не медиапоток, а реальные файлы рядом с ним.

Delete File способен удалить working или original file и при необходимости пустую родительскую папку. Tdarr сам очищает обычные временные cache-файлы после Flow, поэтому добавлять Delete только для уборки кэша не нужно. Если working file удалён вручную, следующий блок должен загрузить валидный файл, например через Set Original File, иначе дальнейшие plugins закономерно завершатся ошибкой.

Replace Original File — точка, после которой тестовый сценарий становится изменением медиатеки. Удобно проектировать Flow так, чтобы все проверки качества, размера, потоков и здоровья находились до неё. Тогда одна финальная операция выполняется только после прохождения всех предохранителей.

Как проектировать Flow, который легко отлаживать

Большой граф лучше строить слоями. Первый слой подтверждает доступ к файлу и классифицирует вход: video/audio, codec, resolution, HDR/SDR, container. Второй формирует изменения: encoder, audio, subtitles, stream order, container. Третий выполняет команду. Четвёртый проверяет результат. Пятый делает файловые операции и завершает работу. Такая структура помогает по одному Job Report понять, на каком уровне возникла проблема.

Не стоит соединять десять преобразований в одну непрозрачную custom FFmpeg command только потому, что FFmpeg технически это позволяет. Одна команда действительно может быть быстрее, чем несколько последовательных перекодирований, но логику принятия решений всё равно лучше разнести на блоки, а сам Execute оставить единым. Тогда Tdarr строит одну финальную команду, но граф остаётся читаемым.

Ветви должны снова сходиться только там, где их состояния совместимы. Если одна ветка создаёт MKV, а другая MP4, общий следующий шаг не должен без проверки предполагать один контейнер. Если GPU-ветка создаёт 10-bit, а CPU-ветка 8-bit, финальная проверка должна учитывать оба допустимых результата или привести их к одной политике.

Полезно давать пользовательским переменным смысловые имена: targetCodec, preferredAudioLanguage, maxResolution, quality. Имена вроде x1 или test быстро превращают универсальный Flow в трудно сопровождаемую схему. То же относится к Node Tags: тег nvenc понятнее условного node2.

Проверка результата перед заменой

Минимальная проверка результата — успешный код возврата энкодера. Для важной коллекции этого недостаточно. Можно дополнительно убедиться, что working file существует и имеет ненулевой размер, контейнер соответствует ожидаемому, нужные видео- и аудиопотоки присутствуют, а размер не превышает допустимый предел. Затем при необходимости выполняется health check.

Сравнение длительности полезно для выявления обрезанных результатов, но нужно учитывать особенности контейнеров и округление. Незначительное отличие метаданных duration не обязательно означает потерю кадров. Если условие должно быть автоматическим, задавайте разумный допуск, а не требование абсолютного равенства десятичного значения.

При аудио- и субтитровой очистке проверяйте не только количество потоков, но и их роль. Два audio streams не гарантируют наличие нужного языка, а один subtitle stream не гарантирует, что это forced track. Финальный контроль должен отражать именно пользовательскую цель.

Методика безопасного тестирования

Самый надёжный способ внедрить Tdarr — не запускать сразу всю медиатеку. Создайте тестовую Library с копиями нескольких файлов, отражающих реальные крайние случаи. В неё должны попасть распространённый 1080p, крупный 4K, необычный контейнер, файл с несколькими аудиоязыками, графическими субтитрами, HDR при его наличии и хотя бы один элемент, который уже соответствует целевой политике.

Первый проход выполняют с одним Worker. Так легче читать последовательность Job Report и исключить конкуренцию за кэш. Второй проход повторяет обработку тех же результатов: если они снова кодируются, политика ещё не готова. Третий проход добавляет параллельность и проверяет, хватает ли диска, сети и кэша. Только затем Flow переносится на основную Library.

1. Сначала проверить сканирование и свойства без модификации.
2. Запустить Flow на копии оригинала с отключённой финальной заменой, если это предусмотрено схемой.
3. Сравнить потоки, длительность, цветовые свойства, размер и воспроизведение.
4. Повторно поставить результат в очередь и убедиться, что дорогая ветка больше не нужна.
5. Проверить ошибочный сценарий: недоступный кэш, неподдерживаемый codec или отсутствующий тег.
6. Только после этого включать Replace Original File и Auto accept.

Такой тест важнее синтетического измерения FPS. Цель автоматизации — не получить рекордную скорость на одном файле, а предсказуемо обработать тысячи разных входов без потери данных.

Сетевая медиатека: SMB, NFS и NAS

При хранении Source на NAS сервер Tdarr, Node и сам сетевой ресурс образуют единую цепочку. Mapped Node должен видеть тот же файл, что Server, но путь и способ монтирования могут отличаться. Если Linux Server использует NFS-путь, а Windows Node — SMB share, Path Translator решает только текстовую часть адреса; права и реальная доступность всё равно настраиваются на уровне ОС.

Для сетевой обработки желательно использовать стабильные системные mounts, которые существуют до запуска Tdarr. Пользовательский сетевой диск, подключённый после входа в GUI-сеанс, может быть невидим service-процессу. В контейнере нужно проверять путь внутри container namespace, а не только путь хоста.

Сетевой bandwidth особенно важен при аппаратном encode. Один GPU может обработать видео быстрее, чем гигабитная сеть успевает подать несколько потоков исходных 4K-файлов. При этом график GPU выглядит недогруженным, хотя проблема не в количестве workers. В таких случаях помогает локальный быстрый cache, меньшая параллельность и более быстрый uplink.

При нестабильной сети health check и transcode могут выдавать похожие ошибки чтения. Если сбой не воспроизводится локально и возникает на разных файлах в случайных местах, сначала проверяйте NAS, сеть и mount, а не объявляйте десятки медиафайлов повреждёнными.

Параллельная работа нескольких библиотек

Каждая Library имеет собственное расписание и настройки обработки, поэтому Tdarr можно использовать как приоритетную очередь без ручного перемещения файлов. Например, новая медиатека может работать круглосуточно с одним GPU Worker, а архивная конверсия — только ночью и забирать ещё два. Это снижает задержку для свежих материалов, не останавливая долгий проект оптимизации.

Приоритет Library и Node следует отличать от порядка плагинов. Library priority влияет на выдачу работ между библиотеками, Node priority — на предпочтение вычислительных узлов, а plugin order — на логику одного файла. Ошибка в одном уровне не исправляется другим: повышение приоритета Node не заставит GPU Worker выполнить CPU-only команду.

Если разные библиотеки находятся на разных физических дисках, их параллельность можно использовать для загрузки оборудования. Если они лежат на одном массиве, агрессивная конкуренция способна снизить суммарную скорость. Планирование Tdarr имеет смысл согласовать с topology хранилища, а не только с числом CPU cores.

Логи и хранение отчётов

Сервер и Node имеют ограничение размера лог-файлов, задаваемое конфигурацией. Job Reports хранят подробности отдельных заданий отдельно от общих Logs, и для них можно определить отдельный путь. На постоянно работающем сервере это полезно, чтобы диагностические данные не заполняли системный раздел неожиданно.

Полный FFmpeg/HandBrake output следует включать как диагностический режим, а не обязательно оставлять навсегда. Длинный encode способен генерировать большой объём строк, и на тысячах файлов это увеличит размер отчётов без практической пользы. Обычного сокращённого вывода достаточно, пока ошибка не требует контекста из середины процесса.

При обращении за помощью наиболее полезны Job Report конкретного файла, Node log и Server log за тот же период. Скриншот финального Error почти ничего не объясняет: одна и та же красная строка может скрывать неправильный path, неподдерживаемый encoder, отказ muxer или сетевой разрыв.

Когда remux лучше транскодирования

Если кодеки уже подходят целевым устройствам, а проблема заключается только в контейнере или порядке потоков, remux предпочтительнее повторного encode. Он не пересчитывает видеокадры и аудиосэмплы, поэтому выполняется значительно быстрее и не добавляет потерь качества. В Tdarr такой сценарий удобно ставить раньше дорогих веток: сначала проверить, можно ли решить задачу контейнером и составом streams, и только при реальной несовместимости переходить к кодированию.

Однако remux не является универсально безопасной операцией. Целевой контейнер должен поддерживать все сохраняемые типы потоков, а клиенты — уметь декодировать сами кодеки. Если MP4 не принимает конкретные субтитры или data stream, понадобится Force Conform, явное удаление либо конвертация этого потока. Если устройство не понимает HEVC, перенос HEVC из MKV в MP4 ничего не изменит. Поэтому решение принимается по всей цепочке контейнер — видео — аудио — субтитры — клиент, а не по одному расширению.

Отдельно полезно различать remux и переупаковку с изменением метаданных. Некоторые задачи могут проходить без повторного сжатия, но всё равно изменять порядок tracks, default/forced flags или заголовки. Для архива такие изменения тоже стоит тестировать, особенно если сторонние программы зависят от названий дорожек или chapters.

Сравнение Tdarr с аналогами

Программа	Лучше подходит для	Главное ограничение
Tdarr	Постоянной условной обработки больших медиатек и распределения задач между несколькими Nodes	Сложнее первоначально настроить пути, Workers, плагины и Flow
Unmanic	Автоматической оптимизации библиотек с plugin-пайплайном и сравнительно быстрым стартом	Архитектура и маршрутизация отличаются от детализированных Tdarr Flows, поэтому сложные Tdarr-сценарии не переносятся напрямую
FileFlows	Визуальных многоцелевых файловых Flow с FFmpeg Builder и внешними processing nodes	Широта задач увеличивает число сущностей и настроек, если нужен только простой медиатранскод
HandBrake	Ручной и пакетной конвертации с готовыми пресетами и визуальными параметрами	Нет модели постоянной распределённой медиатеки с сервером, Nodes и условными библиотечными очередями уровня Tdarr
FFmpeg Batch AV Converter	Пакетного запуска FFmpeg через графический интерфейс и собственные параметры	Ориентирован на управляемые пользователем batch-задачи, а не на постоянно наблюдаемую распределённую библиотеку

Практический выбор зависит от того, является ли задача постоянным обслуживанием медиатеки или эпизодической конвертацией. Tdarr особенно силён, когда файлов много, правила повторяются, есть несколько вычислительных узлов и важно автоматически определять нужна ли обработка. Для ручной подготовки нескольких роликов HandBrake или пакетный FFmpeg-интерфейс проще. Если нужна более широкая автоматизация файлов разных типов, а не только медиатеки, FileFlows может оказаться естественнее. Unmanic ближе всего по идее поставил библиотеку под наблюдение и приводи её к правилам, но его модель плагинов и распределения отличается.

Когда Tdarr подходит лучше всего

Tdarr оправдан, когда библиотека достаточно большая, чтобы ручное поддержание единого формата стало постоянной работой. Особенно полезны повторяемые требования: целевой codec, контейнер, наличие совместимого audio, ограничение лишних streams, автоматический health check и ночное расписание. В такой среде время, потраченное на точный Flow, окупается тем, что каждое новое поступление проходит одинаковую проверку.

Второй сильный сценарий — неоднородное железо. Вместо того чтобы запускать отдельные очереди на каждом ПК, Tdarr позволяет свести их к Server и направлять задания на Nodes. Это удобно в домашней лаборатории, где несколько машин включаются не постоянно, но могут ускорять большую миграцию библиотеки.

Для разовых конвертаций двух-трёх файлов Tdarr обычно избыточен: настройка библиотеки, кэша, Node и правил занимает больше времени, чем обычный batch encoder. Программа раскрывается там, где важны автоматическое обнаружение, состояние всей коллекции и повторяемость решений.

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

Можно ли использовать Tdarr без GPU?

Да. CPU Workers выполняют транскодирование программными энкодерами и health checks. GPU нужен только для аппаратных веток. CPU-режим часто медленнее, но даёт широкий выбор параметров и не зависит от аппаратных ограничений конкретного ускорителя.

Можно ли смешивать Windows, Linux и macOS Nodes?

Да, Server и Nodes не обязаны работать на одной ОС. Для mapped Nodes критично, чтобы они обращались к одним физическим Source/Cache; при различии синтаксиса путей используются Path Translators.

Почему запущенный GPU Worker не берёт файл?

Потому что тип Worker — только часть условия. Команда должна выглядеть для Tdarr как GPU-задача, Node должен иметь нужные теги, Library должна быть разрешена расписанием, а Flow не должен требовать CPU. Откройте Staging/Job Report и проверьте требуемые tags.

Нужно ли перекодировать MKV в MP4?

Только если это требуется вашим клиентам или политике. Контейнер не определяет видеокодек. Если потоки уже совместимы, можно сделать remux без повторного сжатия; если MP4 не поддерживает конкретный поток, его придётся преобразовать, удалить или выбрать другой контейнер.

Можно ли оставить оригинал и создать копию?

Да, Flow можно построить без Replace Original File и переместить working file в другой каталог, сохраняя исходник. Нужно заранее продумать структуру output и исключить её из Source, чтобы копии не сканировались как новые входы.

Как понять, что Flow завершён правильно?

Повторный запуск над результатом не должен снова выполнять дорогие изменения. В Search свойства должны соответствовать политике, Job Report — завершаться без ошибок, а файл после повторной постановки обычно получать Not required или проходить только безопасные проверки.

Что делать, если новый файл стал больше?

Проверить encoder, quality/preset и исходный bitrate. Для некоторых источников более новый codec не гарантирует уменьшение при выбранных параметрах. Добавьте в Flow сравнение размеров и не заменяйте оригинал, если результат не соответствует цели.

Как найти причину ошибки конкретного файла?

Открыть Job Report этого запуска, найти первый реальный сбой FFmpeg/HandBrake или plugin step, затем проверить путь, входные свойства и сформированную команду. Серверный лог нужен главным образом для проблем инфраструктуры, а не для анализа одного encode.

Можно ли использовать один Flow для разных библиотек?

Да. Глобальные и library variables позволяют подставлять разные значения — например качество, язык, контейнер или custom argument — в один и тот же граф. Это удобнее копирования Flow, если логика одинакова, а параметры отличаются.

Нужно ли включать Thorough health check для каждого файла?

Не обязательно. Полный проход дорого обходится по времени и I/O. Для постоянного фонового контроля можно использовать Quick, а Thorough — по расписанию, после миграции, для новых результатов или подозрительных элементов.

Итог

Tdarr — инструмент для построения политики медиатеки, а не просто оболочка над одной командой FFmpeg. Его сильные стороны — условные правила, отдельные библиотеки, очереди, CPU/GPU Workers, распределённые Nodes, health checks, подробные Job Reports и два уровня расширения через Classic Plugins и Flows. За эту гибкость приходится платить более высокой сложностью настройки: особенно внимательно нужно работать с путями, кэшем, тегами, контейнерной совместимостью и условиями завершения.

Наиболее надёжная схема внедрения состоит из небольшой тестовой Library, проверенного mapped-доступа, нескольких репрезентативных файлов и явно заданного критерия ничего делать не нужно. После того как повторный прогон действительно даёт Not required, а отчёты подтверждают корректный результат, Tdarr можно переводить в длительный автоматический режим и постепенно масштабировать число Nodes и Workers.