running exiftool as Java process vs commandline returns fewer fields

[willhays]

When I execute exiftool in a Java program on a Quicktime .mov file, I get 112 fields versus 150 on the commandline.
In particular, the duration field is not showing up in Java.   What am I missing?

Code Select Expand


        String[] commands = new String[] { "exiftool", "-a", "-u", "-G1", f.getAbsolutePath() };
        Process child = Runtime.getRuntime().exec(commands);


[Phil Harvey]

I would have to guess that you are running either a different version of exiftool, or using different options with the command.

- Phil

[willhays]

The exiftool output for both says it's the same version (8.66).  The explicit options are the same for both cases.  Also, there is only one copy of the target file and there is plenty of output from exiftool to confirm this.

I went through various combinations of option parameters on both sides, but never to the point of getting the same fields to display and in particular I could never get the 'duration' field to display under Java.  On the Java side, something is blocking some fields from displaying.

[Phil Harvey]

OK, well it wasn't the simple explanation. Maybe if there was a pattern to the missing tags it would tell us something. Are they all in the same group?  Are they always the last tags extracted?  If the latter, are you closing the pipe before flushing the buffers?  ...

[willhays]

I couldn't find a pattern.  In particular, the 'duration' field is in the 'quicktime' group and the other quicktime fields show up.  What I saw that may be diagnostically useful is that by default, i.e. without the -a -u -G1 params, the Java version displayed properties, e.g. 'preview duration : 0s' that only displayed on the commandline with the extra params.

Unfortunately, I'm on a deadline to get a particular set of records on our website for review so I'm going to run the commandline version of exiftool to pregenerate the metadata with your handy autonaming option. 

I know this looks like a dumb configuration or setup error, but I just can't see it if that's what it is.
Thanks for considering the problem.

[Phil Harvey]

OK, well I hope you get some time later to come back and figure this one out.  I hate unresolved issues.

Another possibility is if you have a ".ExifTool_config" laying around, due to different environment for the Java it could be invoked in one case but not in the other.  Also, are you looking at the stderr output from Java?  There is an outside chance that an error is occurring (maybe due to a memory limitation while running inside Java?)

- Phil

[rkalla]

Will,

I have an inkling that you might not be reading back the entire reply from the Java InputStream that is streaming back the results to you.

Are you just doing a single readLine on a BufferedReader or maybe just filling your read byte[] once and then parsing the results?

If you are using readLine and not getting all the results back, that is because ExifTool may not necessarily being using \n chars to terminate output the way BufferedReader expects it.

I'd suggest using an InputStreamReader to read the feedback from ExifTool with a char[] buffer, maybe say 2048 in size, and keep appending the results as long as the read command returns > -1 to a StringBuilder, then outputting that, something roughly along the lines of:

Code Select Expand


int charsRead = 0;
char[] buffer = new char[2048];
StringBuilder reply = new StringBuilder();

while((charsRead = inputStream.read(buffer)) > -1) {
  reply.append(buffer, 0, charsRead);
}

System.out.println("Total Reply: " + reply.toString());


I thought this might be one place to check given the oddity of the problem, I could be way off though.