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

В основе работы лежат библиотеки, очередь задач, рабочие процессы и плагины. Для каждой библиотеки можно задать собственный набор проверок и действий, поэтому фильмы, сериалы, записи с ТВ-тюнера, музыкальные файлы или произвольные каталоги не обязаны обрабатываться одинаково. Файл сначала проходит этап тестирования, затем при необходимости попадает в Pending Tasks, после чего свободный worker запускает назначенные операции и передаёт итог в постобработку.

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

Как Unmanic обрабатывает файлы

Рабочий цикл начинается не с запуска FFmpeg, а с обнаружения кандидата. Источником может быть периодическое сканирование каталога, монитор файловой системы, ручной запуск проверки или добавление задачи через API. Сам факт обнаружения файла ещё не означает перекодирование. Unmanic передаёт путь в цепочку плагинов этапа Library Management - File Test, где каждый модуль решает, нужно ли ставить задачу в очередь, игнорировать файл или передать проверку следующему модулю.

Это различие важно для больших коллекций. Если библиотека уже соответствует выбранным правилам, постоянное полное перекодирование было бы и медленным, и вредным для качества. Поэтому плагины обычно используют FFprobe или другую проверку метаданных и только затем требуют обработку. Например, Video Transcoder может определить, что видеопоток уже закодирован выбранным кодеком, а фильтр по языку — что в файле нет дорожек, которые нужно удалить.

Проверки на этапе File Test выполняются по порядку. Как только один плагин требует создать задачу, дальнейшее тестирование этой цепочки прекращается и файл ставится в очередь. Аналогично, явный запрос на игнорирование останавливает дальнейшие тесты. Если все модули отвечают, что действие не требуется, файл остаётся в библиотеке без изменений. Поэтому порядок фильтров имеет практическое значение: сначала обычно ставят самые широкие ограничения, потом более узкие проверки кодека, разрешения, языка или возраста файла.

После помещения файла в очередь worker заново запускает собственные проверки плагинов этапа Worker - Process. Это сделано потому, что задачу мог создать один модуль, а другие модули в том же worker-потоке для конкретного файла могут оказаться ненужными. Если несколько процессоров действительно нужны, они идут последовательно: результат одного становится входом для следующего.

Промежуточные данные хранятся в cache path. Исходный файл не перезаписывается во время работы команды. Только после успешного завершения всех необходимых операций Unmanic переходит к движению результата и финальным событиям. При стандартном поведении успешный выход заменяет исходный файл обработанным, а при ошибке источник остаётся на месте. Именно поэтому перед первым массовым запуском нужно проверить не только кодек, но и правила перемещения: ошибка в профиле может корректно выполниться с точки зрения FFmpeg, но дать нежелательный для медиатеки результат.

Dashboard: очередь, workers и выполненные задачи

Главная страница предназначена для наблюдения за текущей работой. Она не является отдельным редактором профилей: здесь сосредоточены состояние workers, Pending Tasks и Completed Tasks. Такой расклад удобен при первоначальной настройке, потому что позволяет видеть, действительно ли сканер находит файлы, хватает ли обработчиков и чем закончилась каждая операция.

Pending Tasks

В Pending Tasks находятся пути к файлам, которые уже признаны требующими обработки, но ещё не назначены свободному worker. Карточка на главной странице показывает до десяти ближайших элементов; раскрытый список даёт больше возможностей управления. Выбранную задачу можно поднять к началу очереди, опустить вниз или удалить. Отсюда же запускается повторное сканирование библиотеки. Если сканирование уже запланировано или выполняется, вместо простого повторного запуска доступны Pause, Resume и Cancel для самого процесса сканирования.

Удаление пункта из Pending Tasks не изменяет сам файл. Но если условия библиотеки остаются прежними, последующее сканирование снова может признать его несоответствующим и вернуть в очередь. Поэтому постоянное исключение нужно решать на уровне File Test: фильтром, правилом игнорирования, отдельной библиотекой или корректировкой целевого профиля.

Workers и их состояние

Worker — исполнитель задачи. Несколько workers способны параллельно запускать независимые подпроцессы, поэтому увеличение их числа действительно повышает параллелизм, а не просто делит одну команду на виртуальные потоки. Карточка worker показывает, свободен ли он, обрабатывает ли файл, известен ли процент выполнения и приостановлен ли исполнитель. В раскрытом состоянии видны дополнительные сведения и текущий вывод команды.

Через Options можно приостановить или возобновить конкретный worker, а также завершить его текущий subprocess. Это полезно, если один файл застрял, а остальные очереди нужно сохранить. Следует различать паузу worker и паузу сканирования: первая влияет на выполнение очереди, вторая — на обнаружение новых кандидатов.

Состояние Processing с неопределённым прогрессом не обязательно означает зависание. Не каждый внешний процесс выдаёт строку, из которой интерфейс может извлечь процент. В таком случае нужно смотреть живой журнал: изменение frame, time, размера выходного файла или активности устройства говорит о продолжающейся работе.

Completed Tasks

Выполненные элементы получают статус успеха или ошибки. Раскрытый список позволяет вернуть одну или несколько задач обратно в Pending Tasks или удалить записи из истории. Повторная постановка особенно полезна после исправления параметров плагина: не приходится ждать нового полного сканирования.

У провалившейся задачи доступна подробная карточка с командами и журналом каждого worker-job. По ней обычно видно, на каком плагине возникла проблема, какой входной поток был выбран и что вернул FFmpeg или внешний процесс.

Есть важная особенность: задача со статусом Failed, остающаяся в Completed Tasks, игнорируется последующими сканированиями и событиями file monitor. Если причина устранена и файл нужно попробовать снова, его следует переочередить либо удалить соответствующую неуспешную запись, а не просто несколько раз запускать Rescan.

Библиотеки: независимые правила для разных каталогов

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

При первом запуске создаётся базовая библиотека. Её имя и путь можно менять. Дополнительные библиотеки создаются кнопкой добавления и сначала имеют пустой набор правил. Сам каталог без плагинов фактически ничего не делает: сканирование найдёт файлы, но ни один модуль не потребует рабочую задачу.

Имя и path

Имя важно не только для удобства. При связке нескольких инсталляций совпадение имени библиотеки участвует в маршрутизации удалённых задач. Путь должен быть реальным с точки зрения того процесса, который запускает Unmanic. В Docker это путь внутри контейнера, а не путь хоста. Если на хосте каталог подключён как /mnt/media/movies, но в контейнер передан как /library/movies, именно второй вариант нужно указывать в библиотеке.

Ошибки в path часто маскируются под проблемы плагинов: список пуст, scan завершается мгновенно, worker получает не существующий путь или удалённый узел не может открыть файл. Перед настройкой кодирования полезно убедиться, что Unmanic видит реальные файлы и имеет право читать каталог, создавать временные данные и заменять итоговые файлы.

Scanner и File Monitor

Для каждой библиотеки отдельно включаются периодические сканы и file monitor. Scanner последовательно просматривает каталог и запускает File Test для найденных файлов. Можно задать интервал в минутах, выполнить один скан при старте и разрешить следование по символическим ссылкам. Это предсказуемый вариант для сетевых хранилищ, архивов и библиотек, где нет необходимости реагировать на файл сразу после появления.

File Monitor реагирует на изменения файловой системы. Для локального диска это экономит полный обход каталога: новый или изменённый файл можно проверить вскоре после события. Но на сетевых файловых системах события могут доставляться иначе или не доставляться вовсе, поэтому там периодическое сканирование часто надёжнее. Обычно нет смысла одновременно включать оба механизма без причины: это увеличивает число проверок, хотя защита от повторной обработки остаётся задачей File Test.

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

Manual rescan полезен после изменения правил File Test, потому что позволяет сразу перепроверить содержимое. Когда scan уже выполняется, его можно приостановить, продолжить или отменить. Pause сохраняет текущий прогресс сканирования, Resume продолжает обход, а Cancel снимает активный или запланированный запрос. Это удобно, если стало ясно, что фильтр настроен слишком широко и очередь быстро наполняется лишними файлами.

Библиотека только для удалённых задач

Опция Use this library only for linked remote tasks превращает библиотеку в целевой endpoint для связанных инсталляций. В таком режиме локальный scanner не просматривает путь, а file monitor не наблюдает его. Однако вручную или удалённо созданные pending tasks не запрещаются. Если присланный файл доступен по тому же пути на общем хранилище, удалённый узел работает с ним напрямую; если путь недоступен, применяется передача данных между инсталляциями.

Установка и назначение плагинов

Большинство полезных операций в Unmanic реализовано не жёстко в ядре, а отдельными plugins. Ядро отвечает за обнаружение файлов, очередь, workers, cache, стадии выполнения и интерфейс. Плагин добавляет правило проверки, команду обработки, перемещение, реакцию на результат или информационную панель. Такой подход позволяет одной и той же программе заниматься не только видео, но и аудио, изображениями, именованием, уведомлениями и внешними скриптами.

Plugin Installer

Во вкладке Plugins кнопка Add New открывает Plugin Installer. Перед поиском новых модулей можно обновить данные репозиториев. В карточке плагина отображаются название, автор, версия и источник; кнопка установки добавляет модуль в Unmanic, но сама по себе ещё не включает его ни в одну библиотеку.

После установки нужно открыть настройки конкретной библиотеки, добавить плагин в её конфигурацию и проверить место в Plugin Flow. Это две разные операции: глобально установленный модуль доступен системе, а включённый в библиотеку — реально участвует в её pipeline. Такая модель позволяет держать несколько инструментов установленными и использовать только нужные в конкретном каталоге.

Официальный и пользовательские репозитории

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

Список репозиториев позволяет видеть добавленные источники и удалять их. Удаление источника не является эквивалентом отмены уже выполненной обработки и не должно использоваться как способ вернуть файлы в исходное состояние. Если установленный plugin больше не нужен, нужно отдельно изменить flow библиотеки и решить, требуется ли удалять сам модуль.

Глобальные и библиотечные настройки

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

Кнопка Reset Configuration в библиотечном окне удаляет локальное переопределение и возвращает использование глобальных параметров. Это удобнее, чем вручную копировать значения между множеством библиотек, и одновременно помогает диагностировать случай, когда изменения в глобальном профиле не применяются: чаще всего у библиотеки сохранён собственный override.

Разные плагины показывают разные типы элементов формы — переключатели, поля текста, select, slider, выбор каталога. Конкретный набор строится самим модулем, поэтому одинакового универсального экрана настроек нет. Если параметр плагина непонятен, лучше ориентироваться на его описание и реальную команду в журнале, а не переносить значения из другого encoder-модуля по похожему названию.

Plugin Flow и четыре стадии обработки

Порядок модулей настраивается перетаскиванием. В актуальной модели у библиотеки четыре основных потока: Library Management - File Test, Worker - Process, Post-processor - File Movement и Post-processor - Task Results. Один плагин может иметь обработчики сразу для нескольких стадий, но логически каждая стадия решает отдельную задачу.

Library Management - File Test

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

Поскольку выполнение прекращается после первого явного Request Task или Request Ignore, неправильный порядок может давать неожиданный результат. Если сначала поставить широкое правило все H.264 перекодировать, а после него фильтр игнорировать 4K, второй модуль может никогда не получить файл. Безопасный подход — сначала ограничения, затем операции.

Worker - Process

На этой стадии запускается собственно преобразование. Каждый процессор перед выполнением ещё раз проверяет, нужен ли он данному файлу. Если цепочка содержит Video Transcoder, Normalise AAC Audio Streams и удаление дорожек по языку, не каждый модуль обязан менять каждый файл. Если изменение требуется, выход предыдущего процессора становится входом следующего, а все промежуточные версии остаются в рабочем cache.

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

Post-processor - File Movement

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

Post-processor - Task Results

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

Почему порядок нельзя выбирать случайно

Линейный flow означает, что каждый следующий модуль видит уже изменённое состояние. Если сначала удалить attachment streams, а потом попытаться сохранить их в отдельный архив, второй этап уже не сможет восстановить исходные вложения. Если сначала изменить container, а потом применить фильтр, ориентирующийся на расширение исходника, критерий может перестать соответствовать ожидаемой логике. Поэтому порядок должен отражать не удобство чтения списка, а зависимость действий.

Надёжный способ проектирования — записать желаемый путь словами: проверить свежесть → проверить codec → сохранить субтитры → перекодировать видео → нормализовать нужное аудио → переместить → обновить медиасервер. Затем каждое действие сопоставляется с правильной стадией. Такой подход уменьшает риск того, что post-processor окажется раньше операции, от результата которой он зависит.

Перекодирование видео с Video Transcoder

Типовой сценарий Unmanic — привести видеопотоки к единому кодеку. Официальный Video Transcoder проверяет видеопотоки и при необходимости формирует команду FFmpeg. В его настройках как целевые семейства представлены H.264, HEVC/H.265 и AV1, а конкретный encoder зависит от выбранного режима и доступного оборудования. Плагин поддерживает программные энкодеры и аппаратные реализации, включая QSV, VAAPI и NVENC, если среда и драйверы настроены.

Codec, encoder и принудительная обработка

Параметр Video Codec задаёт целевое семейство, а Video Encoder — конкретный кодировщик. Это разные уровни: HEVC может кодироваться программным libx265, NVIDIA NVENC, Intel Quick Sync или VAAPI. Выбор аппаратного encoder не имеет смысла, если устройство не передано в контейнер или драйвер не предоставляет нужный codec profile.

Опция Force transcoding even if the file is already using the desired video codec предназначена для случаев, когда одного совпадения codec_name недостаточно — например, нужно пересжать материал с другими параметрами. Она требует осторожности: повторное поколение с потерями снижает качество, а дальнейшее переименование или изменение метаданных может осложнять механизмы, которыми плагин помечает уже обработанный файл.

Container: сохранить или изменить

Video Transcoder умеет оставить исходный container либо выбрать MKV или MP4. Контейнер нельзя путать с кодеком: H.264 и HEVC могут находиться в разных оболочках, а совместимость конечного устройства определяется сочетанием container, video, audio, subtitles и профиля кодирования. Если задача — только сменить оболочку без повторного сжатия потоков, лучше использовать подходящий remux-процесс, а не заставлять видеотранскодер делать лишнюю работу.

Smart video filters и разрешение

В стандартных настройках плагина есть preconfigured video filters. Autocrop Black Bars запускает обнаружение областей обрезки и применяет crop при транскодировании. Target Resolution позволяет оставить source или выбрать целевую ступень, включая SD, 720p, 1080p, 1440p, DCI 2K, 4K UHD, DCI 4K и 8K UHD. Масштабирование вниз уменьшает число пикселей, но само по себе не гарантирует меньший файл: итог также зависит от encoder, режима качества, содержания и аудио.

Параметры Strip data streams и Strip attachment streams удаляют соответствующие типы потоков. Это может уменьшить лишние данные в container, но применять их без просмотра состава файла нельзя: attachments часто содержат шрифты для оформленных субтитров, а data streams могут хранить служебные данные. Если такие элементы нужны проигрывателю или архиву, их следует сохранить.

Smart Output Target и ручной режим

Для упрощённой настройки доступна идея Smart Output Target: Prefer Quality, Balanced или Prefer Compression. Такой уровень полезен, когда важнее задать намерение, чем вручную подбирать каждый FFmpeg-параметр. Для тонкого управления плагин также предоставляет расширенный режим с собственными options и filters. Здесь уже требуется понимание синтаксиса FFmpeg, поскольку некорректная комбинация может привести к провалу задачи или к формально успешному, но нежелательному результату.

На экране расширенных параметров виден характерный для Unmanic подход: программа собирает команду на основе формы, но оставляет опытному пользователю возможность дополнять её. Свободные параметры нужно вводить только тогда, когда штатных элементов плагина недостаточно. Чем больше custom options, тем важнее смотреть фактическую команду в task log.

Custom filters

Стандартный режим умеет включать собственные video filter chains. Это полезно для операций, которых нет в готовых переключателях, но здесь легко создать несовместимость с hardware pipeline. Software filtergraph и аппаратные filters требуют разной передачи кадров между CPU и GPU; иногда нужен hwupload или обратное скачивание кадров. Если аппаратный encode перестал работать после добавления фильтра, причина может быть не в encoder, а в несовместимом filter chain.

Что проверять после смены видеопрофиля

• codec и profile итогового видеопотока;
• разрешение, frame rate и aspect ratio;
• сохранность нужных audio и subtitle streams;
• HDR и color metadata для соответствующих источников;
• возможность Direct Play на реальных клиентах;
• размер файла и отсутствие повторной постановки после следующего scan.

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

Аудио, языки и нормализация

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

Audio Transcoder

Audio Transcoder переводит звуковые потоки в выбранный формат и учитывает ограничения канальности конкретного encoder. Важно оценивать не только расширение контейнера, но и поддержку кодека внутри него. MP4, MKV, WebM, MOV, AVI и TS имеют разные практические сочетания с AAC, AC3, EAC3, Opus или MP3. Если выбрать кодек с меньшим максимально поддерживаемым числом каналов, многоканальный источник будет сведён к допустимой конфигурации вместо сохранения исходной схемы.

В специализированных audio encoder-плагинах встречаются расширенные поля для собственных FFmpeg main, advanced и audio options, а Max input stream packet buffer управляет размером muxing queue. Эти настройки нужны при реальной проблеме с конкретным материалом; увеличение буфера не улучшает качество звука и не заменяет корректную схему stream mapping.

Normalise AAC Audio Streams

Плагин нормализации AAC работает только с потоками AAC и применяет loudnorm. В настройках задаются Integrated Loudness Target, Loudness Range и Maximum True Peak. Такая обработка полезна для медиатеки, где эпизоды или файлы сильно отличаются по воспринимаемой громкости. Нормализация не равна простому повышению volume: она использует параметры целевой громкости и пиков и требует перекодирования затронутого аудиопотока.

Есть настройка, позволяющая игнорировать ранее нормализованные файлы. Она защищает от бесконечного повторения одной и той же операции. Если параметры loudness меняются, нужно осознанно решить, следует ли заново обрабатывать старые файлы: повторное lossy-кодирование аудио может быть нежелательным.

Языки и порядок дорожек

Официальный каталог включает плагины для удаления audio/subtitle streams по языку и для переупорядочивания аудиодорожек по language metadata. Практический смысл в том, чтобы отделить хранение от поведения проигрывателя: можно оставить только нужные языки или сделать предпочтительный язык первым, не затрагивая видео. Перед массовым удалением стоит проверить, корректно ли проставлены language tags. Дорожка с неопределённым языком может оказаться оригинальной, комментариями или дубляжом, и автоматическое правило без исключений способно удалить полезный контент.

Если цель — сохранить многоканальный оригинал и добавить совместимую stereo-дорожку, лучше проектировать этот процесс явно. Сначала создаётся производный поток, затем при необходимости он нормализуется, а исходная дорожка сохраняется. Удаление исходника до создания производной версии лишает pipeline возможности вернуться к полноценному surround.

Субтитры, attachments и служебные потоки

Субтитры в медиаконтейнере бывают текстовыми и графическими, а оформленные ASS/SSA могут зависеть от вложенных шрифтов. Поэтому задача удалить всё лишнее требует большего внимания, чем кажется. В Unmanic можно строить поток, в котором сначала извлекаются нужные субтитры, затем изменяется набор встроенных streams и только потом выполняется remux или транскодирование.

Если Video Transcoder настроен на Strip Attachment Streams, из container исчезнут attachments. Для простого SRT это может быть безразлично, но для стилизованных субтитров отсутствие шрифтов меняет внешний вид. Strip Data Streams тоже нельзя применять как универсальную оптимизацию: часть containers использует data streams для служебных метаданных и отдельных типов субтитров.

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

Если конечный container меняется с MKV на MP4, проверку субтитров нужно делать особенно внимательно. То, что штатно хранится в Matroska, не обязательно можно перенести в MP4 в режиме stream copy. Ошибка mux в таком случае не означает, что исходник повреждён: причина может быть в сочетании output container и конкретного subtitle codec.

Workers, группы, tags и расписание

Настройки workers определяют не только число параллельных операций. Worker Groups позволяют разделить исполнителей по назначению. У каждой группы есть имя, количество workers, tags и возможность защиты от случайного удаления. Теги связывают группу с libraries: задача может быть взята группой, если у библиотеки и группы есть хотя бы один общий tag.

Если у библиотеки нет tags, её задачи обрабатывают только группы без tags. И наоборот, библиотека с тегом gpu не должна рассчитывать на нетегированную CPU-группу. Это удобный способ отделить 4K от обычного материала, аппаратные задачи от программных или приоритетную медиатеку от фоновой.

Сколько workers ставить

Worker Group позволяет выбрать несколько параллельных исполнителей, но оптимальное значение зависит от операции. Для software x265 один тяжёлый encode может уже загрузить все CPU cores; четыре таких workers нередко лишь конкурируют за процессор и диск. При NVENC несколько параллельных задач могут быть эффективнее, пока не достигнуты лимиты GPU, VRAM, decoder sessions или пропускной способности накопителя. Для remux и простых метаданных лимитом чаще становится I/O.

Документация рекомендует для большинства установок не гнаться за большим числом одновременно активных workers: практический эффект часто уменьшается после нескольких процессов. Начинать разумно с одного, а затем постепенно увеличивать значение после наблюдения за CPU, GPU, RAM, cache и скоростью диска.

События расписания

Worker settings поддерживают events, которые выполняются сверху вниз. Ими можно менять число workers в разные периоды: например, оставить один обработчик утром, увеличить число вечером и использовать больший pool в выходные. Если активных workers больше нового целевого значения, Unmanic не обрывает занятый процесс только ради снижения счётчика: лишний исполнитель завершается, когда освобождается.

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

Теги как средство маршрутизации

Tags удобны не только для разделения CPU и GPU. Ими можно сделать отдельную группу для медленных AV1-задач, для remux, для коротких роликов или для библиотеки с высокой приоритетностью. Главное — не использовать слишком много пересекающихся tags без схемы. Если library совпадает сразу с несколькими groups, задача может быть обработана не тем hardware profile, который подразумевался.

Cache Path: временное пространство и защита исходников

Cache — рабочая область задачи. Плагин пишет новый файл не поверх оригинала, а в отдельный временный каталог. Следующий процессор получает предыдущий cache-output, поэтому цепочка может включать несколько преобразований, не затрагивая медиатеку до финального успеха. Если worker провалился, временные данные очищаются, а исходный файл остаётся.

Для одного файла требуемое место может быть близко к размеру исходника или превышать его, а при нескольких workers это значение умножается. Если pipeline создаёт последовательные промежуточные файлы, пик потребления может быть ещё выше. Поэтому маленький системный SSD при большой 4K-медиатеке часто оказывается более опасным узким местом, чем CPU.

Документация предлагает использовать tmpfs для I/O-bound задач. Это устраняет часть дисковых операций, но RAM должна вместить средний рабочий файл, умноженный на число параллельных workers, плюс память самих encoders. В Unraid можно использовать /dev/shm/unmanic либо отдельный tmpfs с явным лимитом. Если размер файла непредсказуем, обычный быстрый SSD безопаснее.

Cache path должен быть доступен на запись тому же пользователю, под которым работает Unmanic. В Docker это особенно важно: PUID и PGID определяют права процесса, а volume mount должен согласоваться с владельцем каталога на хосте. Ошибка Permission denied при старте FFmpeg часто связана именно с cache или destination, а не с входным media-файлом.

Cache не является резервной копией. После успешного завершения или ошибки временное содержимое может быть удалено. Использовать его как способ сохранить исходник нельзя. Если требуется возможность отката, нужен отдельный backup или движение результата в другой каталог.

Docker и файловые пути

Контейнерный запуск использует несколько ключевых томов: конфигурацию, библиотеку и cache. Типовая схема сопоставляет каталог настроек с /config, медиатеку с /library и временное пространство с /tmp/unmanic. Web UI обычно публикуется на порту 8888. Официальный Docker image собирается для linux/amd64, linux/armv7 и linux/arm64.

Экран General Settings хорошо показывает саму идею разделения library path, cache path, worker count, watcher и scanner. В актуальном интерфейсе часть этих параметров распределена по более специализированным разделам, но ошибки монтирования остаются теми же: путь внутри Unmanic должен существовать именно внутри его среды выполнения.

Read-only и read-write mounts

Если библиотека подключена только для чтения, scan и probe будут работать, но стандартная финальная замена исходника завершится ошибкой. Read-only имеет смысл только при flow, который пишет результат в отдельный доступный destination и не пытается удалить source. Для обычной оптимизации на месте библиотеке требуется запись.

PUID и PGID

Эти значения задают пользователя и группу для работы с файлами. Неправильные идентификаторы приводят к двум классическим симптомам: Unmanic видит каталог, но не может открыть отдельные файлы, либо успешно кодирует в cache, но падает на финальном move. Проверять права нужно на всех трёх уровнях: source, cache и destination.

Сетевые mounts

NFS и CIFS подходят для больших медиатек, но лучше учитывать задержки и семантику rename. Если cache и destination находятся на разных mounts, финальное перемещение не может быть обычным атомарным rename внутри одной файловой системы; Unmanic переходит к копированию. Поэтому большой файл после кодирования может ещё некоторое время копироваться, хотя FFmpeg уже завершён.

Для сетевого источника полезно отделять scan от file monitor: периодический scanner обычно предсказуемее на томах, где события файловой системы пробрасываются не полностью. Также следует избегать ситуации, когда медиасервер начинает читать файл в момент финальной замены; post-processing и notification о refresh лучше ставить после завершённого movement.

Windows

Для Windows предусмотрен Desktop Launcher, который объединяет Unmanic, Python и FFmpeg и даёт tray icon для базовых действий. Документация при этом рекомендует пользователям, знакомым с WSL, Docker и passthrough устройств, рассматривать WSL + Docker как более управляемую схему для сложных конфигураций и hardware acceleration. После запуска Web UI открывается в browser на локальном адресе.

Аппаратное ускорение: NVIDIA, Intel и AMD

Unmanic не требует GPU, но отдельные plugins умеют использовать аппаратные возможности FFmpeg. Для NVIDIA Video Transcoder поддерживает NVENC/NVDEC при доступном устройстве. В Docker недостаточно выбрать NVENC в форме: нужно установить драйвер на хосте, настроить NVIDIA Container Toolkit и передать GPU контейнеру.

Для Intel iGPU и AMD на Linux используется VAAPI. Здесь также требуется передать соответствующее устройство, обычно из /dev/dri, и убедиться, что драйвер поддерживает нужный codec profile. Intel Quick Sync может использоваться через QSV, если окружение предоставляет устройство и FFmpeg собран с нужной поддержкой.

Аппаратный encoder меняет баланс качества, скорости и нагрузки, но не делает профиль автоматически хорошим. Одинаковое название HEVC не означает одинаковый результат у libx265, NVENC, QSV и VAAPI. Поэтому сначала стоит проверить несколько реальных файлов на целевых клиентах, оценить размер и качество, а уже потом ставить полный scan.

Если hardware-плагин внезапно падает, диагностика должна идти снизу вверх: видит ли ОС устройство, видит ли его контейнер, умеет ли FFmpeg перечислить encoder, поддерживает ли encoder исходный pixel format и bit depth, и только после этого — корректны ли параметры Unmanic.

VAAPI

Для VAAPI поддержка определяется libva и драйвером. Intel и AMD могут работать через этот API, но набор доступных codec profiles зависит от конкретного GPU и driver stack. Перед запуском библиотеки лучше проверить декодирование и кодирование короткого тестового файла тем же FFmpeg, который находится в среде Unmanic.

NVENC и NVDEC

NVENC отвечает за аппаратное кодирование, NVDEC — за decode. Если encoder включён, но decoder остаётся software, часть нагрузки всё равно будет на CPU. И наоборот, аппаратный decode без NVENC не превращает software encode в аппаратный. При сложных filters кадры могут дополнительно переходить между GPU и CPU, что снижает ожидаемый выигрыш.

Linked Installations: распределение очереди между машинами

Unmanic умеет связывать несколько инсталляций и передавать им задачи. Главная идея — оставить единую логику обнаружения файлов, но подключить workers на другом компьютере. Это полезно, если медиатека находится на NAS, а кодировать удобнее на отдельной машине с GPU, либо если несколько серверов должны разгребать общий backlog.

В конфигурации link задаётся адрес удалённой инсталляции, направление передачи задач и дополнительные параметры. Unmanic сам не предоставляет встроенную общую HTTP-аутентификацию для такого endpoint; если доступ выходит за доверенную сеть, защиту нужно организовать reverse proxy и сетевой инфраструктурой. В настройках связи можно использовать подходящую схему аутентификации прокси.

Совпадение библиотек

Для маршрутизации удалённой задачи на принимающей стороне должна существовать библиотека с подходящим именем. Если обе машины видят один storage по совместимому пути, удалённый worker может работать с файлом напрямую. Если путь не разрешается на удалённой стороне, Unmanic переключается на передачу данных между инсталляциями.

Поэтому есть два архитектурных варианта. Первый — shared storage: меньше сетевых копий между Unmanic-узлами, но обе машины должны одинаково и надёжно видеть медиатеку. Второй — transfer: source отправляет файл worker-узлу, тот обрабатывает и возвращает результат. Он проще при разных локальных дисках, но требует дополнительного traffic и временного места.

Preload remote Pending Tasks

Для снижения простоя удалённого worker можно заранее держать несколько задач в его Pending queue. Это особенно полезно при высокой задержке сети или больших файлах, когда следующий encode иначе ждёт копирования после каждого завершения. Значение preloading — целевой размер удалённой ожидающей очереди, а не строгий лимит всей удалённой работы: выполняющиеся tasks считаются отдельно.

Слишком высокий preload имеет обратную сторону — больше данных заранее передаётся на remote и дольше занимает его storage. Для локальной быстрой сети обычно достаточно небольшой очереди; для медленного канала нужно сопоставлять скорость transfer со скоростью encoder.

Разные plugin stacks на разных узлах

Связанная схема позволяет учитывать hardware каждого компьютера. Один узел может иметь NVIDIA и соответствующий encoder plugin, другой — Intel QSV, третий — только CPU. Важно понимать, что удалённый execution опирается на конфигурацию принимающей стороны. Поэтому одинаковое имя library не означает, что её plugin stack обязан быть идентичным; напротив, документация допускает tuning под конкретное оборудование.

Но различие профилей должно быть намеренным. Если один узел кодирует HEVC в MKV, а другой по той же logical library выдаёт MP4 с иным audio policy, итог станет неоднородным. Перед масштабированием лучше добиться одинакового логического результата на каждом типе worker, даже если конкретный encoder различается.

Data Panels и измерение результата

Data Panel — тип frontend-плагина, который добавляет собственную страницу в Web UI. Он не обязан менять файлы: его задача может быть чисто аналитической. Это удобно, потому что обработку и её metrics можно держать в одном интерфейсе, не смешивая их с основной карточкой Dashboard.

Пример — File Size Metrics. Панель сохраняет сведения о размере до и после обработки и показывает суммарное изменение, список tasks и данные по отдельному файлу. Эти цифры полезны при выборе между несколькими профилями кодирования: можно видеть не только субъективное качество, но и реальный размер итогов.

Метрики не следует трактовать как универсальную оценку качества. Большое уменьшение размера может означать эффективный HEVC-профиль, а может — чрезмерное снижение bitrate или resolution. Корректный цикл настройки: небольшая выборка файлов, визуальная проверка, совместимость клиентов, затем статистика размера и только после этого массовая очередь.

Если панель показывает, что отдельные файлы после обработки стали больше, это не обязательно ошибка. Уже хорошо сжатый source, grain-heavy материал, высокий quality target или другой container overhead могут уменьшить ожидаемую экономию. Такие исключения нужно анализировать отдельно, а не автоматически снижать quality для всей библиотеки.

API: точная постановка задач без полного scan

REST API позволяет программно тестировать файлы и добавлять их в очередь. Это альтернатива scanner и file monitor, особенно полезная, когда другое приложение уже знает, какой файл только что появился. Вместо обхода сотен тысяч записей внешняя автоматизация может отправить конкретный path сразу после импорта.

Встроенная интерактивная документация API доступна из раздела Help and Support. Один из рабочих путей добавления задач использует endpoint /api/v2/pending/create; после создания элемент проходит тот же worker pipeline, что и обычная задача. API не является обходом правил post-processing: он меняет способ обнаружения, но не саму логику worker и plugins.

С точки зрения интеграции это даёт три полезных сценария: медиаменеджер сообщает о новом файле после move, собственный script выбирает только записи старше определённой даты, либо внешняя система отправляет обработку после проверки checksum или архивации. В каждом случае основной профиль остаётся в Unmanic, а внешний инструмент лишь выбирает момент постановки.

API особенно удобен для больших media trees, которые редко меняются. Полный scan такой библиотеки тратит время на повторный FFprobe тысяч уже нормализованных файлов. Если importer способен сам вызвать Unmanic для только что добавленного объекта, нагрузка на storage и CPU становится гораздо предсказуемее.

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

Для большого архива задача сделать HEVC состоит не из одной галочки. Сначала нужно решить, какие исходные codecs вообще следует перекодировать. H.264 обычно имеет смысл рассматривать как кандидата, а HEVC можно пропускать. AV1, MPEG-2, VC-1 и редкие форматы требуют отдельного решения по совместимости клиентов и цене повторного кодирования.

1. Создайте отдельную library или тестовый path с несколькими типичными файлами.
2. Добавьте Video Transcoder и выберите HEVC как целевой codec.
3. Оставьте container без изменения либо явно выберите MKV/MP4 в соответствии с устройствами.
4. Настройте encoder: software для максимального контроля либо доступный hardware encoder для скорости.
5. Не включайте Force Transcode без причины; сначала убедитесь, что уже HEVC-файлы проходят без task.
6. Запустите manual scan и просмотрите Pending Tasks до старта массовой очереди.
7. После первых Completed Tasks проверьте video, audio, subtitles, HDR metadata и воспроизведение на реальном клиенте.

Если медиатека содержит и 1080p, и 4K, один codec target может быть недостаточным. Например, пользователь хочет оставить 1080p в H.264 ради старых клиентов, а 4K переводить в HEVC. Нативного графического branching внутри одной цепочки нет. Официальная документация предлагает псевдоветвление: две libraries указывают на один path, а комплементарные ffprobe-фильтры распределяют файлы по условиям.

Одна library может использовать Limit Library Search by FFprobe Data, а другая — противоположное правило Ignore Files with Matching FFprobe Data. При одинаковом JSONata-условии каждый файл достаётся только одной из цепочек. Это мощный приём, но он сложнее визуального if/else и требует особенно внимательно расставлять File Test.

Что делать с 4K и 10-bit

Если часть библиотеки 10-bit или HDR, нельзя считать, что любой HEVC encoder сохранит все свойства автоматически. Для таких файлов нужен профиль, который поддерживает требуемый bit depth и pixel format, а также корректно сохраняет color metadata. Если аппаратный path не поддерживает вход, лучше отправить только эти файлы в отдельную CPU-library, чем заставлять весь архив работать по самому медленному профилю.

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

Если видео уже удовлетворяет требованиям, не нужно повторно кодировать картинку ради звука. В library можно включить только аудиопроцессоры. Normalise AAC Audio Streams определит AAC-потоки, а видео будет перенесено без видеоперекодирования, если остальные plugins не требуют изменений.

Сначала стоит решить, какие дорожки считать основными. Если файл содержит оригинальный 5.1 AC3 и дополнительный AAC stereo, нормализация AAC затронет только AAC. Если требуется сначала создать AAC, порядок меняется: audio transcoder должен сформировать нужный поток до модуля loudnorm либо цепочка должна быть спроектирована так, чтобы второй plugin получил уже преобразованный cache-output.

Значения Integrated Loudness, LRA и True Peak следует подбирать под практический сценарий, а не копировать без понимания. Для домашнего архива важнее постоянство между эпизодами и отсутствие clipping на клиентах. После нескольких тестов можно включать file monitor и автоматически нормализовать новые поступления.

Практический сценарий: очистка дорожек по языку

Экономия диска от удаления лишнего audio иногда заметна на многодорожечных релизах, но такая автоматизация опаснее простого перекодирования. Metadata языка могут быть пустыми или ошибочными, commentary часто имеет тот же language tag, что и основная дорожка, а forced subtitles могут понадобиться даже при дубляже.

Безопасный pipeline начинается с выборочной проверки ffprobe-данных. Затем включается модуль удаления языков в тестовой library. В Completed Task Details нужно убедиться, какие stream index были сохранены и какие удалены. Только после этого правило переносится на большой каталог.

Если нужно не удалить, а изменить приоритет, лучше использовать Re-order Audio Streams by Language. Он меняет порядок так, чтобы предпочитаемый язык стал первым. Это менее разрушительная операция и проще откатывается повторным remux, если сами потоки были сохранены.

Практический сценарий: записи ТВ и Comskip

Unmanic умеет запускать не только transcoders. В каталоге plugins есть Comskip для обнаружения и разметки рекламных блоков. Типичный pipeline для DVR строится вокруг момента, когда запись закончена: file monitor или внешний API замечает новый файл, filter откладывает слишком свежий материал, затем worker запускает анализ, а дальнейший plugin выполняет нужное действие с результатами.

Для активно записываемых файлов особенно важно не начинать обработку слишком рано. Фильтр по времени изменения предотвращает ситуацию, когда Unmanic видит растущий TS-файл и сразу пытается его читать. Если DVR использует временные части или переименовывает файл в конце записи, лучше ориентироваться на устойчивый финальный path.

После Comskip можно настроить перекодирование или remux, но порядок зависит от инструмента: некоторые анализаторы предпочитают исходный поток, а некоторые post-processing операции меняют таймкоды. Поэтому такой pipeline нужно проверять на реальной записи с несколькими рекламными блоками, а не только на коротком тестовом ролике.

Переименование, перемещение и обновление медиасервера

После изменения codec имя файла иногда перестаёт отражать содержимое. Официальный каталог содержит Rename File, который умеет использовать ffprobe metadata fields, и плагины движения, способные направить итог в другой каталог. Эти действия лучше выполнять после основного transcoding, чтобы новые metadata уже соответствовали финалу.

Если медиатекой управляют Sonarr или Radarr, следует заранее решить, кто является владельцем имени и path. Одновременная политика rename в нескольких программах приводит к гонкам: Unmanic завершил encode и переименовал, медиаменеджер почти сразу вернул собственную схему, а marker ранее обработанного файла может оказаться привязан к старому имени. Чем меньше систем одновременно меняют один path, тем предсказуемее automation.

Notify Plex или аналогичный plugin обновления Jellyfin/Emby разумно ставить в Task Results после финального movement. Тогда медиасервер сканирует уже готовое имя и location. Если уведомить его раньше, он может увидеть временное отсутствие исходника или начать индексировать path до завершения копирования.

Безопасная настройка перед массовым запуском

Unmanic создан для автоматической работы, поэтому ошибка масштаба здесь важнее ошибки одного ручного encode. Неверный Plugin Flow способен последовательно обработать тысячи файлов. Минимальный безопасный подход — отдельная тестовая library с копиями нескольких характерных файлов и сохранённый backup критичных данных.

• Состав выборки. Добавьте H.264, HEVC, разные audio layouts, субтитры, HDR и крупный 4K-файл.
• Проверка File Test. Убедитесь, что уже соответствующие цели файлы не попадают в очередь.
• Проверка cache. Оцените свободное место при выбранном числе workers.
• Проверка результата. Откройте итог на нескольких реальных клиентах, а не только в одном player.
• Проверка движения. Проследите полный путь от cache до финального имени и каталога.
• Проверка повторного scan. После успеха снова просканируйте тестовый каталог: очередь должна остаться пустой.

Отдельно полезно понять поведение неуспешной задачи. Если ошибка появилась при тестировании, посмотрите Completed Task Details, исправьте причину и верните task в Pending. Это позволяет освоить recovery до того, как очередь содержит сотни элементов. Failed records влияют на последующие scans, поэтому их нельзя оставлять без понимания.

Перед длительным запуском стоит временно отключить автоматический File Monitor или увеличить scan interval. Тогда во время настройки очередь будет пополняться только после контролируемого действия. Когда профиль стабилен, автоматическое обнаружение можно вернуть.

Форматы и пределы совместимости

Unmanic не имеет фиксированного списка поддерживаемых видеоформатов в смысле обычного конвертера. Реальная поддержка определяется FFmpeg, выбранным plugin, сборкой среды и конкретным container. Video Transcoder явно работает с H.264, HEVC/H.265 и AV1 как целевыми codec families и позволяет выводить MKV или MP4 либо сохранять исходный container. Аудиоплагины имеют собственные списки.

Такой подход гибче, но требует точнее читать ошибку. Если FFprobe распознал файл, это ещё не гарантирует, что выбранный encoder сможет обработать его pixel format, bit depth или profile. Если encoder умеет кодировать HEVC, это не означает автоматическое сохранение HDR metadata. Если container принимает видеокодек, он может не принимать конкретный subtitle или attachment stream.

Поэтому при редком материале нужно проверять три слоя отдельно: decode входа, encode выбранного stream и mux в целевой container. Сообщения вроде encoder not found, unsupported device, could not write header и incorrect codec parameters указывают на разные слои и требуют разных исправлений.

MKV и MP4

MKV обычно удобнее для сложных многоязычных коллекций, потому что допускает широкий набор audio, subtitles и attachments. MP4 часто удобнее для бытовой совместимости, но имеет более строгие ограничения по некоторым streams и metadata. Выбор нельзя делать только по расширению, если в библиотеке есть PGS, ASS с fonts, редкие audio codecs или data streams.

Remux и transcode

Remux копирует совместимые streams без повторного кодирования и обычно значительно быстрее. Transcode меняет codec и может менять качество. Если цель — только перейти из AVI в MKV или переставить дорожки, повторно кодировать H.264/HEVC бессмысленно. Если же клиент не поддерживает codec, один remux проблему не решит.

Типичные ошибки и их устранение

Файлы не появляются в Pending Tasks

Сначала проверьте, включён ли scanner или file monitor именно у нужной library и существует ли path с точки зрения Unmanic. Затем убедитесь, что к библиотеке добавлен хотя бы один File Test plugin. Если plugins есть, проверьте порядок: ранний Ignore может не пропускать файл до codec-test. Для container-среды дополнительно сверяют volume mapping.

Один и тот же файл постоянно возвращается в очередь

Обычно это означает, что критерий File Test и фактический output не совпадают. Например, plugin требует HEVC, но из-за профиля сохраняется H.264; либо правило смотрит на container, который не меняется. Сравните ffprobe исхода и результата. Если включён Force Transcode, проверьте механизм пометки уже обработанного файла и не меняет ли внешняя система имя сразу после завершения.

Worker показывает неопределённый прогресс

Не всякая команда умеет отдавать parsable progress. Состояние Processing - progress indeterminate само по себе не означает зависание. Разверните worker и смотрите live log. Если там меняются frame, time или другие показатели, процесс продолжается. При полном отсутствии вывода оцените CPU/GPU, I/O и доступность сетевого source.

Permission denied при финальном move

Если encode успешно завершён, а ошибка возникает после него, проверьте destination и права на удаление или rename в исходной директории. В Docker сопоставьте PUID/PGID с владельцем host path. На NFS учитывайте mapping пользователей и server-side permissions. Read-only library несовместима со стандартным overwrite.

No space left on device

Свободное место нужно считать для cache, а не только для media disk. Несколько workers умножают потребление. Очистите незавершённые временные данные только после остановки соответствующих задач, затем уменьшите worker count, перенесите cache на большой диск или настройте tmpfs с адекватным лимитом RAM.

Hardware encoder not found

Проверьте encoder непосредственно в FFmpeg той же среды, где работает Unmanic. На Docker-хосте наличие GPU ещё не доказывает, что он доступен container. Для NVIDIA нужны driver и container runtime, для VAAPI/QSV — device pass-through и подходящие drivers. После этого проверяют выбранный encoder в plugin settings.

Could not write header или Invalid argument

Такая ошибка часто связана с несовместимостью streams и container при remux. Пример: поток можно декодировать, но выбранный container не принимает его в режиме copy. Решение — сменить container, перекодировать проблемный stream либо удалить только действительно ненужный stream. Увеличение muxing queue здесь обычно не помогает.

После изменения global settings ничего не изменилось

Проверьте Library Config конкретного plugin. Локальные значения перекрывают глобальные. Reset Configuration удаляет override. После изменения условий уже стоящие Pending Tasks могут продолжить обрабатываться по новым параметрам, поэтому перед крупной сменой настройки полезно решить, нужно ли очистить очередь.

Failed-файл больше не находится scan

Это ожидаемое поведение, если неуспешная запись осталась в Completed Tasks: такие файлы игнорируются последующими scans и file monitor. Исправьте причину, затем верните task в Pending или удалите failed record, чтобы повторная проверка снова стала возможна.

File Monitor не реагирует на сетевой каталог

Не все network filesystems передают events так же, как локальный диск. Переключитесь на периодический Library Scanner, задайте разумный interval и при необходимости включите one-off scan on startup. API-постановка ещё точнее, если программа-источник может сообщать о новом файле сама.

Queue растёт быстрее, чем workers успевают

Это не обязательно ошибка. Scanner может быстро добавить тысячи кандидатов, а каждый encode занимать десятки минут. Если такой backlog нежелателен, временно поставьте scan на паузу, уменьшите область library либо используйте фильтры по возрасту и типу. Увеличивать worker count стоит только после проверки ресурсов: иначе очередь останется длинной, а сервер станет менее отзывчивым.

После remux пропали субтитры

Проверьте stream mapping и совместимость subtitle codec с output container. Плагин мог намеренно исключить stream, либо FFmpeg не смог поместить его в выбранный format. Если это ASS/SSA, отдельно проверьте attachments с fonts. Для PGS при переходе к MP4 иногда разумнее сохранить MKV или извлечь subtitles отдельно.

После hardware encode изменились цвета

Сравните bit depth, pixel format, color primaries, transfer и matrix до и после. Hardware path мог выбрать другой format или filtergraph. Для HDR проверьте также metadata и поведение реального display. Если профиль не сохраняет необходимые свойства, отправьте такой subset в отдельную library с подходящим encoder.

Настройка производительности

Производительность Unmanic складывается из четырёх независимых этапов: чтение source, собственно processing, запись cache и финальное движение результата. Ускорение только encoder не помогает, если исходник читается по медленному Wi‑Fi или cache находится на перегруженном HDD.

CPU encode

Software x264, x265 и SVT-AV1 способны использовать много потоков внутри одного процесса. Поэтому несколько workers не обязательно ускоряют суммарную очередь. Контролируйте load average, температуру, частоту CPU и скорость каждого encode. Если два workers дают почти ту же суммарную скорость, что один, но сильнее тормозят систему, оставьте один.

GPU encode

Аппаратный encoder освобождает CPU, но может упереться в hardware sessions, decoder, copy engines или VRAM. Слишком много workers также заставляют несколько задач одновременно читать и писать большие файлы. Подбирать число лучше на типичных 4K/1080p источниках, а не на коротком клипе.

Disk и cache

Для SATA HDD случайные параллельные чтения нескольких больших media files могут быть медленнее последовательной обработки. SSD-cache снимает часть записи с media volume, но source всё равно читается оттуда. На NAS часто полезно ограничить workers и держать cache локально на encoder-машине.

Сеть

При Linked Installations сравните bitrate transfer и скорость обработки. Если GPU пережёвывает файл быстрее, чем он передаётся, worker будет простаивать. Remote preloading смягчает задержку, но не отменяет фундаментальный лимит сети. Shared storage может быть эффективнее, если оба узла имеют быстрый доступ к одному NAS.

Память

RAM расходует не только Unmanic. FFmpeg, hardware drivers, OS cache и tmpfs делят одну память. При RAM-cache рабочие файлы могут занимать гигабайты, поэтому число workers следует выбирать с запасом. OOM-kill внешнего процесса выглядит как внезапный failed task и требует анализа system log, а не только FFmpeg output.

Доступ к интерфейсу и защита

Web UI предназначен для конфигурации и мониторинга работающего Unmanic. Если интерфейс открыт только в домашней LAN, обычно достаточно сетевых ограничений. Публиковать порт напрямую в интернет без дополнительной защиты не следует. Для внешнего доступа разумнее reverse proxy с TLS, authentication и ограничением источников.

В интерфейсе есть вход, связанный с учётной системой проекта и supporter-функциями, но его не следует путать с универсальной защитой самого HTTP endpoint. Для remote links документация прямо рассматривает reverse proxy как способ добавить authentication.

Plugins тоже являются частью модели доверия. Они могут запускать внешние команды, менять файлы и обращаться к сети. Официальный repository снижает риск случайных несовместимостей, однако любые custom sources стоит рассматривать как исполняемый код и устанавливать только из доверенных мест.

Для серверов с внешним reverse proxy стоит также ограничить доступ к API, потому что он позволяет создавать задачи. Ошибочная или неавторизованная постановка множества файлов может загрузить CPU/GPU так же сильно, как ручной запуск большого scan.

Когда нужны две библиотеки на одном пути

Возможность указывать один folder в нескольких libraries сначала выглядит лишней, но это основной способ разделить pipeline по условиям. Например, одна library берёт только 4K-файлы и назначает NVENC HEVC, другая берёт 1080p и оставляет H.264. Ещё один вариант — отдельно обрабатывать фильмы и файлы с конкретным audio codec, если они физически лежат в общем каталоге.

Ключевая задача — сделать filters взаимно исключающими. Если оба File Test flows могут захватить один файл, он попадёт в разные очереди и рискует обрабатываться повторно. Комбинация include/ignore на одном ffprobe-условии как раз создаёт две стороны одного логического branch.

При таком дизайне названия libraries, tags и worker groups стоит выбирать системно. Например, movies-4k-gpu и movies-1080p-cpu позволяют сразу увидеть назначение, а теги gpu и cpu-only не дают tasks уйти не на тот hardware pool.

Две libraries на одном path полезны и без разных codecs. Одна может заниматься только files older than определённого срока, другая — новыми поступлениями; одна — language cleanup, другая — images или sidecar files. Но если conditions пересекаются, автоматизация становится трудно предсказуемой. Простая схема с минимальным числом пересечений надёжнее.

Разбор одного задания от File Test до финального результата

Полезно представить полный путь одного файла. Допустим, в library появляется фильм в MKV с H.264-видео, двумя аудиодорожками и субтитрами. File Monitor фиксирует изменение и передаёт path в File Test. Первый фильтр проверяет возраст файла и пропускает его, потому что запись уже стабильна. Второй проверяет codec и требует task, так как целевое правило — HEVC. На этом тестирование прекращается, и путь появляется в Pending Tasks.

Свободный worker забирает task. Каждый Processing plugin получает текущий input и решает, нужен ли ему action. Video Transcoder видит H.264 и создаёт HEVC-output в cache. Следующий audio plugin обнаруживает, что первая дорожка уже соответствует policy и ничего не делает, а plugin языка удаляет ненужную вторую дорожку из следующего output. Если затем идёт subtitle operation, она получает уже изменённый container из cache, а не исходный source.

После Worker stage система имеет финальный cache-file. File Movement либо выполняет стандартную замену исходника, либо следует правилам mover-plugin. Task Results записывает metrics и отправляет refresh медиасерверу. Только после этого task считается полностью завершённым. Такой пошаговый разбор помогает понять, почему порядок plugins важен даже тогда, когда каждый отдельный модуль настроен правильно.

Если один из Worker Process plugins завершается ошибкой, успешный post-processing результата не должен подменить исходник. В Completed Tasks появится Failed, а рабочий cache будет очищен. Если ошибка произошла уже при movement, нужно изучать права и destination отдельно: media transformation могла закончиться корректно, но операция размещения не удалась.

Как читать FFmpeg-команду из журнала Unmanic

Completed Task Details и раскрытый worker log показывают фактическую команду, которую собрал plugin. Даже без глубокого знания FFmpeg полезно читать её по блокам. До -i находятся общие и input options. После input указываются -map, codecs и stream-specific параметры. В конце располагается output path в cache. Если ошибка касается не того audio stream, первым делом проверяют mapping. Если encoder неизвестен — значение -c:v или -c:a. Если muxer ругается на header — сочетание streams и output container.

Параметр max_muxing_queue_size влияет на очередь пакетов во время mux и иногда помогает при материалах с необычным числом streams или временными характеристиками. Но его увеличение не лечит несовместимый codec/container, не исправляет повреждённый input и не добавляет отсутствующий hardware encoder. Это параметр, который стоит менять только после того, как log указывает именно на проблему muxing queue.

При custom options полезно сначала оставить одну минимальную модификацию. Набор из десяти flags затрудняет диагностику: неизвестно, какой именно изменил mapping или filtergraph. После успешной проверки следующий параметр добавляют отдельно. Такой метод особенно важен в автоматическом pipeline, где одна ошибка масштабируется на всю очередь.

Порядок plugins: частые логические ошибки

Первая ошибка — ставить преобразующий критерий раньше исключения. Если общий codec-test сразу создаёт task, поздний filter по resolution уже не увидит файл. В File Test сначала должны находиться правила, которые сужают область: ignore свежие, исключить extension, ограничить resolution или library subset, и только затем — условия, которые требуют работу.

Вторая ошибка — удалять данные до их использования. Если notification или rename опирается на исходные metadata, а предыдущий plugin их удалил, последующий шаг получит уже другую картину. Для subtitles похожая ситуация: извлечение наружу должно идти до удаления embedded stream.

Третья ошибка — обновлять медиасервер до File Movement. Refresh должен сообщать уже окончательный path. Иначе сервер может удалить старую карточку, увидеть промежуточное отсутствие файла и только потом заново обнаружить новый. На больших библиотеках это увеличивает лишние scans.

Четвёртая ошибка — сочетать два plugins, которые оба пытаются принять окончательное решение о placement. Post-processor File Movement может переопределять стандартное поведение, а порядок определяет, какой модуль последним меняет destination. Если нужны два движения, стоит заранее описать конечную структуру и убедиться, что второй шаг не отменяет первый.

Пятая ошибка — заставлять один и тот же media stream перекодироваться несколько раз в одной цепочке. Если первый plugin уже создал HEVC, а следующий снова кодирует видео ради изменения filter, возникает лишнее lossy-поколение. По возможности операции над одним video stream лучше объединять в одном FFmpeg pass либо проверять, что второй plugin использует stream copy.

Как планировать изменение большой медиатеки

Перед многосуточной очередью стоит оценить объём. Количество файлов умножается на среднее время encode и делится на эффективное число workers. Это не точный прогноз, но показывает порядок величины. Если один 45-минутный эпизод кодируется 20 минут, тысяча эпизодов при одном worker — сотни часов. Hardware encoder может резко сократить время, но тогда bottleneck может перейти в storage.

Имеет смысл разделить проект на фазы. Сначала самые старые или самые большие файлы, потом основная масса, после — исключения. Unmanic не требует делать это вручную, если создать несколько libraries с filters и tags. Так можно направить тяжёлые 4K tasks на GPU-группу, а короткие SD — на CPU pool, сохранив единую панель наблюдения.

При длительной миграции не следует каждый день менять codec profile. Иначе библиотека окажется неоднородной, а сравнивать metrics станет трудно. Лучше сначала зафиксировать профиль на тестовой выборке, затем выполнить определённый batch и только после этого пересматривать параметры.

Если конечная цель — экономия места, сохраняйте не только суммарный процент уменьшения, но и список файлов, которые выросли. Некоторые sources уже эффективно сжаты, и повторный encode в другом codec может дать мало выигрыша или даже увеличение. File Size Metrics помогает увидеть такие исключения.

Для очень большого каталога удобен постепенный запуск scanner. Можно временно ограничить library path подкаталогом, обработать его, затем расширить область. Альтернатива — filters по дате или свойствам. Такой подход уменьшает размер Pending Tasks и упрощает возврат к конкретной фазе после ошибки.

HDR, 10-bit и нестандартные pixel formats

Unmanic передаёт media-обработку FFmpeg и encoder plugins, поэтому HDR и 10-bit нельзя считать автоматической гарантией только по названию HEVC. Hardware encoder должен поддерживать нужный bit depth и pixel format, а цепочка должна сохранить или корректно преобразовать color metadata. Неправильный профиль может дать файл, который формально воспроизводится, но имеет неверные цвета или потерянные HDR-признаки.

Для HDR-теста выбирайте реальный файл с проверяемыми metadata и client, который показывает режим вывода. После обработки сравните stream metadata до и после. Если plugin использует scaling/filter, убедитесь, что он поддерживает нужный bit depth. Software и hardware paths могут строить filtergraph по-разному.

То же относится к 4:2:2, 4:4:4 и редким camera formats. Бытовые NVENC/QSV profiles часто ориентированы на проигрываемые 4:2:0 варианты. Если задача архивная, прежде чем массово преобразовывать такие файлы, определите, нужно ли сохранить профессиональный chroma format или допустим delivery-oriented output.

Проверка одного HDR-файла недостаточна, если в collection встречаются HDR10, Dolby Vision, HLG или разные bit depths. Не каждый pipeline одинаково обрабатывает динамические metadata. Для сомнительных типов безопаснее создать отдельную library с Ignore filter и не трогать их, пока не выбран проверенный профиль.

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

Главная соблазнительная метрика после HEVC или AV1 — процент освобождённого места. Но два профиля одинакового размера могут давать разное качество из-за encoder, preset, source noise, grain и разрешения. Более того, старый материал с шумом плохо сжимается: агрессивный encoder может тратить bitrate на grain либо сглаживать его.

Поэтому File Size Metrics полезен как операционная статистика, а не как единственный критерий. Для настройки нужна визуальная выборка сложных сцен: движение, тёмные gradients, grain, титры, анимация. Если целевые clients транскодируют новый codec обратно, экономия диска может обернуться дополнительной нагрузкой медиасервера.

Разумный профиль — компромисс между storage, Direct Play и временем processing. Unmanic автоматизирует применение этого решения, но не может выбрать компромисс вместо владельца библиотеки. Особенно опасно оптимизировать только по размеру и забывать, что повторное lossy-кодирование уже сжатого source необратимо.

Резервное копирование и откат

Стандартный успешный workflow заменяет source. Это удобно для освобождения места, но означает, что undo не является встроенной кнопкой. Если исходный материал ценен, backup должен существовать до массовой обработки. Особенно это касается домашнего видео, редких записей и sources, которые нельзя заново получить.

Для миграции можно временно настроить movement в отдельный destination и сравнить результаты с originals. Это требует вдвое больше места, зато позволяет сделать объективную проверку до удаления source. После утверждения профиля pipeline можно изменить на inplace replacement.

Не стоит считать cache резервной копией. Это временное рабочее пространство, которое очищается после task или ошибки. И не стоит рассчитывать на Completed Tasks как на копию файла: история хранит сведения и logs, но не восстанавливает media content.

Если backup выполняется внешней системой snapshot-ов, важно понимать момент их создания. Snapshot до массового scan даёт понятную точку возврата. Snapshot в середине многодневной миграции содержит смесь обработанных и исходных файлов и сложнее для выборочного restore.

Организация нескольких libraries и имён

Когда libraries больше двух-трёх, произвольные названия мешают. Полезна схема тип-контента_условие_исполнитель: например, movies_4k_gpu, tv_1080_cpu, recordings_comskip. Тогда tags могут повторять последний компонент, а Linked Installations легче сопоставлять по назначению.

Если remote setup требует совпадения library name, имя становится частью инфраструктуры. Менять его нужно осознанно на обеих сторонах. Path при этом может отличаться, если используется transfer, но logical library должна быть однозначно сопоставлена.

Отдельные libraries удобны и для разных post-processing policies. Фильмы могут уведомлять Plex, музыка — другой индексатор, а архивные материалы — вообще не вызывать внешний refresh. Это чище, чем пытаться заставить один огромный flow принимать все решения.

При экспорте и импорте настроек library удобно переносить готовую конфигурацию на другой узел, но после импорта всё равно нужно проверить path, hardware-specific options и доступность plugins. Конфигурация, созданная на NVIDIA-машине, не становится автоматически подходящей для AMD или CPU-only host.

Логи и последовательная диагностика

При проблеме сначала определите стадию: discovery, File Test, queue, worker processing, movement или results. Если файл не появляется нигде — бессмысленно анализировать encoder. Если worker успешно пишет output, но task становится Failed после этого — вероятнее post-processing. Такое разделение сокращает поиск причины.

На discovery-уровне проверяют path, scanner, monitor и права чтения. На File Test — plugin order и conditions. На queue — наличие idle workers и tags. На processing — фактическую command line, device и codec. На movement — права записи, свободное место и mounts. На results — network notifications и сторонние services.

Expanded worker log полезен для live-диагностики, а Completed Task Details — после завершения. Если проблема повторяется только на одном media file, сравните его ffprobe с успешным. Часто причина обнаруживается в редком subtitle stream, unusual channel layout, profile или damaged packet.

Для повторяемой ошибки полезно уменьшить pipeline до одного подозреваемого plugin. Если task проходит, возвращайте modules по одному. Это быстрее, чем менять несколько параметров одновременно и потом не понимать, что именно помогло.

External Script и собственная автоматизация

В official plugin catalog есть External Script, который позволяет запускать Python, Node или Bash-код против файла. Это мост между Unmanic и специфической инфраструктурой: можно вызвать собственную проверку, подготовить sidecar, передать данные внутренней системе или выполнить операцию, для которой нет готового plugin.

Скрипт получает ту же силу, что и ручная команда на сервере, поэтому ошибки в path handling особенно опасны. Он должен корректно обрабатывать spaces, Unicode и специальные символы, возвращать предсказуемый exit code и писать понятный log. Если script создаёт новый media output, нужно явно определить, кто отвечает за его movement и удаление source, чтобы не дублировать обязанности Unmanic.

Для сетевых вызовов важны timeouts. Зависший request внутри script может удерживать worker, хотя media processing уже закончился. Уведомления обычно лучше выполнять в Task Results, где сбой внешнего сервиса легче отделить от собственно transcoding.

Проверка повторяемости pipeline

Хороший автоматический профиль должен быть идемпотентным в практическом смысле: после успешной обработки повторный File Test не должен требовать того же преобразования снова. Это проверяется повторным scan тестового каталога. Если очередь снова наполняется теми же файлами, критерий результата и критерий тестирования расходятся.

Причиной может быть потерянная metadata, rename внешней программой, container, который не сохраняет служебный marker, или plugin, проверяющий другой stream, чем тот, который меняет worker. Решать проблему нужно на уровне логики, а не просто увеличивая interval scanner.

Идемпотентность особенно важна для Force Transcode и custom scripts. Любая операция, намеренно меняющая уже соответствующий файл, должна иметь свой способ понять, что повторять её не нужно.

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

Программа	Лучше подходит для	Главное ограничение
Unmanic	Постоянной автоматической обработки библиотек через plugins, scanner, file monitor и workers	Нет обычного визуального ветвления if/else внутри одной цепочки
Tdarr	Распределённого media transcoding и health-check больших библиотек с узлами и plugin stacks	Конфигурация сложнее для простой одиночной медиатеки
FileFlows	Визуального построения условных file flows с ветвями и большим числом типов обработки	Для простого слежения и перекодирования граф может быть избыточным
FFmpeg Batch AV Converter	Пакетного запуска FFmpeg-профилей над выбранным набором файлов	Меньше ориентирован на постоянный server-side контроль библиотеки
HandBrake	Ручного и очередного перекодирования видео с понятными preset-профилями	Не строит постоянный plugin-driven pipeline для каталога

Если цель — один раз перекодировать папку, Unmanic может оказаться сложнее HandBrake или пакетной оболочки над FFmpeg: сначала нужно понять libraries, plugins и очередь. Если задача постоянная — автоматически приводить пополняемую медиатеку к правилам, удалять ненужные streams, запускать post-processing и распределять workers, его архитектура становится преимуществом.

Tdarr ближе всего по идее массовой автоматизации и распределённых nodes. FileFlows выигрывает там, где пользователю нужен явный граф условий и ветвлений. FFmpeg Batch AV Converter полезнее при пакетной работе, когда оператор сам формирует список файлов и хочет быстро прогнать один профиль. HandBrake проще для ручной очереди с preset-подходом, но не заменяет постоянный watcher и plugin pipeline.

Выбирать стоит не по одному списку codecs — несколько решений используют FFmpeg, — а по модели управления. Unmanic подходит тем, кто хочет держать правила рядом с libraries и собирать обработку из небольших plugins. Если главный критерий — сложные визуальные if/else, удобнее FileFlows. Если нужен распределённый transcoding с сильным акцентом на media health и node pools, логичнее Tdarr.

Ограничения, которые нужно учитывать заранее

Нет полноценного branch-редактора. Plugin Flow линейный по стадиям. Условное разделение реализуется File Test filters, отдельными libraries и при необходимости JSONata/ffprobe-правилами. Для простого pipeline этого достаточно, но сложная матрица условий становится труднее для чтения.

Функциональность зависит от plugins. Ядро не содержит отдельную кнопку для каждого codec или медиасценария. Перед настройкой нужно найти подходящий plugin, установить его, назначить library и проверить совместимость. Это даёт гибкость, но требует больше дисциплины, чем монолитный конвертер.

Ошибки storage проявляются на разных стадиях. Encode может пройти успешно, а финальный move упасть из-за прав, network mount или свободного места. Source, cache и destination нужно рассматривать как три части одной задачи.

Автоматизация усиливает последствия неверного правила. Если File Test ошибочно считает тысячи файлов кандидатами, workers будут последовательно выполнять это решение. Наличие тестовой library и backup важнее, чем при программе, где каждый encode запускается вручную.

Некоторые параметры требуют знаний FFmpeg. Базовые поля закрывают типовые случаи, но custom options, filtergraphs, stream mapping и hardware-specific значения остаются техническими. Неверная command line не становится безопаснее только потому, что введена через GUI.

Кому подходит Unmanic

Программа хорошо соответствует домашним серверам, NAS и небольшим инфраструктурам, где файлы добавляются постоянно и должны автоматически приходить к единой policy. Особенно сильны сценарии положил файл — через некоторое время он уже в нужном codec/container, новые DVR-записи проходят проверку, лишние языки удаляются, после завершения обновляется медиасервер.

Она также удобна тем, кто предпочитает разделять ответственность: один plugin отвечает за video, другой за audio, третий за names и movement, четвёртый за notification. При изменении одного требования не нужно заново проектировать весь процесс.

Для редких разовых конвертаций установка server-oriented окружения и создание library будут лишними. В таком случае обычный encoder с ручной очередью проще. Unmanic раскрывается именно на повторяемой policy, когда один раз настроенный pipeline должен применяться к файлам неделями и месяцами.

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

Unmanic сам выбирает, какие файлы перекодировать?

Решение принимают File Test plugins в конкретной library. Scanner или monitor только обнаруживают файл. Например, Video Transcoder может проверить codec и поставить task, если он не совпадает с целевым. Другие plugins могут фильтровать по ffprobe-данным, возрасту, extension или иным условиям.

Можно ли оставить исходник и писать результат в другой каталог?

Да, если настроить подходящий File Movement plugin и не использовать стандартную замену source как единственный вариант. Нужно отдельно проверить, сохраняется ли структура подкаталогов, как формируется имя и что происходит с оригиналом.

Можно ли использовать несколько GPU-машин?

Linked Installations позволяют отправлять tasks другим Unmanic-узлам. На принимающей стороне нужна соответствующая library и plugin stack. Если storage общий, remote может работать по path; иначе используется transfer файлов.

Нужно ли постоянно держать browser открытым?

Нет. Web UI нужен для настройки и наблюдения, а scanner, workers и plugins выполняются процессом Unmanic. Закрытие вкладки не останавливает активную обработку.

Можно ли полностью отключить scanner?

Да. Для library можно не включать periodic scan и использовать file monitor либо API. На remote-target library самостоятельное обнаружение отключается, а задачи поступают с другого узла.

Что произойдёт при ошибке FFmpeg?

Worker пометит task как Failed, исходный файл не заменяется успешным результатом, а запись появляется в Completed Tasks. Подробный log помогает найти причину. Для повторной попытки после исправления task нужно вернуть в Pending или удалить failed record.

Можно ли использовать только remux без повторного сжатия?

Да, если поставить plugin, который копирует streams и меняет container или структуру без video re-encode. Нужно помнить, что не каждый stream совместим с каждым container; в таком случае FFmpeg может отказать на этапе mux.

Можно ли разделить GPU и CPU задачи?

Да. Назначьте libraries и Worker Groups соответствующими tags. Task берётся group при совпадении хотя бы одного тега; без tags работают соответствующие нетегированные pairs.

Можно ли обрабатывать один folder разными правилами?

Да. Несколько libraries могут указывать на один path. Чтобы файл не обрабатывался дважды, условия File Test должны разделять наборы. Для сложных случаев используют взаимно противоположные ffprobe/JSONata filters.

Где искать причину странного результата?

Начните с Completed Task Details: там видны commands и logs. Затем сравните настройки plugin на уровне library и Global Config, порядок Plugin Flow и фактический ffprobe результата. Если проблема возникает после encode, проверяйте post-processing и movement.

Можно ли писать собственные plugins?

Да. Plugin — Python-module, который подключается к определённым runner stages. Поддерживаются file test, worker processing, file movement, task results, data panels, plugin API и event runners. Собственный repository можно добавить в Plugin Installer.

Что лучше для большой сетевой библиотеки: monitor или scan?

Если файловая система надёжно передаёт events, monitor экономит полные обходы. Для NFS/CIFS и иных network mounts периодический scanner часто предсказуемее. Самый точный вариант — API, когда внешний importer сам сообщает о новом path.

Итоговая схема настройки

Надёжная конфигурация Unmanic строится снизу вверх. Сначала должен быть доступен storage: правильные volume mounts, permissions, cache и свободное место. Затем создаётся library и выбирается способ обнаружения. После этого устанавливаются plugins, выстраивается File Test, затем Worker Process и post-processing. Workers и hardware acceleration имеет смысл увеличивать после того, как один тестовый файл проходит весь путь без ошибок.

Критерий готовности к автоматическому режиму простой: повторный scan уже успешно обработанной тестовой выборки не создаёт неожиданные tasks, Completed Tasks показывают предсказуемый результат, медиасервер видит файлы в правильных местах, а cache и ресурсы выдерживают выбранный parallelism. После этого Unmanic можно оставлять работать по scanner, file monitor или API без постоянного ручного контроля.