Exif and exiftool questions

[Duane Mitchell]

I'm having a problem with data being extracted from image files. Nothing is being extracted. This is a new issue. In my Installation Check it shows EXIF extension as OK. ExifTool reports this error:

FAIL:
Unexpected output when executing -ver command. Output was ''.

If I understand the documentation I don't need ExifTool but can map IPTC fields in the config.php file. That would work for me. For example IPTC 2#120 maps to the ResourceSpace Caption field.

If I were to add the allowed fields to the config.php would it look like:

$exif=2#120; #Caption

$exif=2#025; #Keywords

Not sure exactly how to frame this question but I'd like to do a sort of best practices and get it right.

I am on shared hosting and see I can add PERL modules. One is ExifTool 11.85 and then all kinds of modules as well. About 200 of them for about every device and file format there is.

It's a bit confusing.

Thanks.

[Duane Mitchell]

Following up here...

I have reviewed the IPTC mappings in Manage metadata fields settings of System Setukp and they appear correct. For example 2#120 is entered in the correct field of Advanced Settings for Caption. That's always been correct and I'm not sure why the IPTC fields have stopped importing with the new version of RS.

I also don't understand how to implement this line found in the documentation:

Exif fields are mapped using the $exif_* settings in include/config.php.

I've tried several variations of this and they all cause errors. Not sure if I'm missing something or something is not correct?

[Duane Mitchell]

Yes, I caught my syntax error and changed the = to _ in $exif_

On Tuesday, May 19, 2020 at 4:50:20 PM UTC-4, Duane Mitchell wrote:

[Duane Mitchell]

Following up once again. This is looking like a fault/bug in the latest release of RS. I did a clean install of version 8.6.12117. The metadata is extracted perfectly. There is no change in the server config.

I'm going to try a clean install of version 9.0. I'm pretty sure it all worked there.

On Tuesday, May 19, 2020 at 4:50:20 PM UTC-4, Duane Mitchell wrote:

[Duane Mitchell]

I created a clean install of RS 9.0.13003. That also works with the metadata. In the process I noticed that the ExifTool  field for the path was autofilled in both this install and the install for v8.6.12117. Not so in the v9.2 installs. I added that path to the config.php and it all works as it should.

On Tuesday, May 19, 2020 at 4:50:20 PM UTC-4, Duane Mitchell wrote:

[Mike Perry]

What was the wrong path that was added with the clean 9.2 install??

[Duane Mitchell]

It's getting a little confusing because I've got 8 installs of RS going right now of 4 different versions. Some are upgrades and a couple are clean installs. Two are on hosted sites and 6 are on my MAMP development server. This line had to be added to the config.php of some:

$exiftool_path = '/usr/local/bin';

In reviewing my notes I'm not sure if that path was not there in the Install window to begin with or if the path could not be verified as shown in the screen shot and I deleted it. I'll keep an eye out for this next time I do an install.

[Duane Mitchell]

BTW, adding this path to ExifTool line does not work on my hosted server. If you have any ideas about that I would greatly appreciate it. I need to get a site over to the live server.

Running the Installation Check tells me the version of ExifTool is 11.38. I guess that means that RS installed it? Not sure what I need to do on the hosted service. Maybe add Perl modules for ExifTool?

On Wednesday, May 20, 2020 at 10:23:16 AM UTC-4, Mike Perry wrote:

[Mike Perry]

I doubt that RS had permission to install exiftool on the shared server.

Can you SSH into the server and check to make sure exiftool is installed in the /usr/local/bin folder??

[Duane Mitchell]

I cannot get access to the root level of the server. I can only get to my home directory. Which has a lot of software. I can install perl modules and one is ExifTool 11.54.

Exif is compiled as part of PHP. What also puzzles me is that the RS documentation says I don't need ExifTool for my purposes as the IPTC data should be imported and extracted into the database. I'm pretty sure it used to be prior to upgrading. I'm going to look into it more.

https://www.resourcespace.com/knowledge-base/resourceadmin/metadata-read-write-mapping

I have a good working relationship with my hosting company. They are always willing to work with me but I don't think they'd install exiftool on a shared server.

I've never needed to install perl modules on any website so I'm not sure what's involved. Time to find out I guess.

[Duane Mitchell]

This gets more curious. I just did a clean install on my hosting service of v8.6 and it works perfect with extracting IPTC metadata. ExifTool was not installed nor any attempt to install it was made by the installer. I'd call this progress. More to do.

On Tuesday, May 19, 2020 at 4:50:20 PM UTC-4, Duane Mitchell wrote:

[Duane Mitchell]

Here's a screenshot of the Installation Check. Note the ExifTool report of not found. Previously there was an error attempting to get the version.

[Duane Mitchell]

I don't think this should be happening. I did a clean install of v9.2.14719 and I did not specify a path to install ExifTool. Yet it appears to want to check for it in Installation check.

On Tuesday, May 19, 2020 at 4:50:20 PM UTC-4, Duane Mitchell wrote:

[Mike Perry]

Using Filezilla I can view the contents of the usr folder. Using putty (logging in via SSH I can also view the usr folder and it's contents. Obviously I do not have permission to write, delete, or edit files in those folders, but I can view them.

My host company did perform an update of pdftotext for me; they won't install antiword on a shared server due to the dependencies and potential issues with them.

With the issues you're running into I wonder if there might be an OS install issue -- things seem pretty flaky. . .

[Duane Mitchell]

I don't think there's much of a chance that there is any OS issues. Either on my desktop, development server, or hosting service. I've been using the same hosting service for well over 10 years. This issue is new to version 9.2. I've installed versions 8.6 and 9.0 with no problems. This is what the installation window should look like for ExifTool prior to running the installation prior to v9.2. No path specified because it doesn't exist and, in fact, is not needed for my purposes.

Here is what the System check looks like post installation.

The ExifTool check fails because there isn't one. This is the correct outcome.

Here is the Installation Check post in v9.2.

Notice the error. It should not do that. It's trying to run a version check on something that doesn't exist. This I believe is the clue to my issues regarding metadata.

I would be happy if it just worked like the documentation says it should work. That is, with no ExifTool at all. I don't need it but something is causing this error. It's described here.

https://www.resourcespace.com/knowledge-base/resourceadmin/metadata-read-write-mapping

In my testing I've dug up some older versions of RS and I have them going back to 4.2 which was 2011. I've been working with RS off and on since then. I've worked with DAM systems since the mid 1990's. Media Bank, Telescope, and MetaCommunications. I may not be expert in RS but I do believe this issue lies with the v9.2 release.

[Duane Mitchell]

This is what I want to do. It doesn't work for some reason.

https://www.resourcespace.com/knowledge-base/resourceadmin/advanced-configure-metadata-field

On Tuesday, May 19, 2020 at 4:50:20 PM UTC-4, Duane Mitchell wrote:

[Duane Mitchell]

Working with my hosting service I was able to get exiftool installed. This solved the issue. Not all hosting services are equal. I have a good one in Rochen.

According to ResourceSpace documentation I should not need exiftool to import the IPTC metadata I wanted. I've been using ResourceSpace since version 4 in 2011. It's always worked that way up until version 9.2. Not sure what the issue is but after a LOT of hours chasing it down I got it fixed and that's what matters.

On Tuesday, May 19, 2020 at 4:50:20 PM UTC-4, Duane Mitchell wrote: