Is is possible to show the progress (-progress) as the filename in the title bar in a command window? The DOS command is TITLE.
If not, can you consider this as a feature request?
Thx
G
Interesting idea. I'll look into this.
- Phil
If you decide to go all out, here's the link to the website that shows how to do this robustly in DOS Batch: http://www.dostips.com/?t=Batch.Progress
I've attached a jpeg of how this looks when implemented.
G
I've looked into this and it is doable on Windows, Mac and Linux.
You say you want the file name in the title? What about the percentage complete?
I would like to avoid adding a new option if possible. Could this maybe be an extension of the -progress option?
- Phil
I think I have a good solution. How is this?:
-progress[:[TITLE]]
Show file progress count in messages. The progress count appears
in brackets after the name of each processed file, and gives the
current file number and the total number of files to be processed.
Implies the -v0 option, which prints the name of each processed
file when writing. When combined with the -if option, the total
count includes all files before the condition is applied, but
files that fail the condition will not have their names printed.
If followed by a colon (ie. -progress:), the console window title
is set according to the specified TITLE string. If no TITLE is
given, a default TITLE string of "ExifTool %p%%" is assumed. In
this string, %f represents the file name, %p is the progress as a
percent, %r is the progress as a ratio, and %% is a % character.
May be combined with the normal -progress option to also show the
progress count in console messages.
That sounds very cool.
Looks good to me. Thanks for considering this as a development idea.
BTW, another suggestion for the forum 'tag line' (instead of Metadata R Us) could be 'I never Metadata I didn't like', or something similar.
G
Lol. I like it. :)
- Phil
Thanks for the new progress title bar feature. The %f option (in batch %%f) throws off errors for filenames containing ampersands (&) ... I tried several tricks to get around this, but no joy.
Rgds
Right, thanks. It is my mistake for not quoting the string sent to the "title" command. This will be fixed in the next release.
- Phil
Edit: No, wait. There is a reason I didn't quote the string: The quotes show up in the window title. :(
This will be trickier than I thought...
Edit2: OK, I've got a solution. Individual characters in a Windows command may be escaped with a carat (^). This is new to me, and it solves the problem. ExifTool 10.27 will implement this fix.
While you're fixing things ;D: the window title now stays at the last setting when exiftool got interrupted (e.g., when the user pressed CTRL-C). It would be nicer if the window title got reset in this case.
Ah, right. Thanks for the report Hayo. I'll fix this too in 10.27.
- Phil
Hey. I like this feature.
For each ExifTool release I have a test suite of about 10000 files that I run ExifTool on -- a process that takes a few minutes. Adding the -progress: option to this command is very useful.
- Phil
;D
The fixed version is out now.
Note there is also an undocumented %b progress bar feature (eg. -progress:%40b shows a 40-character progress bar in the title. The bar is 20 characters wide unless another width is specified.). I haven't documented this because I'm not sure I like it, or maybe there is a better way to implement this (ie. better characters than "I" and "."). If anyone has an opinion about this, I'm all ears.
- Phil
Hi Phil, fix seems to work well for me. The %b feature is quite funny :) I think the I and . are quite good choices as on a non-fixed width font (the default, at least for Mac), this doesn't take up much space and allows for more bars. You could, of course try some fancy unicode characters instead, but that may give more headaches than it is worth. Not sure how useful the bars are in the long run though, but I guess it is good to have options ;)
Thanks for your comments. The character width was a major concern, but it bugs me that "I" and "." don't have exactly the same width as each other on the Mac, so the bar shifts a bit as it grows.
- Phil
Works but very slow. My 1 minute test script takes more than 3 minutes to run with -progress: %%f. I know %title% can slow things down but not that much.
Any ways you see to optimize this feature? In MS DOS Batch I have found that using EnableDelayedExpansion is up to 10x faster than DisableDelayedExpansion for this function ... don't know if that gives you a clue or not. ... perhaps reporting progress every 10 reads instead of every time?
Anyway, thanks for giving this feature your consideration. A wonderful product overall.
That's too bad. It is hard to believe the title command is so inefficient.
Try using %p instead of %f. Exiftool will only update the window title if the progress changes, which it does every time for %f.
- Phil
%%p is fine ... 1 minute 6 seconds. This is about the hit I expected from using from %title% ...
Let me give you the entire command I use just in case there's something I'm doing that could be interfering with %%f ...
G:\software\exiftool\exiftool.exe -progress:%%p%% -L -q -q -s3 -p "¬${album;s/!//}¬~${filename;s/.mp3//;s/!/^!/}" G:\_AlbumTags>>"%USERPROFILE%\Desktop\albums.txt"
Again, thanks for your attention to this feature
I can't imagine how anything could interfere, except that the file names are rather long.
I think the problem is most likely that changing the title bar for each file name is just too inefficient in Windows.
I tried this on Mac, and there is about a 10% penalty for using the -progress: option with file names. I'll run some tests on Windows if I get a chance.
- Phil