Total Commander

Loopback писал(а):если есть fix_cp - к тексту источника применяется исправление

Исправил <FixTagEncoding>7</FixTagEncoding> на 6 и все понял.

Loopback писал(а):ft_numeric_floating

Мне тоже кажется, что только это и не исправлено. Но лучше прочитать. Здесь не романы многотомные написаны, как в Autorun

Orion9 писал(а):Если с годом ее можно решить, убрав тип поля:
<column name="Recorded Date" coltype="ft_datetime">RecDate</column>

Orion9 писал(а):А с типом данных "ft_datetime" поле "Year" (не важно, как оно называется) не работает.

В общем эта проблема мне непонятна, так и не смог найти у себя проблемные файлы. У меня Recorded_Data возвращает данные только на AVI, на других файлах пусто. А на mp4, mkv дату возвращает поле Encoded_Data. Но и в том и другом случае установка coltype="ft_datetime" работает без проблем. Т.е. для набора колонок

Код: Выделить всё

<column name="Recorded Date" coltype="ft_datetime">RecDate</column>
<column name="Recorded Date 2">RecDate</column>		
<column name="Encoded Date" coltype="ft_datetime">EncDate</column>
<column name="Encoded Date 2">EncDate</column>

нигде нет такого, чтобы в колонках без ft_datetime была правильная дата, а в соответствующих полях с ft_datetime её не было или она была неправильная.

Так что было бы неплохо взглянуть на примеры файлов, у которых есть проблема с ft_datetime.

Loopback писал(а):В общем эта проблема мне непонятна

Забудьте про это. Там была проблема в том, что это поле заполняемое вручную в тэгах. И оно простое текстовое. То-есть пользователи писали туда что в голову взбредет. У себя я убрал на этом поле форматирование и теперь все правильно показывает.

Loopback писал(а):было бы неплохо взглянуть на примеры файлов, у которых есть проблема с ft_datetime.

Их есть у меня:

Посмотрите, в каком формате пользователи записывают в эти поля данные. Формат ft_datetime такое воспроизвести не может.

AkulaBig писал(а): Там была проблема в том, что это поле заполняемое вручную в тэгах. И оно простое текстовое. То-есть пользователи писали туда что в голову взбредет.

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

Тут надо подумать, видимо будет иметь смысл, если дата не преобразовывается, возвращать её тоталу в виде строки, меняя тип поля на ft_stringw. Тогда и преобразование должно работать при корректном формате, и корявые даты тоже будут выводиться как есть. Собственно, к остальным преобразуемым типам тоже применимо.

Loopback писал(а):не очень правильный подход, как по мне

Да. Но этом нам не подвластно. Поэтому проглатываем и приспосабливаемся.

Loopback писал(а): меняя тип поля на ft_stringw

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

AkulaBig писал(а):Но этом нам не подвластно. Поэтому проглатываем и приспосабливаемся.

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

AkulaBig писал(а):Ну вообще стесняюсь вам предложить все-же посмотреть выше мой xml, да и все остальное. Я там просто никакого формата не ставил.

Всё во власти пользователя. Мне всё же представляется удобным иметь возможность форматировать значения по своему усмотрению. Когда данные корректно отформатированы, их удобно использовать в ИГП и для установки атрибутов.

А так я смотрел, не сильно вникая, конечно. Но из-за наименования полей конфиг слишком уж специфичен.

Loopback писал(а):Но из-за наименования полей конфиг слишком уж специфичен.

Хотел сделать один в один, как в MI, но ТС не позволяет. Ну и количество строк всего 99, не позволяет сделать необходимое количество полей. Поэтому пришлось делать составные поля. Но некоторые из прям удачненько получились. Сокращенные названия полей из-за ограничения длины. Но названия столбцов удалось оставить полными. Еще и для картинок поля сделал.

AkulaBig
Возможно, нашёл причину падения x64 без конфигурации, хотя у меня всё равно не повторяется. Если не сложно, проверьте у себя.

Версия от 27.06.2025

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

Loopback писал(а): Если не сложно, проверьте у себя.

Извиняюсь за отсутствие. Были дела.
Да, теперь все отрабатывает отлично. ТС не крашит.
А я совсем забыл про этот баг. Спасибо, что исправили.

Loopback писал(а):Также тут изменена логика вывода полей

Круто. Проверю и отпишусь.

Добавлено спустя 2 часа 11 минут:

С типом колонки почему-то ничего не получилось. Вывод только как на скрине выше. Вот так я прописал:

Код: Выделить всё

		<!--
		<column name="G_RecDate">G_RecDate</column>
		<column name="G_EncDate">G_EncDate</column>
		<column name="G_RelDate">G_RelDate</column>
		-->
		<column name="G_RecDate" coltype="ft_date">G_RecDate</column>
		<column name="G_EncDate" coltype="ft_date">G_EncDate</column>
		<column name="G_RelDate" coltype="ft_date">G_RelDate</column>
		<column name="G_AllDate" type="script">
		<![CDATA[
			Output:='';
			if (G_RecDate <> '' AND GetLang() = 'RUS') then Output:=Output+' записано '+G_RecDate;
			if (G_EncDate <> '' AND GetLang() = 'RUS') then Output:=Output+' кодировано '+G_EncDate;
			if (G_RelDate <> '' AND GetLang() = 'RUS') then Output:=Output+' выпущено '+G_RelDate;
			if (G_RecDate <> '' AND GetLang() = 'ENG') then Output:=Output+' recorded '+G_RecDate;
			if (G_EncDate <> '' AND GetLang() = 'ENG') then Output:=Output+' encoded '+G_EncDate;
			if (G_RelDate <> '' AND GetLang() = 'ENG') then Output:=Output+' released '+G_RelDate;
		]]>

В комментах видно старую запись, которую я использую сейчас. А в новой записи я попробовал использовать ft_date, то-есть местную дату. Кстати, получается чтобы использовать местную дату и время надо две колонки делать? Неудобно конечно. ft_datetime удобнее, но она в UTC выдает.
Опцию <FieldEmptyOnFail>False</FieldEmptyOnFail> пробовал и с True.
Проверил не только на тестовых файлах, но и своей медиа-коллекции на 65 Гб. Нигде не показывает дату в местном формате.

AkulaBig писал(а): Вывод только как на скрине выше.

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

AkulaBig писал(а):А в новой записи я попробовал использовать ft_date, то-есть местную дату.

Это не "местная дата".

Нужно понимать, что сам по себе тип не делает дату локальной или UTC, всё определяется исходной датой. Для поля типа ft_datetime исходная дата должна быть в UTC. Поля даты в MediaInfo возвращают ее в UTC, т.е. надо использовать для них этот тип.

А для типа ft_date/ft_time исходная дата должна быть локальной. В MediaInfo такой вывод даже не встречается. Сделаны они были для обхода проблемы с неправильным часовым поясом, прописанным в файлах с некоторых видеокамер, причем UTC-дата представлена в виде local_datetime±bias. Использование ft_date/ft_time позволяет трактовать такое время как локальное. Это очень специфическая задача, использовать эти типы для чего-то еще вряд ли имеет смысл.

Полученное время тотал интерпретирует в зависимости от типа. Время из поля типа ft_datetime он сам преобразует в локальное, а из полей ft_date/ft_time - не трогает, т.к. они предполагают местное время. Если как у вас поставить ft_date для исходных полей с датой в UTC - дата в ТС всегда будет неправильной, со смещением на величину временного пояса.

Loopback писал(а):Нужно понимать, что сам по себе тип не делает дату локальной или UTC, всё определяется исходной датой.

Понятно. Я думал даты типа первой и последней на скрине преобразуются в виндовый тип. Пробовал я и ft_datetime и ft_date. А других дат ни в одном файле из 65 Гб нет. Получается пользователи ВСЕГДА забивают дату неправильно.
Ладно, закроем этот вопрос.

AkulaBig писал(а): Я думал даты типа первой и последней на скрине преобразуются в виндовый тип. Пробовал я и ft_datetime и ft_date.

Первая на скрине - это тот вид, что плагин ожидает, она как раз подходит для типа ft_datetime.

Последняя - в принципе можно было бы доработать функцию преобразования даты из текста для поддержки такого "укороченного" вида, но тут две проблемы:

- как интерпретировать эту дату - как UTC или локальную?
- при отсутствии времени придется принять какое-то время по умолчанию (например, 0:00 или 12:00).

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

Loopback писал(а):Так-то хоть сейчас скриптом при желании можно сконструировать правильный формат (как первый на скрине) из любой даты.

Я думаю кому это важно, пусть и пишет скрипт. Меня и так устраивает.

Loopback писал(а):Первая на скрине - это тот вид, что плагин ожидает, она как раз подходит для типа ft_datetime.

Я и думал, что это будет показано в формате установленной в винде даты.

Loopback писал(а):как интерпретировать эту дату - как UTC или локальную?

В формате, установленном в винде. Раз времени нет, то его и переводить не надо.
И для всех функций, раз UTC не указан, значит и не надо учитывать разницу.
То-есть я думал, что предназначение этих функций - переводить дату в формат, установленный на винде. А оказывает их предназначение - перевод строковых параметров в дату UTC.

Выложил релиз на wincmd.ru. Полный список изменений:

Код: Выделить всё

* ВАЖНО: "исправление кодировки" теперь зависит от значения опции FixTagEncoding и по умолчанию отключено
* обновлён русский перевод для новых полей MediaInfo
* обновлена библиотека MediaInfo до версии 25.04
* унифицированы сообщения об ошибках для wdx/wlx
- исправлено падение версии x64 в некоторых случаях при отсутствующем файле конфигурации
+ CFG: в шаблоне "по умолчанию" добавлены пустые строки перед заголовками (управляется опцией HeaderExtraSpace)
+ добавлены опции FixTagEncoding, IgnoreExtensions, FieldEmptyOnFail
+ для колонок с типом (ft_datetime и т. д.) данные возвращаются в исходном виде при ошибке преобразования
* CFG: закомментированы Video codec custom, Audio codec custom
+ в компактный шаблон аудио добавлены поля текущего трека и общего числа треков
- в шаблонах не выводились поля вида "Track/Position"
- Ctrl+I не работала, если строка обложки была не первая
+ добавлены скриптовые функции GetOption, Floor, Ceil
+ добавлена опция TimingRounding (для функции TimingFormat)
+ CFG: добавлена колонка "Глубина цвета", "Обложка"
* CFG: убрана установка цвета подзаголовка из специальных режимов просмотра

AkulaBig писал(а):Я думаю кому это важно, пусть и пишет скрипт.

Да, думаю это правильно.

AkulaBig писал(а):Я и думал, что это будет показано в формате установленной в винде даты.

Нет, конечно, при чем тут формат винды? Это же плагин для TC, у которого есть своё форматирование даты.

AkulaBig писал(а):Раз времени нет, то его и переводить не надо.

Не всё так просто, ft_datetime подразумевает наличие времени.

Loopback писал(а):Выложил релиз

Поздравляю с релизом

Смотрю есть и незнакомые новые опции. Будем тестировать.

Loopback писал(а):ft_datetime подразумевает наличие времени

Но есть отдельные опции для даты и времени. Только я так и не понял, можно-ли их в одной колонке записывать.

Loopback писал(а):Это же плагин для TC, у которого есть своё форматирование даты.

Ну да. Это правильно. Просто ТС тоже ведь из Винды берет установки.

Total Commander

[wlx/wdx] TCMediaInfo