Writing metadata on download broken in latest svn builds

[Stephen S]

I have spent the better part of the day tracking down some very odd behavior in the metadata that is written to download files. I have three different sites (that are all at the latest svn version) and they are exhibiting the following behavior when downloading previews:

1. The scr (screen) size preview will always download with all the correct metadata written to the file (I'm using Photoshop's file info tool to check the metadata btw)

2. None of the other sizes will write all the meta data to the files.

3. Some older files that were uploaded seem to have correct meta data on download of the various sizes. Some don't. But re-uploading the originals in the latest svn version always causes the identical new behavior outlined in 1 and 2 above, regardless of whether the metadata for downloaded sizes were working for the earlier versions.

Driving me (and a client) crazy, anyone else experiencing this or have any suggestions? Thanks!

[Stephen S]

To make sure this wasn't based on some crazy config, I just did a clean install and experience the exact same problems. Here is a little more info:

1. Out of the box, no config changes, metadata will NOT be written on download, but previews some previews (not SCR) will have original meta data from the file

2. Adding $force_exiftool_write_metadata = false; $exiftool_write_option = true; (as per instructions to force writing of meta data) results in SCR having correct meta data on download, and most of the others missing at least the title meta.

Does anyone on the dev team have any insight here, please?

[Stephen S]

OK, this is NOT a latest builds thing after all. I just installed a stock 7.8 and I have the exact same problems. Really, has no one else seen this or does no one use the metadata writing into downloads?

[Stephen S]

After still more investigation:

1. It seems that the exiftool command would fail the same way when run in a shall directly against the file. Debugging verified that it WAS being run after all

2. I found that if (in the shell) I attempted a repair of metadata (exiftool -all= -tagsfromfile @ -all:all -unsafe -icc_profile FILENAME ) it would then afterwards properly write the metadata to all files.

3. Using this knowledge, I thought perhaps using the option:

$exiftool_remove_existing=true;

 to remove all tags and then have them re-added would help BUT This fails in all kinds of ways on any install (at least for me):

a. no metadata is ever written, the files only have whatever metadata was in the original file, nothing that was added in the system

b. Now the SCR image contains NO metadata

I have also tried every combo of:

$force_exiftool_write_metadata = false;

$exiftool_write_option         = false;

but to no avail.

Maybe what is needed is an option to "fix" the files before writing. I will try to include an option for that and see if that works...

Does ANYone have ANYthing to suggest here? Thanks,

[Stephen S]

Hopefully this will help someone else. I think I have a fix:

1. Created a new config option:

$exiftool_repair_existing=true;

2. Modified resource function (write_metadata) on line 1918 to add this config option:

global $exiftool_repair_existing,$exiftool_remove_existing, $storagedir, $exiftool_write, $exiftool_write_option, $exiftool_no_process, $mysql_charset, $exiftool_write_omit_utf8_conversion;

AND added this new line right after $exiftool_remove_existing (line 1948):

if ($exiftool_repair_existing) {$command.= "-all= -tagsfromfile @ -all:all -unsafe -icc_profile ";}

What this does is repair bad files, of which my client had a lot of them. They all seem to come from an older version of Photoshop. Hope this helps someone else. I think it should probably be included in the core, but that is obviously up to the devs.

[Stephen S]

after talking with the client, it seems most of these files had their metadata tinkered with in Lightroom before uploading initially. I suspect there is an incompatibility with those files, but my fix seems to work regardless of source.

[Frederick Yocum]

@Stephen S I had nothing to contribute to solving the problem you were experiencing with ResourceSpace, but I did want to thank you for posting your progress as you tracked through the issue. This may help me or other users in the future.

[Stephen S]

Hi Frederick,

Thanks so much for saying that. Sometime I feel a bit like a crazy person posting in such detail about problems, wondering if it is just annoying people. You telling me it is useful to you and others is highly appreciated. :)

S

[fauw...@gmail.com]

THX from me too, i struggle a lot with writing metadata on RS and so I have another suggestions, what it could be. I will check, if Adobe Bridge could be the reason also.

Greetings, Karsten

[J. Manuel Velasco]

Agreed, +1 to give details of what you are trying.

I had problems recreating previews and I fix it disabling the snapshots creation.

$ffmpeg_snapshot_frames=0;

I don't think this is related to the post, but just another tip :)

Regards.

2017-06-13 11:01 GMT+02:00 <fauw...@gmail.com>:

THX from me too, i struggle a lot with writing metadata on RS and so I have another suggestions, what it could be. I will check, if Adobe Bridge could be the reason also.

Greetings, Karsten

--
ResourceSpace: Open Source Digital Asset Management
http://www.resourcespace.com

---
You received this message because you are subscribed to the Google Groups "ResourceSpace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to resourcespace+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.