[WDX] MediaTime - sum up length of media files in dir

[milo1012]

MediaTime 1.1

A content plug-in for Total Commander which can sum up the length
of every media file (Video + Audio) in a dir and shows the combined size,
with optionally leveled recursive search.
Based on MediaInfo.

In short: it's quite useful for summing the duration of a folder-based MP3 collection (one dir = one album),
or the length of your personal video collection, etc.
It should work for basically every file format that MediaInfo supports, including newest mkv/mp4 containers.

It's not(!) meant to replace the existing MediaInfo plug-ins.
It currently has fields for the playtime (runtime, i.e. media file duration) and average bit rate only.
There shouldn't be any conflicts with different plug-ins, due to static linking of the Lib.

Recursion in custom columns above two levels will by default only work "on demand", by pressing
spacebar or using internal TC commands, but you can change that behavior through an ini option.

Every recursion depth comes in two variants: a standard TC time, which is limited
to 99 (100) hours and doesn't show milliseconds,
and a more detailed field, which isn't limited in length and may show the duration
in two configurable custom formats, including milliseconds (fractions of seconds, therefore no rounding)
and days (might be useful for a large video/audio collection with hundreds of hours).
The TC time might have some advantages when it comes to sorting in custom columns,
and for the search function.

The plug-in features a caching functionality, that helps retrieving fields
in an instant when you already obtained them in the past, which can be configured in size.



Note: for comfortable on-demand fields you should be aware of the internal TC commands cm_LoadAllOnDemandFields and cm_LoadSelOnDemandFields


Download (32+64 bit + source)
SHA1: 758e4d5cdd736a657462a2054ccf9431fcd0494a




Old version 1.0:
Download (32+64 bit + source)
SHA1: df888938c75809c1ea269bd438a990737ff9a128

Old version 0.8beta:
Download
SHA1: b5b8ad6068fe0ad61d89238863fe2cfd7569a3da


Please report bugs and give me some feedback.

[Dalai]

Nice one!

At first, I thought it doesn't work at all, since it just showed zero for every directory and even single files. But then I mapped the UNC path to a network drive and that works like a charm. Don't know if there's a limitation in MediaInfoLib related to UNC or if you can fix it somehow.

Just a question: Is there a way to get the on-demand plugin fields via Shift+Alt+Enter or is this a limitation of TC that it doesn't retrieve anything?

Regards
Dalai

[milo1012]

But then I mapped the UNC path to a network drive and that works like a charm. Don't know if there's a limitation in MediaInfoLib related to UNC or if you can fix it somehow.

Thx for testing!
Yes, I forgot to treat UNC paths correctly. MediaInfoLib should work for any path that is valid for WinAPI.
I'll fix it for the next version.

Just a question: Is there a way to get the on-demand plugin fields via Shift+Alt+Enter or is this a limitation of TC that it doesn't retrieve anything?

I'd say it's a TC limitation, cause an on-demand field will only work with <Space> in custom columns, but nothing else, not even <Insert> key (like documented in the wdx interface).
That's why Alt+Shift+Enter just calculates dir size, and nothing more.

Maybe Christian should implement an INI option for that.
I think we now have one more reason for finally making an update to the WDX interface
(besides the discussed plug-in config, and better background thread implementation)

In any case, I will add options for configuring on-demand field behavior for the next version.

[HolgerK]

Recursion above 2 levels will only work "on demand", by pressing spacebar in custom columns.

Seems that aborting the background on demand counting does not work and blocks any foreground action until the background counting is finished.

Configuration:

Code: Select all

Widths29=164,29,43
Headers29=Media Time (all levels)
Contents29=[=mediatime.Media Time (all levels).h:m:s]
Options29=-1|0

- Press <Space> on a folder with a huge number of mkv-files
- Press <Escape> while the plugin is still counting
- Enter a folder with mkv files
-> Only "..." is shown for the plugin fields
-> Background activity with 10% CPU-Load and about 50MB/s Reads (Phenom II 945 3GHz Quad, Toshiba DT01ABA300)
-> After the background activity stops, the foreground display continue to show values.

Suggestion:
Is it possibly to show time-spans in "D hs"-Format?
"d:\Video\ 3384:36:10" is a little bit unhandy compared to "141(days) 00:36:10"

BTW: "Mark->Copy to clipboard with path and details" seems to start the counting again (this time in foreground thread, which blocks the TC-UI "Not responding..." until the counting is finished)
A little bit caching would be fine (either on TC side or on plugin side).

Nice plugin
Holger

[milo1012]

Seems that aborting the background on demand counting does not work and blocks any foreground action until the background counting is finished.

Thx for testing!
Yes, abort will be implemented on the next version, I don't know how often I can check for abortion though.

Configuration:
...
-> Only "..." is shown for the plugin fields
-> Background activity with 10% CPU-Load and about 50MB/s Reads (Phenom II 945 3GHz Quad, Toshiba DT01ABA300)
-> After the background activity stops, the foreground display continue to show values.

This is the typical behavior of TC. Background threads will be inserted in a "queue".
I report "ft_delayed" for every field, (just like tbeu's mediainfo plug-in)
and insert the "..." manually before that, to inform the user that the request was recognized and will be processed in that queue.
(I do that for other wdx plug-ins too)
If I don't do this in background the GUI would be blocked completely for most fields, until all values are available.

"Mark->Copy to clipboard with path and details" seems to start the counting again (this time in foreground thread, which blocks the TC-UI "Not responding..." until the counting is finished)
A little bit caching would be fine (either on TC side or on plugin side).

Seems that this is typical TC behavior, not much I can do.
So another reason to do sth. about that from Christian's side

In opposite to my other wdx plug-ins I can't implement caching in a "safe" way, since I'd need to make sure that
all sub-dirs and files are the same for the next request (user might have deleted or created files in the meantime),
and so I'd need to scan everything recursively again -> no performance gain.
Still, I might implement the "not safe" caching (on user's own responsibility).

Suggestion:
Is it possibly to show time-spans in "D hs"-Format?
"d:\Video\ 3384:36:10" is a little bit unhandy compared to "141(days) 00:36:10"

Good idea! I will think about some configuration for this.
I used "hh:mm:ss.ms" for now because it's a quite common format and doesn't require localization (you can see it in many video/audio editors).

[milo1012]

New Version 1.0!

• added file result caching - also helps in case of repeating requests for dir fields
  (as long as the cache pool is large enough to hold at least the majority of files in that dir)
  and a "clear cache on reread" option
• added request abortion (ContentStopGetValue) - should trigger almost instantly
  when switching views
• added a custom format string parser for custom string fields, which can now
  also use a 'day' field and "single" values
• added option to set on-demand behavior
• added file type pre-filter (will speedup all general requests for mixed file type dirs)
• added TC time field rounding option and overflow protection
• fixed: UNC paths didn't work
• renamed plug-in fields to "Duration" (from "Media Time"), for better comparability
  with different plug-ins
• reduced plug-in file size
• updated to MediaInfoLib 0.7.75
• released source

Check the first post for the new file.

[malialicol]

I have been using TC for quite a while, but never really come to grip with the more complicated stuff... I have installed the 64b plug-in. But now I have no idea how to get anything displayed in the file panes. Can you help me on the right track?

Many Thanks. I really would like to see the duration info about my flac files.
I.e. about more than just one thru MediaInfo or properties

[malialicol]

In a moment of splendid inspiration, the solution revealed itself to me.
Had been puzzling me for hours. Now I managed

[Dalai]

• fixed: UNC paths didn't work

Confimed. It now works flawlessly with UNC paths.

• reduced plug-in file size

Just out of curiosity: How did you manage that? And how did you get it smaller than the DLL in the first place? It is just a recompilation with an older compiler (plugin=7.10 vs. DLL=12.0)?

Regards
Dalai

[milo1012]

• fixed: UNC paths didn't work

Confimed. It now works flawlessly with UNC paths.

Thx for testing.

Just out of curiosity: How did you manage that? And how did you get it smaller than the DLL in the first place?

Just by using different MSVC compiler options:
/O1
instead of the default
/O2
which will optimize the size for every program, at the cost of execution speed.
MediInfo is basically a huge string parser (just reading headers and doing some simple calculations), where execution speed doesn't really matter on modern CPUs.

It is just a recompilation with an older compiler (plugin=7.10 vs. DLL=12.0)?

Yes, the 32bit version is compiled with MSVC 2003 .NET (aka "7.1"), which has a slightly smaller runtime compared to newer versions, but it's not much (~50k).
It also produces a slightly more compact code than VC 2005+, since the latter started to optimize code for SSE and 64-bit.
Still, the main difference results from the compiler option.

To clarify why I use static linking:
The DLL has one huge flaw: it's exporting C++ (not pure C, i.e. just pointers and POD) functions, mainly std::strings.
We are lucky that the existing MediaInfo plug-ins have a compatible ABI, but if you would compile your main plug-in DLL with MinGW or similar,
using the DLL from the MediaInfo website probably won't work.
To be honest: I don't know what got into the head of the MediaInfo author to use C++ functions export on a module DLL,
cause it's sth. you just shouldn't do when the main project that use the DLL isn't under your control.

Some info about the ABI problem here and here.

Edit:
seems that I was (partly) wrong, about the DLL interface, at least about the C++ wrapper.
Anyway, the DLL interface is a mess, with tons of things not implemented, but things you'd normally do by yourself are implemented (like module handling).
Also it's quite likely that newer or different DLL versions won't work, not to mention that there were no real important changes to the lib recently.

I might be able to reduce file size even further, by disabling some features via preprocessor, but I need some time for detailed testing.

[HolgerK]

Hello milo1012,

Sorry for the late reply (no spare time in the last weeks).
Very nice update.
The Cache works like a charm.

Current config:

Code: Select all

[MediaTime]
UseFileTypesOnly=avi;mpg;mpeg;mpe;m1v;m2v;mpv2;mp2v;pva;evo;m2p;mpv;ts;tp;trp;m2t;m2ts;mts;rec;vob;mkv;mka;webm;mp4;m4v;mp4v;mpv4;hdmov;mov;3gp;3gpp;3g2;3gp2;flv;f4v;ogm;ogv;rm;ram;wmv;wmp;asf;divx;rmvb;ac3;dts;aif;aiff;alac;amr;au;snd;ra;flac;mpc;ape;wv;ogg;oga;opus;m4a;aac;mid;midi;rmi;mp3;mp2;mpa;m1a;m2a;wav;wma
CustomFormatString=$d1 $h2:$m2:$s2
RoundTcTime=1
TcTimeOverflowZero=0
ClearCacheOnReread=0
CacheSize=6
OnDemandLevel=3

(btw: Is "contentplug.ini" the default name from Christian's plugin sample, and wouldn't it be better to rename it to "MediaTime.ini"?)

During my test i noticed a small glitch (you know this quote: "Any sufficiently advanced bug is indistinguishable from a feature.")
I prefer to see it as a feature!

If the "on demand" field "[=mediatime.Duration (all levels) detailed]" is combined with "[=mediatime.Duration (Files only). ]" in one column:

Code: Select all

 Headers29=Duration
Contents29=[=mediatime.Duration (all levels) detailed][=mediatime.Duration (Files only). ]
Options29=-1|1

, the on demand function starts to sum all mediatimes without any manual request (the second field delivers not visible output because of the ending ". ").
Okay, it takes a while until the cache is filled, but after this, navigation through the different cached (sub-)directories is just an impressive experience.
Even sorting the directories by size is fluid.

Kind regards,
Holger

[Dalai]

(btw: Is "contentplug.ini" the default name from Christian's plugin sample, and wouldn't it be better to rename it to "MediaTime.ini"?)

Neither. It's the default name for content plugins.

• fsplugin.ini is for WFX plugins
• lsplugin.ini for WLX plugins
• pkplugin.ini for WCX plugins
• and, contplug.ini for WDX plugins

BTW: It's contplug.ini, not contentplug.ini . Any plugin can use these common files (matching the plugin type of course), so renaming won't be possible.

Regards
Dalai

[milo1012]

Is "contentplug.ini" the default name from Christian's plugin sample, and wouldn't it be better to rename it to "MediaTime.ini"

Yes, as Dalai explained it: It's the standard ini file for ALL content plug-ins.
They are guaranteed to land in the same location as TC's main ini file (writable location!).
You're free to use it for your plug-in, or not, if you use a more complex config on your own.
I didn't want to bother with a standalone file for just a handful of entries.

the on demand function starts to sum all mediatimes without any manual request

Interesting, I never tried that
Seems that this is TC behavior, because it decides on it's own when to allow plug-ins to fill the request on demand.
Not much I can do about it.

Okay, it takes a while until the cache is filled, but after this, navigation through the different cached (sub-)directories is just an impressive experience.
Even sorting the directories by size is fluid.

Nice to hear. Thx for testing!

[HolgerK]

Yes, as Dalai explained it: It's the standard ini file for ALL content plug-ins.

Thanks both for the explanation, I was wondering because this ini file besides wincmnd.ini was the only one here with a name not correlated to a single plugin.

You're free to use it for your plug-in, or not, if you use a more complex config on your own.

It may be necessary if two plugins are potentially using the same section name.

Seems that this is TC behavior, because it decides on it's own when to allow plug-ins to fill the request on demand.

pssst, don't tell this to loud, otherwise it may be that this will be fixed in tc9.


Holger

[Dalai]

You're free to use it for your plug-in, or not, if you use a more complex config on your own.

It may be necessary if two plugins are potentially using the same section name.

Yes, this might happen. However, the plugin SDK states in the *SetDefaultParams functions that the plugin authors should make sure to use unique section names, so it's a quite low probability that it becomes a real issue. And if it does, it's the plugin author's problem (first come first serve ).

Regards
Dalai