Домашний медиа-сервер (UPnP, DLNA, HTTP)

подскажите почему HMS сам переименовывает файлы
например Formula lubvi dla uznikov braka переименовал в --SHUMAHER--
а Падение римской империи в ==Kinozal-HD==
ну и другое также иногода встречается.

Структура AVI-файла

Так, в соответствии с общей структурой RIFF-типа, AVI-файл должен иметь следующий вид:

RIFF `AVI ` // четырехбуквенный идентификатор файла (в RIFF-формате)
LIST `hdrl` // список заголовков блоков, определяющих форматы потоков

:::::::::::::::::::::::::::::::::
LIST `movi` // блоки данных (потоков) AVI-файла
:::::::::::::::::::::::::::::::::

`idx1` // необязательный блок, определяющий размещение блоков данных внутри AVI-файла

То есть в AVI-файле должно быть по крайней мере два обязательных блока: заголовка и данных, которые, в свою очередь, могут содержать подблоки. Первый блок будет содержать общую информацию о видеоролике: разрешение кадров и их частоту, формат аудио и т.д. Сначала в заголовке для записи длины потока отводилось 32 байт, поскольку в файловой системе FAT 16 максимальный раздел диска не мог превышать 2 Гбайт, поэтому и максимальный кусок видео, который можно было записывать в AVI-файле, не мог превышать 2 Гбайт (с учетом знака переменной размера). Во времена возникновения формата казалось естественным, что длина файла не может превышать размер логического диска. С появлением файловых систем FAT 32 и NTFS верхняя граница размера раздела значительно отодвинулась, однако потребовалось еще немало времени, чтобы ввести расширение формата и дождаться программ, способных это ограничение обходить.

Список `hdrl` может состоять из подсписков:

LIST `hdrl` // список заголовков блоков, определяющих форматы потоков
`avih` // главный заголовок AVI-файла
LIST `strl`
`strh` // заголовок потока
`strf` // формат потока
`strd` // дополнительный заголовок данных

:::::::::::::::::::::::::::::::::
Список `movi`, в свою очередь, состоит из подблоков:

LIST `movi` // блоки данных (потоков) AVI-файла
SubChunk | LIST `rec ` // подблок | список записей
`##wb` (размер блока 4 байта) (data) // звуковые данные (блок)
`##dc` (размер блока 4 байта) (data) // видеоданные (блок)
`##db` (размер блока 4 байта) (data) // видеоданные (блок)

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

Первоначально ##dc-блок был предназначен для хранения сжатого изображения, а ##db-блок - для несжатого DIB (Device Independent Bitmap). Но фактически они оба могут содержать сжатые данные.

Серьезным недостатком AVI-формата является то, что аудио- и видеофрагменты не содержат никаких меток времени или индексов кадра. Данные упорядочиваются по времени последовательно, в порядке поступления. Приложение для захвата или проигрывания видео должно само позаботиться о синхронизации видео- и аудиопотоков. Но если деление видео на кадры совершенно естественно, то звук представляет собой непрерывный поток, который приходится искусственно расчленять на фрагменты, соответствующие кадрам (из-за этого точная синхронизация изображения и звука часто отсутствует и звук может `расходиться` с изображением). В простейшем случае каждому кадру видео соответствует кусок звукового сопровождения, но далеко не все AVI-файлы делаются по этой простой схеме.

Недостаток временных меток был устранен в расширении AVI-формата - OpenDML AVI (поддержанный затем в DirectShow и в ActiveMovie), которое добавляет новые куски по меткам времени.

Возможно, я ошибаюсь, но сам сервер не переименовывает файлы.
Если при просмотре название фильма отличное от имени файла, то наверное сервер отображает заголовок файла.

а есть настройка чтобы он отображал мена файлов как есть?
а то задрало переименовывать обратно после пересканирования.

Информация о файле хранится в базе сервера до ?удаления? файла, или его ?переименовании? или ?перемещения?.