Strange Behavior

[Regor250]

Just ran into a very strange issue. For some reason, ACDSee Ultimate decided not to like a certain folder. Whenever I opened it, the app crashed. I optimized the database to no avail, I renamed it and its parent folder, still crashing, so in file explorer, I copied the folder to another location; ACDSee could open that folder without issue. I copied the filed from the duplicate folder back in the original overwriting the files, still crashing so I deleted the folder altogether and moved the copy (from ACDSee) back where the old one was and now it works. Weird!

[MrSteveVee]

I have had something similar but with TIFF files. I have quite a lot of scanned Tiffs each around the 65mb size. Some of these AC will open to develop quite happily, but quite a lot of them AC will fail with the cannot develop (or some such phrase) error , so for a while I was using other software to convert the Tiff to another Tiff and that seemed to work albeit long winded.
By chance I found that If I used AC to move the images into a new folder (I was segregating them to "re-tiff") AC would then allow me to develop them quite happily. Additionally If I moved them back to the original folder AC was still quite happy. How bizarre! I checked the images for "read only" etc but nothing seems to be in error and other software has no problem editing them, most strange. I have since found that although AC cannot develop them it will quite happily export them to another format so now I just export the undevelopable Tiffs to a PSD format and for me a PSD means a copy of a Tiff Lol.

[Regor250]

One other thing I ran into was on opening the app while pointing to a new database location. I wanted to share the same database between 2 different users on the same computer, so I copied the default database to a shared location and renamed it. For some reason, unbeknown to me, in the process it became read only, which prevented ACDSee from opening it successfully, however rather than asking me to open a different database it simply crashed. Not particularly elegant. I tried the usual load while holding the shift key as a way to bypass the offending database to no avail. What could have I done if the database was corrupt if the app won't even load?

[MrSteveVee]

Lucky you sussed the problem, could have been a long head scratcher for sure. As well as Database backups I use FreeFileSync to mirror the database and Images to a backup drive, "just to be sure" lol

[Greyfox]

One other thing I ran into was on opening the app while pointing to a new database location. I wanted to share the same database between 2 different users on the same computer, so I copied the default database to a shared location and renamed it. For some reason, unbeknown to me, in the process it became read only, which prevented ACDSee from opening it successfully, however rather than asking me to open a different database it simply crashed. Not particularly elegant. I tried the usual load while holding the shift key as a way to bypass the offending database to no avail. What could have I done if the database was corrupt if the app won't even load?

That raises a question from me.
Say you have processed a photo, for example Fido.jpg, given it keywords, captions, whatever, and embedded the metadata. Your copy of the database and that photo are in sync.

Now the other user on your PC opens their copy of the database, accesses Fido.jpg and adds to or changes the metadata and also embeds the metadata in the image..

When you next open your copy of the database, it will not be "in sync" with the changes made, and my experience is that even re-cataloging a photo that is already in the database doesn't always update the database from the embedded metadata.There is a thread on this somewhere.

So my question is, how do you intend to keep both databases and the images all synchronized?.

[Regor250]

That's why I wanted one single database in a shared location. I tried and both user accounts could be logged in the same database instance simultaneously, sort of as only one user can be "active" at a time (this is not a network, but one computer with 2 user accounts) so there is no data conflicts to be resolved. To achieved this I copied the database into the application data folder, and made the folder shared with the app and all users. So far this seems to work.

[Greyfox]

That's why I wanted one single database in a shared location. I tried and both user accounts could be logged in the same database instance simultaneously, sort of as only one user can be "active" at a time (this is not a network, but one computer with 2 user accounts) so there is no data conflicts to be resolved. To achieved this I copied the database into the application data folder, and made the folder shared with the app and all users. So far this seems to work.

My bad, for some reason I had the idea each user had their own database. Now I read your post again, I see they are sharing the same database, and on a single PC, only one user can be active at a time, so that shouldn't be a problem.

[Emil]

When you next open your copy of the database, it will not be "in sync" with the changes made, and my experience is that even re-cataloging a photo that is already in the database doesn't always update the database from the embedded metadata.

If the "embed pending" flag is set for a catalogued item re-cataloguing will not read embedded proprietary AC meta data. At that time there's a conflict between meta data existing in the db not jet embedded and the embedded meta existing in the file to be catalogued.

This is in complete contrast to the handling of iptc meta data. (Which imho is much smarter :-)

Work around: First embed all changed meta data, then start the cataloguing function. I'd not reset the embed pending flag. This might delete meta data for files I don't need to catalogue.

[Greyfox]

If the "embed pending" flag is set for a catalogued item re-cataloguing will not read embedded proprietary AC meta data. At that time there's a conflict between meta data existing in the db not jet embedded and the embedded meta existing in the file to be catalogued.

This is in complete contrast to the handling of iptc meta data. (Which imho is much smarter :-)

Work around: First embed all changed meta data, then start the cataloguing function. I'd not reset the embed pending flag. This might delete meta data for files I don't need to catalogue.

The situation I referred to is where the embedded information in an image or some images is newer than the information in the database, or some of the database metadata has been deleted. The most current information is what is embedded in the images, and the exercise is to update the database record from the images.

Back in October 2020, I raised an issue with Customer Support that if an image has been previously cataloged, and subsequently its ACDSee metadata in the database gets changed or removed, then Tools->Database->Catalog Files will not restore the ACDSee Metadata in the database from that embedded in the file itself.

A similar situation occurs where the embedded metadata in an image or some images already in the ACDSee database has subsequently been changed by other software, but the images are left in their original location. Simply re-Cataloging does not update the database information.

The outcome of that issue was that Support indicated the following steps were needed to have the embedded data update the database

1. Select the images concerned
2. Right click, Metadata->Clear embed pending icon
3. Tools->Metadata->Rebuild Thumbnails and Metadata
4. Tools->Database->Catalog, then add the folder the images are in to Folders to catalog
5. Run Catalog.

The above is not necessary if the images have been moved to a different folder.

[Regor250]

I suppose a decision must be made as to what metadata information take precedence when "re-cataloging", the database information or the embedded information. Ideally if database information already exists, a dialog box should pop up asking which data you wish to preserve, just like importing duplicate files with the standard apply to all option. In turn there should be a default option that can be set by user. This might be worth raising a Change Request.

I can see a number of situations when one way is preferred, and vice versa. If a file has its embedded metadata deleted by another app, I certainly don't want to delete the corresponding database information if I re-catalog the file. On the other hand if I purposely updated the embedded metada outside ACDSee, then I'd want re-catalog to update the database. ACDSee has established its precedence as the source of information, hence does not modify its database unless you purposely remove the information prior to re-cataloging. Makes sense.

[Greyfox]

I suppose a decision must be made as to what metadata information take precedence when "re-cataloging", the database information or the embedded information. Ideally if database information already exists, a dialog box should pop up asking which data you wish to preserve, just like importing duplicate files with the standard apply to all option. In turn there should be a default option that can be set by user. This might be worth raising a Change Request.

I can see a number of situations when one way is preferred, and vice versa. If a file has its embedded metadata deleted by another app, I certainly don't want to delete the corresponding database information if I re-catalog the file. On the other hand if I purposely updated the embedded metada outside ACDSee, then I'd want re-catalog to update the database. ACDSee has established its precedence as the source of information, hence does not modify its database unless you purposely remove the information prior to re-cataloging. Makes sense.

I too would much prefer that data in the database could not be accidentally over written by any process affecting groups of files, unless the user has a specific reason for doing so..

It does however appear to be more complex than I had previously thought.

At https://iptc.org/standards/photo-met...iptc-standard/ part way down the page there is a link to download a reference image that contains all the metadata fields defined by the Standard 2019.1 IPTC standard. It's a handy image to have in the tool box for testing.

Now consider this scenario

1. I placed a JPG copy of the IPTC Reference image in a new "test" folder on its own, and cataloged it into the ACDSee Database.
At this point in Properties->Metadata->IPTC (set to all IPTC) the majority of the displayed fields contain information.

2. In Properties->Organize I assigned the keyword "Reference Image"
In Properties->Metadata->ACDsee Metadata I added a Caption, an Author, some text in Notes and I gave the image a Red Label.
I embedded the ACDSee metadata in the image (Tools->Metadata->Embed ACDSee metadata and then exited ACDSee.

3. I opened the image in the test folder in another fairly well known (and relatively expensive image editor), running in freestanding mode, and simply applied a B&W conversion, then exported the converted image into the test folder, choosing to overwrite the one I had prepared.

4. I then opened that image in ExifToolGUI. That confirmed that as expected there was NO IPTC or XMP metadata left present in the image. (I'm well aware that the editor in question doesn't retain either IPTC or XMP metadata).

5. Restart ACDSee.
The image thumbnail now appeared in the B&W form, but still showed the Red Label.
The IPTC medadata fields were empty, but the ACDSee Metadata fields were all showing the original information (presumably this was from the database, since these fields were no longer embedded in the image).

At this stage, it doesn't appear that it would be possible to recover the stripped IPTC metadata, but the ACDSee metadata from the database could be re-embedded in the image.
From the point of this exercise, at this time though, I didn't do that.

6. In Manage mode, I clicked on Tools->Database->Catalog Files, set the Test folder as the only folder to catalog, made sure the "Import from Cataloged files" boxes for "Exif and IPTC metadata", and "ACDSee Metadata including categories, keywords, tagged and collections" were both ticked, and File Formats was set to "Catalog images", then clicked on start. At completion it showed Catalog Complete, 1 item cataloged.

7. With the image again selected in Manage mode, the thumbnail still showed the Red Label, and in Properties (default Metadata view) all the ACDSee metadata Field entries were unaltered, suggesting that that the Catalog process in this instance hadn't overwritten and destroyed the ACDSee metadata in the database.

8. The next move was to carry out the steps listed in my previous post, ie. (1) Select the image, (2) Right Click, select Metadata->Clear embed penging icon, (3) Use Tools->Metadata->Rebuild Thumbnails and Metadata, and (4) Use Tools->Database->Catalog (with the test folder only selected) to re-run Catalog.

I had expected that to overwrite and thus destroy the ACDSee metadata in the database. IT DIDN'T. Again no change to the ACDSee metadata fields.

9. After changing the label to Blue (to set the embed pending flag) I used right-click, Metadata->Embed ACDSee metadata to re-embed the ACDSee metadata from the database into the image and then exited from ACDSee..

10. I then opened the file in ExifToolGUI. Whilst there was still (as expected) no IPTC metadata present, the ACDSee Metadata was now present in the XMP-acdsee section.

11. Whilst in ExofToolGUI I manually changed the entries for XMP-acdsee Author, Caption, Keywords, Notes, Rating and Label so they well all different to the original entries.

12. Restarted ACDSee, and in Manage Mode changed to the Test Folder.
The image (still in B&W) now showed the color label as Green (as changed in ExifToolGUI), and the Properties->Metadata->ACDSee Metadata fields Caption, Author, Notes and Label showed the values manually entered in ExifToolGUI BUT NOT the keywords field, which still showed the original keywords.

So at this point in time, it appeared that if the embedded ACDSee metadata has been removed, selecting the image will still show the original database metadata, but if the ACDsee metadata has been altered it will show the altered metadata, with the exception of Keywords which remain as those previously in the database.

13. I now did a simple Tools->Database->Catalog Files (as per step 6). That resulted in the Keywords now showing the one manually changed in ExifToolGUI.

So again, the indication is that if the Keyword field data has been stripped, the original database keyword data will remain after a re-Catalog, and if it has been changed, unlike the other ACDSee metadata fields, selecting the image will continue to show the database keyword data, but re-cataloging will change it to the embedded Keyword.

Still a mystery

(a) I don't know at step 12 (where the Caption, Author, Notes and Label shown are the embedded data) whether the database has been updated or not.
(b) I don't know why there is the inconsistency between the ACDSee metadata Keywords field and the other ACDSee metadata fields, as seen in steps 12 and 13.

Would be nice to get some official comment on exactly what is supposed to happen in this sort of scenario.

[Regor250]

Interesting! All ACDSee metadata ought to be in the database that's a given. When does it get updated by embedded data? To answer your question (a), manually delete the ACDSee metadata again in a step 12.1 (i.e. before 13), what does it show, the old or what was the "new metadata" you just deleted? It would be good to know. It seems ACDSee showed the embedded metadata as a priority if not blank, except for keywords (and cstegories?), otherwise show the database information like it must when no data is embedded into the file.

As for (b) I'd have to give that more thoughts as to why. I suspect the answer is because of the hierarchical nature of it and database indexing associated.

Addendum: playing with it, it looks like those fields that can be updated under ACDSee Metadata panel (and some can't be) are those that are read from embedded XMP metadata without the need to Catalog. If the value <> null, then ACDSee reads it and updates the corresponding database variable, if = null it is ignored and the value present in the database is displayed, which is a good thing. I guess ACDSee treat changes to these embedded variables as intentional, hence the one to keep, whereas a null value could be un-intentional, hence to be ignored.