Exiftool doesn't read to the end of a directory

[arthurb]

Hello,
I call ET from within a VBScript to enter basic information into the IPTC data for all images in a directory or folder (Win 7 64).  This works fine, and has done for several years, but I have recently noticed that when I have more than about 28-29 images in a directory it just stops after that sort of number; I usually shoot Raw and scan +ve/-ve film to Tiff so normally only have a few Jpegs to process in each folder.  The number varies from directory to directory but when I run it repeatedly against the same directory the number of processed files is consistent.

Has anyone seen an issue like this, or have any idea where I should start looking for an answer?  Please note that the script works just fine with 24-25 Jpegs or fewer in the directory.

I have thought of storage issues but Process Explorer says that wscript has a working set of about 20MB then there are two instances of ET one with a WS of about 5MB and another, subordinate, with about 30MB, which all looks very small.

I am just asking this in case anyone has had anything similar and can point me to something that I might have done wrong.  Unfortunately, on smaller directories the script/exiftool works as required. 

[StarGeek]

Does it happen when you run the command directly on the command line?

I don't believe it's an exiftool problem as I regularly run exiftool on hundreds, sometimes thousands of files, without a problem.

How are you calling exiftool?  Is there possibly a buffer writing problem of some sort?  I faintly recall someone doing something with a script and having a problem where the write buffer wasn't flushing and the script stalled. 

[Phil Harvey]

Could this be a command-line length limitation?  If so, using the -@ option will allow you to get around this.

- Phil

[arthurb]

Thanks for the rapid replies.  I'm sorry that I didn't come back earlier but my new camera arrived at the dealer's on Monday morning and, after picking it up Monday afternoon, I have been a bit engrossed with checking it out; I'm sure you both understand. I will be looking at this again tomorrow, Wednesday (UK time).

Running this from the command line would be a bit problematic as I update about 8 or 9 fields, and some of the input is created from more than one variable; hence I am thinking now about Phil's suggestion.  I will also look into buffer flushing but there's one more thing: I have another script, written slightly earlier, that calls ET once for each file read.  This runs just fine on 30+ files; slowly, but it works.  This, second script, calls ET once with the directory name in the command, and that is the one that fails.

Anyway, thanks for the suggestions, and I will look further tomorrow, after going out again with my new toy... 

[arthurb]

I'm still struggling with this issue, although I have improved the code in my script somewhat; in fact I'm surprised it worked before.

StarGeek, if you are still looking here, do you run VBScripts that call ExifTool, and, if so, do they create backup files (i.e. xxx.jpg_original)?

I do find it hard to believe this is caused by a parameter input problem as it only manifests itself after 27-29 images have been processed, and the script stalls rather than failing.  There's no abend or error code generated, nor any messages, the script stops and leaves the command window open.  It is really, really weird. Still, I am improving the code in my scripts.

[arthurb]

OK, by paring back the command string to ET, concentrating on what I thought would be the most likely culprit, I have found the problem; or rather, what appears to cause the problem.

With the following lines calling ET it works fine:
Set objExecObject = objShell.Exec(str_pgm & _
      " -Exif:Copyright=" & str_Q_date_and_time & _
      " -IPTC:ObjectName<${filename}" & str_Q_currdir_line & _
      " -ext .jpg DIR -pause " & str_tgt_dir)

But with the 3rd line replaced by:
      " -IPTC:ObjectName<${filename}" & str_Q_currdir_line  & "${CreateDate}" & _
the problem occurs. Note that both run through a short directory just fine, although I don't get the Create Date in the IPTC field. But, it's how it fails that leaves me bemused: change that third line, and on a directory with 60-odd image files it stalls after 15-16 now (I had the input parms slightly differently before).  The total length of data input to IPTC ObjectName is about 27 characters without the Create_Date.

I will investigate more - I guess I am misusing the CreateDate function, but the behaviour definitely had me totally confused.
I'll add more later, I'm being called in for dinner ...

[StarGeek]

StarGeek, if you are still looking here, do you run VBScripts that call ExifTool, and, if so, do they create backup files (i.e. xxx.jpg_original)?

I'm sorry, I know nothing about VBScripts.  But you can prevent the creation of backup files with the Overwrite_Original option.

Edit:  Is the command being executed properly quoted?  Maybe create the full command as a string and have a popup to view it before executing it.   Also, is str_tgt_dir the directory being processed?  If so, what is DIR in your command? 

[arthurb]

OK, this whole, weird issue seems to have been caused by the Exif 'CreateDate', and for that matter 'DateTimeOriginal', not being present in the metadata for each image file.  This was down to another issue in another script which is supposed to initialise important fields in scanned images (the scanning software I have been using doesn't fill them in).  Quite why it should manifest itself in the way it did I really cannot say (actually I can't quite get my head round it).  There were other issues with my script, although they shouldn't have contributed to the error (it did actually execute ET in all cases, and complete when processing small directories), so I genuinely think it was something to do with the missing metadata.

I have considered ET to be pretty much bullet-proof for years now, and this has not altered that view; it was just a quirk I guess - a very, very weird one.

It's late, 40 minutes past midnight, and I have had quite enough for today. It's time to put some music on the hi-fi, pour a modest glass of Calvados, sit back and let this whole thing disappear into the ether.

Thank you StarGeek for your suggestions, it is always a help to feel you can ask questions. Thanks also to Phil, you are always there to lend help; I haven't asked about anything for many years, and I can only say that everything is a lot easier than when you were on C-PAN.

Goodnight,
Arthur.

[Phil Harvey]

Hi Arthur,

While I don't know exactly what you were trying to do, I think this section of the documentation may help answer some questions:

            If a specified tag does not exist, a minor warning is issued and
            the line with the missing tag is not printed [the tag isn't copied].
            However, the -f option may be used to set the value of missing tags to '-'
            (but this may be configured via the MissingTagValue API option), or the
            -m option may be used to ignore minor warnings and leave the
            missing values empty.

(annotation in square brackets added since you were using this in context of the -tagsFromFile feature)

- Phil