MiniDLNA (ReadyMedia) и конкуренты

Зачем вам домашний медиасервер, если есть стриминг

Я помню тот вечер, когда после трёх часов танцев с настройками роутера, телевизионной приставки и ноутбука наконец увидел на экране телевизора фильм, запущенный с домашнего сервера. Без подписок, без рекламы, без ожидания буферизации на 480p, когда провайдер решил «оптимизировать» канал. Просто файл с жёсткого диска, переданный по локальной сети на устройство в соседней комнате.

С тех пор прошло много лет, но задача не потеряла актуальности. Наоборот: домашние коллекции фильмов, сериалов, музыки и фотографий растут, устройства множатся, а желание держать всё под контролем — без облаков, без ежемесячной платы, без привязки к экосистеме одного вендора — только крепнет. И именно здесь на сцену выходит DLNA/UPnP — протокол, которому уже больше двадцати лет, но который по-прежнему остаётся самым универсальным способом передать медиафайл с одного устройства на другое без установки клиентских приложений.

Эта статья — подробный разбор MiniDLNA (он же ReadyMedia) как самого лёгкого и неприхотливого DLNA-сервера для Linux, а также честное сравнение со всеми реальными конкурентами: от минималистичных демонов до полноценных медиасерверов с веб-интерфейсом, транскодированием на лету и мобильными клиентами. Я расскажу, что выбрать для конкретной ситуации, где каждый вариант ломается, и какие неочевидные подводные камни ждут при настройке. Информация актуальна на сентябрь 2026 года.

Что такое DLNA и UPnP: краткий ликбез без занудства

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

UPnP (Universal Plug and Play) — это набор сетевых протоколов, позволяющий устройствам в локальной сети автоматически обнаруживать друг друга и обмениваться данными без ручной настройки. Разработан альянсом компаний в конце 1990-х, формализован в начале 2000-х. Внутри UPnP работает несколько механизмов:

• SSDP (Simple Service Discovery Protocol) — мультикаст-объявления на адресе 239.255.255.250, порт 1900. Устройство кричит в сеть: «Я тут, я умею вот это».
• SOAP — обмен управляющими командами поверх HTTP в формате XML.
• Eventing (GENA) — подписка на изменения состояния устройства.

DLNA (Digital Living Network Alliance) — это не отдельный протокол, а набор рекомендаций и профилей поверх UPnP, описывающих, какие форматы медиафайлов устройство обязано уметь воспроизводить, как их передавать и транскодировать. Альянс DLNA был основан в 2003 году, а в 2017-м формально прекратил сертификацию новых устройств. Но сам стандарт никуда не делся: его реализация зашита в телевизоры, игровые приставки, Blu-ray-плееры, медиаприставки и даже в некоторые принтеры.

Когда вы видите в настройках телевизора пункт «Медиасерверы» или «Источники», а там появляется значок с именем вашего Linux-сервера — это и есть работа DLNA/UPnP. Телевизор через SSDP узнал, что в сети появился сервер, запросил у него список контента по SOAP, получил XML-каталог и теперь может запросить конкретный файл.

Важно понимать ограничение: DLNA — это протокол потоковой передачи и каталогизации. Он не предназначен для управления библиотекой, хранения метаданных, постеров или субтитров в удобном виде. Всё это делают конкретные серверы уже поверх протокола, и именно по качеству этой надстройки они различаются.

MiniDLNA: история, философия и место в экосистеме

Откуда взялось название

Проект появился в 2008 году. Его автор — Джастин Маггард, инженер компании Netgear. Задача была конкретной: создать лёгкий, нетребовательный к ресурсам DLNA-сервер для сетевых хранилищ линейки ReadyNAS. Отсюда и двойное имя: для разработчиков и в репозиториях — MiniDLNA, для пользователей продукции Netgear — ReadyMedia.

Когда Netgear потеряла интерес к активной разработке, проект перешёл в руки сообщества и живёт на SourceForge. Релизы выходят нечасто, но стабильно. К 2026 году последняя стабильная ветка включает поддержку современных кодеков, исправления безопасности и совместимость с актуальными версиями FFmpeg и библиотек.

Философия MiniDLNA

MiniDLNA сознательно сделан максимально простым. Один бинарный файл, один конфигурационный файл, один системный пользователь. Никакой базы данных в привычном смысле — сервер сканирует указанные директории, строит внутренний каталог в памяти или в небольшом файле кэша, и отдаёт его клиентам по UPnP. Нет веб-интерфейса. Нет управления пользователями. Нет транскодирования. Нет плагинов.

Это не недостаток — это осознанный выбор. Для задач «раздать фильмы на телевизор и приставку в домашней сети» ничего больше и не нужно. Сервер потребляет 10–30 мегабайт оперативной памяти, не нагружает процессор и стабильно работает месяцами без перезагрузки.

Что умеет и чего не умеет MiniDLNA

Умеет:

• Сканировать папки с видео, аудио и изображениями.
• Строить дерево каталогов по папкам или по метаданным (теги для музыки, названия файлов для видео).
• Отдавать файлы по HTTP с поддержкой Range-запросов (перемотка).
• Автоматически обнаруживаться в сети по SSDP.
• Пересканировать библиотеку по расписанию или по команде.
• Работать с JPEG, MP3, FLAC, AAC, WAV, OGG, AVI, MKV, MP4, MPEG-TS, WMA, WMV и рядом других форматов.
• Поддерживать несколько сетевых интерфейсов.
• Вести минимальный лог.

Не умеет:

• Транскодировать медиа на лету. Если телевизор не понимает MKV с кодеком HEVC — он его не воспроизведёт через MiniDLNA.
• Управлять библиотекой через веб-интерфейс.
• Хранить обложки, описания, рейтинги.
• Работать с субтитрами в контейнере (только как отдельный файл, и то не на всех клиентах).
• Ограничивать доступ по пользователям или паролям.
• Работать с плейлистами как с единым объектом.

Установка и базовая настройка

На большинстве дистрибутивов пакет называется minidlna или minidlna-server.

Для Debian и Ubuntu:

sudo apt update
sudo apt install minidlna

Для Fedora и RHEL-подобных:

sudo dnf install minidlna

Для Arch Linux:

sudo pacman -S minidlna

Основной конфигурационный файл — /etc/minidlna.conf. Вот минимально рабочий пример с комментариями:

# Порты и сеть
port=8200
network_interface=eth0

# Пользователь, от которого работает сервис
user=minidlna

# Каталоги: A — аудио, V — видео, P — изображения
media_dir=V,/srv/media/movies
media_dir=V,/srv/media/series
media_dir=A,/srv/media/music
media_dir=P,/srv/media/photos

# Имя сервера в сети
friendly_name=Home Media Server

# Путь к базе данных (кэш каталога)
db_dir=/var/lib/minidlna

# Путь к логам
log_dir=/var/log

# Уровень логирования: fatal, error, warn, info, debug
log_level=info

# Автоматическое обнаружение новых файлов
inotify=yes

# Интервал пересканирования в секундах (0 — только inotify)
notify_interval=600

# Поддержка субтитров
enable_subtitles=yes

После правки конфига:

sudo systemctl restart minidlna
sudo systemctl enable minidlna

Первое сканирование большой библиотеки может занять от нескольких минут до часа. Для принудительного пересканирования без перезапуска демона:

sudo minidlnad -R

или перезапуск сервиса с флагом пересборки базы:

sudo systemctl restart minidlna

Тонкости конфигурации, о которых молчат мануалы

За годы эксплуатации я собрал коллекцию граблей, на которые наступают почти все:

Права доступа. Пользователь minidlna должен иметь право на чтение всех файлов в указанных директориях. Если медиа лежат на примонтированном NTFS-разделе, убедитесь, что монтирование выполнено с параметрами, дающими доступ на чтение: uid=minidlna,gid=minidlna,umask=022 или хотя бы umask=000.

inotify и лимиты. При большом количестве файлов (десятки тысяч) ядро может упереться в лимит fs.inotify.max_user_watches. Проверяется командой cat /proc/sys/fs/inotify/max_user_watches. Если значение меньше 65536, увеличьте его в /etc/sysctl.conf:

fs.inotify.max_user_watches=131072

Жёсткие ссылки и символические ссылки. По умолчанию MiniDLNA не следует по симлинкам. Если ваша библиотека организована через символические ссылки, добавьте в конфиг wide_links=yes.

Несколько сетевых интерфейсов. Если сервер подключён и к проводной сети, и к Wi-Fi, укажите оба: network_interface=eth0,wlan0. Но помните: мультикаст через Wi-Fi часто работает нестабильно из-за особенностей беспроводных сетей.

Проблема с именами файлов. Некоторые телевизоры некорректно обрабатывают кириллицу в именах файлов. Если вместо названия фильма видите кракозябры — переименуйте файлы латиницей.

Производительность и ресурсы

На тестовой конфигурации (процессор Intel Celeron J4125, 8 ГБ RAM, библиотека 4200 фильмов общим объёмом 6 ТБ) MiniDLNA после первоначального сканирования потребляет около 22 МБ оперативной памяти. Нагрузка на CPU в режиме ожидания — ноль. При отдаче одного потока — доля процента. Это делает его идеальным для маломощных устройств: Raspberry Pi, старые неттопы, одноплатники на ARM.

Первоначальное сканирование 4200 файлов заняло около 18 минут. Повторное сканирование без изменений — 4 секунды.

Конкуренты и альтернативы: полный ландшафт 2026 года

Теперь переходу к главному вопросу: что ещё существует, кроме MiniDLNA, и в каких случаях стоит выбрать что-то другое. Рынок медиасерверов для Linux к 2026 году стабилизировался, но вариантов по-прежнему много, и они сильно различаются по философии.

Jellyfin: свободный медиасервер с полным набором функций

Что это. Полноценный медиасервер с веб-интерфейсом, транскодированием, управлением пользователями, поддержкой субтитров, метаданных и обложек. Полностью свободный, без премиум-функций и подписок. Форк проекта Emby, созданный в 2018 году после того, как разработчик Emby закрыл исходный код и ввёл платные функции.

Архитектура. Серверная часть написана на C# (.NET), работает на Linux, Windows, macOS. Клиенты — веб-браузер, приложения для Android, iOS, Android TV, Fire TV, Roku, LG WebOS, Samsung Tizen. Есть плагины для Kodi и VLC.

Установка на Linux. Для большинства дистрибутивов есть пакеты в репозиториях сообщества. Универсальный способ — через официальный репозиторий:

# Добавление репозитория и установка (Debian/Ubuntu)
sudo apt install jellyfin

После установки сервер доступен на порту 8096. Первый запуск открывает мастер настройки: создаёте администратора, указываете папки с медиа, выбираете язык метаданных.

Сильные стороны:

• Полностью свободен, нет платных функций и ограничений.
• Активное сообщество, регулярные обновления.
• Транскодирование на лету через FFmpeg с аппаратным ускорением (VAAPI, NVENC, QSV).
• Автоматическое скачивание постеров, описаний, рейтингов из TMDB, TVDB, MusicBrainz.
• Управление пользователями с правами и ограничениями.
• Поддержка live TV через TVHeadend или IPTV-плагины.
• Мобильные клиенты с офлайн-режимом.
• Плагины расширяют функциональность.

Слабые стороны:

• Потребляет 200–500 МБ оперативной памяти в базовой конфигурации.
• Транскодирование нагружает CPU/GPU.
• Настройка сложнее, чем у MiniDLNA: нужно понимать, что такое контейнер, кодек, битрейт.
• На слабых устройствах (одноядерный ARM без аппаратного декодера) транскодирование невозможно, а прямое воспроизведение зависит от клиента.
• Не все телевизоры поддерживают клиентское приложение.

Когда выбирать: если нужен красивый интерфейс, управление библиотекой, доступ для нескольких пользователей, транскодирование для разных устройств. Фактически это замена Plex без подписки.

Plex: коммерческий стандарт домашних медиасерверов

Что это. Самый известный и «отполированный» медиасервер. Работает с 2008 года. Серверная часть бесплатна для базового использования, но мобильные приложения, аппаратное транскодирование и ряд функций требуют подписки Plex Pass.

Архитектура. Проприетарный сервер (закрытый код), клиентские приложения для всех мыслимых платформ. Облачная инфраструктура для удалённого доступа, синхронизации метаданных, рекомендаций.

Установка на Linux. Официальный пакет .deb или .rpm, также доступен в формате snap. После установки — веб-интерфейс на порту 32400.

Сильные стороны:

• Лучший пользовательский опыт «из коробки». Настройка занимает 10 минут.
• Отличное транскодирование с аппаратным ускорением.
• Огромная база метаданных, автоматическое распознавание контента.
• Клиенты для всех платформ, включая игровые приставки и умные телевизоры.
• Удалённый доступ без настройки проброса портов.
• Подкасты, музыка, фотографии в одном интерфейсе.

Слабые стороны:

• Закрытый исходный код. Вы не знаете, что сервер делает с вашими данными.
• Часть функций за платной подпиской.
• Сервер требует интернет для первичной настройки и активации.
• Потребление ресурсов выше, чем у Jellyfin: 300–800 МБ RAM.
• Телеметрия. Куда и что отправляется — до конца неясно.
• При удалении аккаунта или закрытии сервиса вся инфраструктура теряет смысл.

Когда выбирать: если важна простота, «чтобы просто работало», и вас устраивает зависимость от чужого облака. Для тех, кто не хочет разбираться в настройках.

Emby: предшественник и конкурент Jellyfin

Что это. Тот самый проект, из которого вырос Jellyfin. После 2018 года стал частично проприетарным: ядро открыто, но премиум-функции (аппаратное транскодирование, мобильные приложения, плагины) требуют подписки.

Архитектура. Аналогична Jellyfin (C#/.NET), но с коммерческой моделью.

Сильные стороны:

• Зрелый, отточенный интерфейс.
• Хорошая поддержка DLNA/UPnP «из коробки» — не нужно ставить отдельный сервер.
• Стабильная работа с экзотическими форматами.

Слабые стороны:

• Платные функции там, где у Jellyfin они бесплатны.
• Меньшее сообщество, чем у Plex и Jellyfin.
• Меньше плагинов.

Когда выбирать: если вы уже использовали Emby до 2018 года и привыкли к интерфейсу. Для новых пользователей логичнее смотреть в сторону Jellyfin.

Universal Media Server (UMS): мощь транскодирования

Что это. Кроссплатформенный DLNA-сервер, написанный на Java. Потомок проекта PS3 Media Server. Главная фишка — агрессивное транскодирование: UMS способен на лету конвертировать практически любой формат в тот, который понимает конкретный клиент.

Установка. Требует Java 17+ и FFmpeg. Пакеты есть для основных дистрибутивов, но часто проще скачать архив с официального сайта.

Сильные стороны:

• Транскодирует всё: от экзотических контейнеров до устаревших кодеков.
• Гибкая настройка профилей транскодирования для каждого типа устройств.
• Поддержка внешних плагинов и движков (FFmpeg, MPlayer, VLC, dcraw).
• Работает с торрентами на лету (стриминг без скачивания).
• Встроенная поддержка YouTube и других онлайн-источников.

Слабые стороны:

• Тяжёлый: 500 МБ – 1 ГБ RAM из-за JVM.
• Java — это всегда отдельная история с зависимостями.
• Интерфейс управления устаревший и перегруженный настройками.
• Транскодирование сильно нагружает CPU.
• Настройка «для конкретного телевизора» может занять вечер.

Когда выбирать: если у вас парк разнородных устройств, некоторые из них поддерживают только MPEG-2 или старые профили, и без транскодирования не обойтись.

Gerbera: наследник MediaTomb

Что это. Лёгкий DLNA/UPnP-сервер, написанный на C++. Прямой наследник проекта MediaTomb, который был одним из первых DLNA-серверов для Linux (2005 год). Gerbera использует SQLite или MySQL для хранения каталога.

Установка:

sudo apt install gerbera

После установки — веб-интерфейс для управления библиотекой на порту 49152.

Сильные стороны:

• Лёгкий: 30–60 МБ RAM.
• Веб-интерфейс для управления каталогом (в отличие от MiniDLNA).
• Гибкие правила импорта: можно написать JavaScript-скрипт, который определяет, как файлы раскладываются по виртуальным папкам.
• Поддержка транскодирования через внешние скрипты (FFmpeg, vlc).
• Хорошо работает на ARM-устройствах.

Слабые стороны:

• Транскодирование базовое, без аппаратного ускорения «из коробки».
• Нет мобильных клиентов, управление только через браузер.
• Сообщество небольшое, обновления выходят редко.
• Интерфейс функциональный, но аскетичный.

Когда выбирать: если нужен лёгкий сервер с веб-интерфейсом и возможностью гибкой организации каталога, но без тяжеловесных функций вроде постеров и рейтингов.

Rygel: DLNA-сервер из мира GNOME

Что это. Компонент среды GNOME, реализующий UPnP MediaServer. Работает через GStreamer. Устанавливается как часть пакета GNOME или отдельно.

Сильные стороны:

• Интегрирован в GNOME, работает «из коробки» на десктопе.
• Не требует отдельной настройки для базового использования.
• Может выступать и как сервер, и как клиент (рендерер).

Слабые стороны:

• Зависит от GStreamer и GNOME-библиотек.
• Настройка ограничена, нет полноценного веб-интерфейса.
• Потребляет больше ресурсов, чем MiniDLNA.
• Не подходит для сервера без графической среды.

Когда выбирать: если вы используете GNOME-десктоп и хотите быстро расшарить папку с медиа без установки отдельного сервера. Для серьёзного использования — не лучший выбор.

Kodi как DLNA-сервер

Что это. Медиацентр (бывший XBMC), который умеет не только воспроизводить, но и отдавать медиа по UPnP.

Сильные стороны:

• Если Kodi уже стоит как плеер — сервер включается одной галочкой в настройках.
• Красивый интерфейс, метаданные, обложки.

Слабые стороны:

• Требует графической сессии или работы в режиме стенда с X-сервером.
• Тяжёлый: 300–700 МБ RAM.
• DLNA-сервер — побочная функция, работает нестабильно и с ограничениями.
• Не предназначен для работы 24/7 как фоновый сервис.

Когда выбирать: только если Kodi уже используется как основной плеер и нужен «бонусный» DLNA-сервер без установки отдельного пакета.

TVHeadend: для живого эфира и записи

Что это. Сервер для приёма и записи телевидения (DVB-T, DVB-S, DVB-C, IPTV, SAT>IP). Не является медиасервером в чистом виде, но умеет раздавать записи и живой эфир по DLNA/UPnP, а также по HTTP-потоку.

Сильные стороны:

• Полноценный PVR: запись по расписанию, таймшифт, серии.
• Интеграция с Jellyfin, Plex, Kodi.
• Поддержка множества тюнеров и протоколов.

Слабые стороны:

• Сложная настройка: частоты, транспондеры, LNB, CA-модули.
• DLNA-функция базовая, без метаданных.
• Не подходит для раздачи уже скачанных фильмов.

Когда выбирать: если главная задача — приём и запись ТВ, а раздача по сети вторична.

Navidrome и другие аудиосерверы

Если основная задача — музыка, стоит посмотреть на специализированные решения:

Navidrome — лёгкий сервер для музыки, реализующий протокол Subsonic API. Написан на Go, потребляет 20–40 МБ RAM. Веб-интерфейс, мобильные клиенты (Symfonium, DSub, Ultrasonic). Транскодирует на лету через FFmpeg. Идеален для больших библиотек FLAC.

Funkwhale — децентрализованный музыкальный сервер с социальной составляющей. Подходит для небольших сообществ.

LMS (Logitech Media Server) — ветеран (с 2001 года), работает с экосистемой плееров Squeezebox и программными клиентами. Поддерживает плагины, интернет-радио, подкасты.

Эти серверы не реализуют DLNA/UPnP напрямую (хотя для Navidrome есть плагины-мосты), но решают задачу доставки музыки эффективнее, чем универсальные медиа-серверы.

Сравнительная таблица

Характеристика	MiniDLNA	Jellyfin	Plex	UMS	Gerbera	Rygel
Потребление RAM	10–30 МБ	200–500 МБ	300–800 МБ	500 МБ–1 ГБ	30–60 МБ	80–150 МБ
Транскодирование	Нет	Да, с HW	Да, с HW	Да, с HW	Базовое	Через GStreamer
Веб-интерфейс	Нет	Да	Да	Да (устаревший)	Да	Нет
Мобильные клиенты	Нет	Да	Да	Нет	Нет	Нет
Метаданные/обложки	Нет	Да	Да	Частично	Нет	Нет
Пользователи/права	Нет	Да	Да	Нет	Нет	Нет
Свободный код	Да (GPL)	Да (GPL)	Нет	Да (GPL)	Да (GPL)	Да (LGPL)
Сложность настройки	Низкая	Средняя	Низкая	Высокая	Средняя	Низкая
Работа на ARM	Отлично	Хорошо	Хорошо	Средне	Хорошо	Средне
Поддержка 24/7	Отлично	Отлично	Отлично	Хорошо	Отлично	Средне

Выбор по сценариям использования

Абстрактные сравнения хороши, но в жизни вопрос стоит конкретно. Разберу типовые ситуации.

Сценарий 1: один телевизор в гостиной, коллекция фильмов на NAS или сервере. Выбор: MiniDLNA. Никакого транскодирования не нужно (современные телевизоры понимают MKV, MP4, HEVC), интерфейс не нужен, ресурсы минимальные. Поставил, указал папку, забыл на год.

Сценарий 2: семья из трёх-четырёх человек, разные устройства (телевизор, планшет, телефон, ноутбук), нужна библиотека с постерами. Выбор: Jellyfin. Бесплатно, есть клиенты для всех устройств, автоматические метаданные, управление пользователями (детский профиль без определённого контента).

Сценарий 3: «Хочу как на стриминге, но со своими файлами и без подписки». Выбор: снова Jellyfin или, если не смущает закрытый код и подписка, — Plex.

Сценарий 4: парк из старого телевизора, который понимает только MPEG-2, и нового, который ест HEVC. Выбор: Universal Media Server или Jellyfin с настроенным транскодированием.

Сценарий 5: музыкальная библиотека 500 ГБ+ в FLAC, нужен доступ с телефона в дороге. Выбор: Navidrome + клиент на телефоне. DLNA здесь не нужен.

Сценарий 6: Raspberry Pi Zero или старый роутер с OpenWrt, 128 МБ RAM. Выбор: только MiniDLNA. Больше ничего в такие ресурсы не влезет.

Сценарий 7: приём эфирного ТВ и раздача записей по дому. Выбор: TVHeadend + Jellyfin (или Plex) для воспроизведения.

Настройка сети: то, что ломает всё

Половина проблем с DLNA-серверами связана не с самим сервером, а с сетью. Разберу типовые грабли.

Мультикаст и Wi-Fi

SSDP работает через мультикаст. Многие домашние роутеры и точки доступа по умолчанию блокируют или некорректно обрабатывают мультикаст-трафик в беспроводном сегменте. Симптом: сервер виден с устройств, подключённых кабелем, но не виден с планшетов и телефонов по Wi-Fi.

Решение: в настройках роутера включить «игнорировать мультикаст» или «отключить изоляцию клиентов». На роутерах с OpenWrt проверить, что в /etc/config/network нет option igmp_snooping '1' без настроенного IGMP-прокси. Альтернатива — включить на сервере 유니icast-объявления (в MiniDLNA: ssdp_notify_interval=900, в Jellyfin: настройка обнаружения).

Брандмауэр

Если включён ufw, firewalld или nftables, нужно открыть:

• UDP 1900 (SSDP).
• TCP порт сервера (8200 для MiniDLNA, 8096 для Jellyfin, 32400 для Plex, 49152 для Gerbera).
• TCP 80 или 8008 для передачи медиафайлов (зависит от реализации).

Для ufw:

sudo ufw allow 1900/udp
sudo ufw allow 8200/tcp

Для firewalld:

sudo firewall-cmd --permanent --add-port=1900/udp
sudo firewall-cmd --permanent --add-port=8200/tcp
sudo firewall-cmd --reload

Подсети и VLAN

Если устройства в разных подсетях (например, гостевой Wi-Fi и основная сеть), мультикаст между ними не ходит. Сервер не будет виден. Решение: мост между подсетями, настройка IGMP-прокси на роутере или вынесение всех в одну подсеть.

Проблемы с MTU и Jumbo Frames

Редкий, но встречающийся случай: на одном устройстве включены Jumbo Frames (MTU 9000), на другом — стандартный MTU 1500. Результат — обрыв передачи больших файлов. Решение: привести все устройства к единому MTU, обычно 1500.

Транскодирование: когда без него не обойтись

Транскодирование — самая ресурсоёмкая функция медиасервера. Суть: сервер на лету перекодирует видео или аудио в формат, который понимает клиент. Например, клиент (старый телевизор) поддерживает только H.264 в контейнере MP4, а файл записан в HEVC внутри MKV. Сервер читает MKV, декодирует HEVC, кодирует в H.264, упаковывает в MP4 и отдаёт потоком.

Аппаратное ускорение

Без аппаратного ускорения транскодирование одного потока 1080p занимает 80–100% одного ядра современного процессора. 4K — от двух ядер и выше. С аппаратным ускорением нагрузку берёт на себя GPU:

• Intel Quick Sync (QSV) — через VAAPI. Доступен на процессорах с интегрированной графикой Intel (Broadwell и новее). Jellyfin и UMS поддерживают из коробки.
• NVIDIA NVENC/NVDEC — через проприетарные драйверы NVIDIA. Отличное качество, но ограниченное число одновременных потоков (зависит от модели карты).
• AMD VCE/VCN — через VAAPI на открытых драйверах. Качество чуть ниже, чем у NVIDIA, но для домашнего использования достаточно.
• V4L2 M2M — для ARM-устройств с аппаратным кодеком (Rockchip, Allwinner, Raspberry Pi 4/5).

Для включения аппаратного ускорения в Jellyfin: Настройки → Воспроизведение → Аппаратное ускорение → выбрать тип. Пользователь, от которого запущен сервер, должен быть в группе render и video:

sudo usermod -aG render,video jellyfin

Когда транскодирование не нужно

Если все ваши устройства поддерживают нужные форматы, транскодирование только вредит: тратит электричество, увеличивает задержку, снижает качество. Мини-совет: прежде чем настраивать транскодирование, проверьте, какие форматы реально поддерживает ваш телевизор или приставка. Часто достаточно просто перекодировать файл один раз в нужный формат и раздавать его напрямую.

Безопасность медиасервера

Домашний медиасервер по умолчанию не предназначен для работы в интернете. Но если вы хотите удалённый доступ:

Никогда не открывайте порт DLNA-сервера наружу. DLNA/UPnP не имеет аутентификации. Любой, кто увидит сервер в сети, получит доступ к файлам.

Для удалённого доступа используйте:

• VPN (WireGuard, OpenVPN) — самый надёжный способ. Подключаетесь к домашней сети через VPN и работаете с сервером как из локалки.
• Reverse proxy с HTTPS и аутентификацией (Nginx + Tailscale, Traefik + Cloudflare Tunnel) — для Jellyfin и Plex.
• Функцию удалённого доступа у Plex (но помните про закрытый код и облако).

Разграничение прав в Jellyfin. Создайте отдельного пользователя с ограниченными правами для гостевого доступа. Не давайте административный доступ всем подряд.

Обновления. Подписывайтесь на уведомления о безопасности вашего дистрибутива. Уязвимость в FFmpeg или libxml может касаться медиасервера напрямую.

Неочевидные факты, которые пригодятся

Факт 1. Стандарт DLNA был разработан при активном участии Sony, Intel, Microsoft, Samsung и Panasonic. При этом ни одна из этих компаний не реализовала полную поддержку стандарта во всех своих продуктах. Телевизоры Sony могут не видеть сервер, который прекрасно работает с Samsung, и наоборот. Приходится тестировать совместимость на конкретных устройствах.

Факт 2. Протокол UPnP, на котором построен DLNA, изначально проектировался для автоматической настройки сетевых принтеров и веб-камер в конце 1990-х. Мультимедийная составляющая была добавлена постфактум, и это заметно по архитектуре: передача видео через SOAP-обёртки в XML — решение, которое в 2026 году выглядит архаично, но работает.

Факт 3. В 2013 году исследователь безопасности Стивен Рамсден опубликовал работу, в которой показал, что через уязвимость в реализации UPnP на роутерах можно получить удалённый доступ к внутренней сети. После этого многие производители роутеров отключили UPnP WAN-администрирование по умолчанию. Внутрисетевой UPnP при этом остался и продолжает работать.

Факт 4. Мини-сервер MiniDLNA способен отдавать одновременно до 10–15 потоков без деградации на гигабитной сети, если нет транскодирования. Ограничение здесь — не сервер, а пропускная способность сети и дисковой подсистемы.

Факт 5. В Японии и Южной Корее стандарт DLNA до сих пор активно используется в коммерческих продуктах: гостиничные системы, медицинские учреждения, цифровые вывески. В этих странах есть сертифицированные устройства, которых нет на западном рынке.

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

Перед тем как ставить сервер, пройдитесь по списку:

• Определите, какие устройства будут потреблять контент (телевизор, приставка, телефон, ноутбук).
• Запишите, какие форматы поддерживает каждое устройство (обычно указано в инструкции или на сайте производителя).
• Выберите место для медиафайлов. Убедитесь, что диск смонтирован с правами на чтение для пользователя сервера.
• Решите, нужно ли транскодирование. Если все устройства поддерживают ваши форматы — выбирайте лёгкий сервер без транскодирования.
• Проверьте, что роутер не блокирует мультикаст.
• Настройте файрвол: откройте порты сервера.
• Установите сервер, укажите папки с медиа.
• Запустите первичное сканирование и дождитесь завершения.
• Проверьте видимость сервера на каждом устройстве-клиенте.
• Если сервер не виден — перезагрузите роутер и клиент, проверьте подсети.
• Настройте автоматическое пересканирование или inotify.
• Если нужен удалённый доступ — настройте VPN, не открывайте порты напрямую.
• Настройте резервное копирование конфигурации сервера.
• Проверьте потребление ресурсов через htop или top в режиме покоя и под нагрузкой.

Частые ошибки и их решения

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

Файл виден в списке, но не воспроизводится. Причина: телевизор не поддерживает кодек или контейнер. Решение: проверить характеристики файла (ffprobe файл), при необходимости перекодировать или использовать сервер с транскодированием.

Воспроизведение обрывается на больших файлах. Причина: проблема с Range-запросами, таймаут на роутере, нестабильный Wi-Fi. Решение: проверить, что сервер отдаёт заголовок Accept-Ranges: bytes. Для Wi-Fi — попробовать проводное подключение.

Пересканирование не подхватывает новые файлы. Причина: inotify не работает (превышен лимит наблюдателей) или файловая система не поддерживает inotify (NFS, некоторые сетевые ФС). Решение: увеличить лимит max_user_watches, использовать принудительное пересканивание по расписанию через cron.

Звук есть, видео нет (или наоборот). Причина: клиент не поддерживает один из потоков. Решение: перекодировать файл в совместимый формат или включить транскодирование.

Сервер потребляет много CPU в простое. Причина: зависший процесс сканирования, конфликт с антивирусом (редко на Linux, но бывает), фоновое транскодирование. Решение: проверить логи, убить зависший процесс, убедиться, что транскодирование не запущено.

Мониторинг и обслуживание

Медиасервер, работающий 24/7, требует минимального, но регулярного внимания.

Логи. Для MiniDLNA: /var/log/minidlna.log. Для Jellyfin: /var/lib/jellyfin/log/. Для Plex: /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Logs/. Настройте ротацию через logrotate, чтобы логи не съедали диск.

Обновления. Настройте автоматические обновления безопасности через пакетный менеджер. Для Jellyfin и Plex обновления функциональные выходят раз в несколько недель — их лучше ставить вручную, читая changelog.

Резервное копирование. Копируйте конфигурационные файлы и базы данных. Для MiniDLNA: /etc/minidlna.conf и /var/lib/minidlna/. Для Jellyfin: вся папка /var/lib/jellyfin/. Для Plex: /var/lib/plexmediaserver/.

Мониторинг ресурсов. Простой скрипт в cron, который проверяет потребление памяти и диска:

#!/bin/bash
MEM=$(ps -o rss= -p $(pgrep -f minidlna) | awk '{sum+=$1} END {print sum}')
DISK=$(df /srv/media --output=pcent | tail -1 | tr -d ' %')
if [ "$MEM" -gt 100000 ]; then
    echo "MiniDLNA memory high: $MEM KB" | mail -s "Media server alert" admin@localhost
fi
if [ "$DISK" -gt 90 ]; then
    echo "Media disk $DISK% full" | mail -s "Disk alert" admin@localhost
fi

Производительность дисковой подсистемы

Часто узкое место — не сервер и не сеть, а диск. Несколько рекомендаций:

Один файл 50 ГБ или 50 файлов по 1 ГБ? Для последовательного чтения разницы почти нет. Но при одновременном воспроизведении с нескольких клиентов фрагментация и случайное чтение начинают играть роль.

HDD или SSD? Для последовательного потокового воспроизведения видео 4K (битрейт 50–80 Мбит/с) достаточно любого современного HDD. Для одновременного доступа 5+ потоков или работы с большим количеством мелких файлов (музыка, фото) — SSD заметно комфортнее.

Сетевое хранилище. Если медиа лежат на NAS и сервер читает их по NFS или SMB, добавьте к задержке диска задержку сети. Для гигабитной сети максимальная пропускная способность — около 110 МБ/с. Этого хватает для 3–4 потоков 1080p или одного потока 4K с высоким битрейтом.

Экосистема плагинов и расширений

Для Jellyfin к 2026 году сформировалась устойчивая экосистема плагинов:

• OpenSubtitles — автоматическое скачивание субтитров.
• Fanart — дополнительные постеры и фоновые изображения.
• Bookshelf — поддержка аудиокниг.
• Live TV — интеграция с TVHeadend и IPTV.
• Playback Reporting — статистика просмотров.
• Reports — отчёты по библиотеке.

Для Plex плагины частично ограничены, но есть встроенные «каналы» и интеграции с внешними сервисами.

Для MiniDLNA и Gerbera плагинов в привычном смысле нет. Расширение функциональности — через внешние скрипты и утилиты.

Миграция между серверами

Если вы начали с MiniDLNA и решили перейти на Jellyfin (типичный путь), учтите:

• Библиотеку файлов переносить не нужно — просто укажите те же папки новому серверу.
• Метаданные, постеры и настройки пользователей придётся создавать заново.
• Настройки клиентов (телевизоров, приставок) нужно обновить: они увидят новый сервер по новому имени.
• Старый сервер остановите, чтобы избежать конфликтов в сети. Два DLNA-сервера в одной подсети работают, но клиенты могут путаться.

Обратная миграция (с тяжёлого сервера на лёгкий) проще: отключили, удалили, поставили MiniDLNA, указали папки.

Альтернативные протоколы: когда DLNA мало

Стоит упомянуть, что DLNA — не единственный способ передать медиа по сети:

AirPlay (Apple) — для устройств экосистемы Apple. На Linux реализуется через shairport-sync (аудио) и uxplay (видео).

Chromecast / Google Cast — для устройств с Chromecast. На Linux можно транслировать через catt (командная строка) или через браузер.

Samba (SMB) — прямой доступ к файлам по сети. Не потоковая передача, а монтирование сетевой папки. Работает на всех устройствах, но требует поддержки на клиенте.

NFS — аналогично, но для Linux-клиентов.

HTTP-сервер — самый примитивный способ: поднять python3 -m http.server в папке с файлами и открывать их в браузере. Никакого каталога, но работает везде.

PulseAudio / PipeWire — для потокового аудио между Linux-машинами.

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

Взгляд в будущее: что ждёт DLNA и медиасерверы

К 2026 году ситуация выглядит так:

Протокол DLNA/UPnP не развивается. Альянс DLNA прекратил работу в 2017 году. Новых профилей не появляется. Но установленная база устройств огромна: миллиарды телевизоров, приставок и аудиосистем по всему миру поддерживают DLNA, и они не исчезнут ещё лет десять.

Вектор развития домашних медиасерверов смещается в сторону:

• Единого каталога с метаданными (не просто файлы в папках, а «фильм с постером, описанием и рейтингом»).
• Транскодирования с аппаратным ускорением.
• Мобильных клиентов с офлайн-режимом.
• Интеграции с умным домом и голосовыми ассистентами.
• Децентрализации и приватности (отказ от облаков).

В этом контексте MiniDLNA остаётся нишевым, но незаменимым инструментом для простых задач. А для сложных — растёт экосистема Jellyfin.

FAQ: частые вопросы и короткие ответы

1. Можно ли запустить два медиасервера одновременно, например MiniDLNA и Jellyfin? Да, они будут работать параллельно на разных портах. Но в списке источников на телевизоре появятся оба сервера, что может путать. Лучше выбрать один.

2. Поддерживает ли MiniDLNA транскодирование через внешний скрипт? Официально — нет. Есть неофициальные патчи и обходные решения (например, запуск отдельного скрипта, который перекодирует файл в временную папку, а MiniDLNA отдаёт уже перекодированный), но это хрупкая конструкция. Если нужно транскодирование — лучше взять Jellyfin или UMS.

3. Какой медиасервер выбрать для Raspberry Pi 4? Для раздачи без транскодирования — MiniDLNA (минимум ресурсов). Для полноценного медиасервера с интерфейсом — Jellyfin с аппаратным декодированием через V4L2 M2M (Raspberry Pi 4 поддерживает аппаратное декодирование H.264 и частично HEVC). Plex на Raspberry Pi работает, но транскодирование крайне медленное.

4. Почему телевизор видит сервер, но показывает пустую библиотеку? Чаще всего — проблема с правами доступа. Сервер запущен от пользователя, который не может прочитать файлы. Проверьте ls -la в папке с медиа и убедитесь, что пользователь сервера имеет право на чтение.

5. Как добавить субтитры к фильму при раздаче через DLNA? Положите файл субтитров (.srt) в ту же папку с тем же именем, что и видеофайл (например, movie.mkv и movie.srt). MiniDLNA отдаст их как связанный ресурс. Но поддержка отображения субтитров зависит от клиента: одни телевизоры подхватывают, другие игнорируют.

6. Можно ли использовать DLNA-сервер для раздачи музыки на колонки с Bluetooth? Напрямую — нет. DLNA работает по сети. Колонка должна быть сетевым устройством с поддержкой UPnP/DLNA (например, сетевой ресивер или умная колонка). Для Bluetooth-колонок нужен другой путь: подключение телефона или компьютера к колонке и воспроизведение с него.

7. Безопасно ли открывать порт 8200 (или 8096) в интернет? Нет. Ни один из рассмотренных серверов не имеет полноценной защиты от несансканированного доступа на уровне протокола. Для удалённого доступа используйте VPN.

8. Как понять, какой формат поддерживает мой телевизор? Найдите точную модель телевизора, откройте спецификацию на сайте производителя. Там обычно указан список поддерживаемых контейнеров и кодеков. Альтернатива: попробовать воспроизвести тестовый файл нужного формата через DLNA или с флешки.

9. Что делать, если сервер периодически «отваливается» из сети? Проверить: не перезагружается ли роутер, не меняется ли IP-адрес сервера (лучше назначить статический), не конфликтует ли таймаут аренды DHCP, не перегревается ли устройство. Посмотреть логи сервера на предмет ошибок.

10. Есть ли смысл использовать DLNA в 2026 году, если есть Jellyfin с клиентами? Да, если устройство-клиент не поддерживает приложение Jellyfin. Например, старый телевизор без Android TV, Blu-ray-плеер, медиаприставка без магазина приложений. Для них DLNA — единственный способ получить файл с сервера без танцев с флешками.

Итоговые рекомендации

Выбор медиасервера для Linux определяется тремя вопросами:

Первый: нужно ли транскодирование? Если все устройства поддерживают ваши форматы — нет. Ставьте MiniDLNA или Gerbera и не тратьте ресурсы на перекодирование.

Второй: нужен ли интерфейс и метаданные? Если да — Jellyfin. Это лучший свободный вариант на 2026 год. Если нет — любой лёгкий сервер.

Третий: какие клиенты? Если среди них есть устройства без приложений (старые телевизоры, приставки) — убедитесь, что сервер поддерживает DLNA/UPnP. Jellyfin поддерживает, но базово. Для максимально совместимой раздачи по протоколу — отдельный MiniDLNA или Gerbera иногда надёжнее.

Мой личный сетап, который работает уже несколько лет: Jellyfin для основного доступа (интерфейс, постеры, мобильные клиенты) и MiniDLNA для раздачи на кухонный телевизор, который не поддерживает ничего, кроме DLNA. Оба работают на одном сервере, не конфликтуют, суммарное потребление памяти — около 300 МБ.

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

---

Информация в статье актуальна на сентябрь 2026 года. Названия пакетов, пути к конфигурационным файлам и поведение программ могут незначительно отличаться в зависимости от дистрибутива и версии.