ExifTool PHP Fast Processing Script using StayOpen and Gearman

[Phil Harvey]

-q effects only one command, so its effects are reversed after the next -execute.  There is no way to un-do it in the same command in which it was used, if that is what you are asking.

- Phil

[TSM]

-q effects only one command, so its effects are reversed after the next -execute.  There is no way to un-do it in the same command in which it was used, if that is what you are asking.

- Phil

is the same to be said of the -echo3 command, is that per run or for the lifetime of stay_alive?
If -echo3 replaces -execute in your example then it causes a problem with my script as -execute allowed for a sequence number to be appended but your example seems to imply that -echo3 does -execute anyway.

I have tried to make it work but it does not, when using -echo3 i only get the warnings to stdout not the data, ive tried echo4 as well.
Are the order of the commands when using -echo very important?

[Phil Harvey]

I think you are confused.  I didn't mean to imply that -echo take the place of -execute.  I just meant to say that if you add -q, then you must add an echo if you want to still receive the "{ready}" message.  You can echo whatever you want, so you could add a sequence number if you want too.  In all cases, -execute is still required.  Read the description of the -echo command in the application documentation.  It gives all of the details about what this option does.  There is no black magic.

- Phil

[TSM]

Right I was going around in circles until i checked the code.

This has only become available since Jan. 27, 2013 - Version 9.15, hmm im still on 9.02

Time for an upgrade me thinks.

Also to help others, syntax should be as follows, remember each arg needs to be on its own line.

Code Select Expand


-q
-echo3
{ready}
testfile.jpg
-execute


Now I can update the PHP script to allow for this.

[Phil Harvey]

Ah.  I forgot to check to see if you were using a recent version.  Glad you caught this.

- Phil

[TSM]

Another thing, when posting multiline data such as IPTC:Caption-Abstract, normally we are using \n to split the line as we are linux based but this causes an issue to the stay_open as it uses \n to split commands, what do you do in this instance?

[Phil Harvey]

There are various work-arounds.  See FAQ 21 for details.  The first technique won't work for argfiles, but the others will.

- Phil

[TSM]

Hmmm interesting.

Would seem the best is to accept entities then 
 in my case (option b) as im feeding in the tags directly for each image i process.
May be an idea for me to add this directly into my API so others do not come across the problem, make it a toggle to switch it on/off and handle the conversion itself.

Also, normally when I was writing tags on the CLI I would wrap the data of each tag in quotes, it seems if this is done with stay_open it renders these quotes, would I be correct in saying the quotes on the CLI are interpreted by the shell before passing the args to exiftool but when using stay_open it is already within the app it does not and so it considers everything after the '=' to be the data to the '\n' character for that tag?

[Phil Harvey]

would I be correct in saying the quotes on the CLI are interpreted by the shell before passing the args to exiftool but when using stay_open it is already within the app it does not and so it considers everything after the '=' to be the data to the '\n' character for that tag?

Correct.

  -@ ARGFILE
            Read command-line arguments from the specified file.  The file
            contains one argument per line (NOT one option per line -- some
            options require additional arguments, and all arguments must be
            placed on separate lines).  Blank lines and lines beginning with
            "#" and are ignored.  Normal shell processing of arguments is not
            performed, which among other things means that arguments should
            not be quoted and spaces are treated as any other character.

- Phil

[TSM]

I hope final one for today.

When using stay_open for writing to a file, I never seem to get any return data to say its done or if there was an error, ive forced errors such as file not existing etc but still nothing.
The only core params that are being set before writing args are ...
-g
-j
-coordFormat
%.6f
-E

Is this normal behaviour?

[Phil Harvey]

Typically the errors go to stderr.  Are you reading this exiftool output?

- Phil

[TSM]

I am but only to a log file, ile have a look at parsing the data but there are a fair few things to check.
It would be nice if possible to have a basic output to the STDOUT when writing files that can be parsed easily with a more verbose log to the STDERR.
Also the error log does not contain any output such as {ready}, the only way I was going to work with it is read all the data into a variable then parse it after the STDOUT has returned {ready}, on the next cycle reset the buffer and start again.

[Phil Harvey]

You can add "{ready}" to the stderr output with -echo4.

See cpp_exiftool for an example of how to do this in C++.

- Phil

[TSM]

Thank you, that was helpful and ive taken a few functions from the C++ implementation into the PHP one.

Ive updated the API to implement getError/getErrorStr/getSummary

getError($id) - false if there is no error, the last error string
getErrorStr($id) - returns STDERR output regardless if there was an error
getSummary($msg) - returns value for summary message

Note that $id should only be supplied if you have passed a batch of different requests and executed fetchAll() as the return data will be an array of results, the index will be $id, if you leave as blank then it will only return if you had used fetch();

[Phil Harvey]

I just took a look at this code again.  By odd coincidence I'm using the -php output formatting for the C++ ExifTool communication.  But you're using -json format with PHP. 

I think the reason I did this was because the -json option didn't support binary output when I wrote the C++ ExifTool interface.  But the binary output in JSON is a bit of a kludge, so I don't regret this.  There may have also been a problem with JSON requiring well-formed UTF-8.

- Phil