Serious Issue - Keywords fail & photo is deleted

(13 posts)
  • CariCreates
    Member

    I'm not seeing this issue elsewhere in the forums, so I'll throw it out there before I contact Support directly. This past week I have had a terrible issue start with ACDSee Pro 2. I will be working to add keywords to my photos. I can do dozens without any problem, or maybe just a few - different each time. Here is the sequence:
    - Click on photo
    - Click in Keywords
    - Type words
    - Click on the "..." button in Keywords to see the Keyword list OR just hit enter when finished typing in keywords
    - Photo disappears and error message pops up: "Failed to update Keywords Value."
    - I check the folder where the photo was at on my hard drive and it is gone from there. It is gone from the entire computer.

    You can imagine how upsetting & frustrating this is. Thankfully, I have had backups of every photo elsewhere and have not had an outright permanent loss, but this is totally unacceptable. Has anyone else encountered this? Are there any ideas/answers?

    Thanks!

    ~~Cari~~
    www.CariCreates.com

    P.S. When previewing photos, I am having occasional crashes by ACDSee Pro 2 as well. Not sure if connected, though one would suspect it might be.

    Posted On July 27, 2008 - 09:30 PM (1 year ago) (Permalink to this post)
  • Chippy
    Moderator

    Hi Cari,
    I cannot duplicate your problem.(At least with files I have.)
    Are you entering keywords in the ACDSee database or in the IPTC Keyword list?
    Are the images Read Only?
    Are they on a CD/DVD?
    Are they just JPG or some other format?
    Have you checked in the Quarantine Files, listed under Database, to see if your files have been put there?

    Posted On July 28, 2008 - 09:05 AM (1 year ago) (Permalink to this post)
  • CariCreates
    Member

    Chippy said:

    Hi Cari,
    I cannot duplicate your problem.(At least with files I have.)
    Are you entering keywords in the ACDSee database or in the IPTC Keyword list?
    Are the images Read Only?
    Are they on a CD/DVD?
    Are they just JPG or some other format?
    Have you checked in the Quarantine Files, listed under Database, to see if your files have been put there?

    Yes, it's a very random problem. I'm sure I could not duplicate it if I tried. As I said, I can do the same exact thing many times and not have a problem. I have processed a few hundred photos in the past week or so, and this has happened just 3 times, all on different days and in different folders.

    First what I'm running:
    Windows Vista Prem Home
    ACDSee Pro 2 Build 238
    Intel Core 2 Duo
    2GB RAM

    The issue occurs when I am entering keywords in the IPTC Keyword box.
    The images are not Read Only.
    They are on my hard drive.
    They are JPGs.
    There are no files in my Quarantine files.

    This occurs when I am just going through the photos in any given folder, entering IPTC keywords for each, and suddenly one will get this error and disappear. The other photos will be fine. Oddly, when I open the IPTC Keyword list afterwards, the new words I had added in the keyword box are now showing up in the list. But the photo is completely deleted from my system. Just awful.

    Posted On July 28, 2008 - 09:13 AM (1 year ago) (Permalink to this post)
  • Marc Sabatella
    Moderator

    Given the random nature of the problem, this will be hard to check, but can you prove the files were actually there before you started writing to them? It occurs to me something could have gone wrong between the time ACDSee first saw the file - and hence was able to display a thumbnail - and when you tried to edit IPTC. If the info about the file was still in ACDSee's database but the file itself was gone by the time you tried editing IPTC, that might explain the behavior you are seeing.

    But I too have never heard of anything like this happening. I'd say contacting support is definitely in order.

    Posted On July 28, 2008 - 02:37 PM (1 year ago) (Permalink to this post)
  • CariCreates
    Member

    The files were definitely really there. I even had this happen once this past week and I tried immediately copying the backup of the photo back into the current directory (using Windows directories, not ACDSee) and when I entered keywords back into it using ACDSee, the same error immediately occurred to the photo. Then I closed ACDSee, re-opened it, (after re-copying the backup file to the directory again), and was able to edit it without problems. Seriously random. Seriously frustrating.

    Posted On August 18, 2008 - 11:11 AM (1 year ago) (Permalink to this post)
  • rbeal
    Member

    CAUSE OF LOST FILES
    This bug is caused by the system simply overwriting the file when it updates it. If this fails for any reason the file vanishes, since it is deleted first then written.

    SOLUTION
    If the file is called xxx.jpg what it should do is rename the old file to xxx.bak, then write the new file, then delete the xxx.bak file. That way the file can't be totally lost. This is fairly basic programming technique! (It doesn't solve the underlying problem of why the program sometimes gets an error when trying to write a file, but it does stop data loss.)

    DEMONSTRATION OF BUG
    I've seen this happen. If you want to demonstrate it simply select every file using the image well, then select them all. Then use the Tools/Batch set information to update some EXIF and IPTC fields in every record, e.g. Copyright, Credits. I suggest you have say 20,000 photos selected so you have a good chance of seeing it. Then set it going. It will take a day or so depending on your machine.

    You may see some files listed as having problems at the end. Some will be quarantined, they can be removed from quarantine and then processed one by one. Others will have simply vanished. If you see no errors, repeat the exercise until you do.

    Hope this helps!

    PS. A related question for you. Does updating the metadata in batch like this cause each JPG file to be uncompressed and then compressed again - i.e. losing some quality?

    Posted On August 21, 2008 - 04:13 AM (1 year ago) (Permalink to this post)
  • rbeal said:

    PS. A related question for you. Does updating the metadata in batch like this cause each JPG file to be uncompressed and then compressed again - i.e. losing some quality?

    No. The image doesn't have to be uncompressed; it is just the metadata that is rewritten. (Some time ago I checked a before and after Jpeg in Photoshop Elements, just to be sure, and the images were identical.)

    Posted On August 21, 2008 - 08:24 AM (1 year ago) (Permalink to this post)
  • CariCreates
    Member

    rbeal said:

    CAUSE OF LOST FILES
    This bug is caused by the system simply overwriting the file when it updates it. If this fails for any reason the file vanishes, since it is deleted first then written.

    SOLUTION
    If the file is called xxx.jpg what it should do is rename the old file to xxx.bak, then write the new file, then delete the xxx.bak file. That way the file can't be totally lost. This is fairly basic programming technique! (It doesn't solve the underlying problem of why the program sometimes gets an error when trying to write a file, but it does stop data loss.)

    That explanation makes sense. I am glad someone else understands what I've been talking about. Hopefully, the programming will be adjusted in future builds.
    Thanks for the info.

    Posted On August 21, 2008 - 10:17 AM (1 year ago) (Permalink to this post)
  • rbeal
    Member

    John_R said:

    No. The image doesn't have to be uncompressed; it is just the metadata that is rewritten. (Some time ago I checked a before and after Jpeg in Photoshop Elements, just to be sure, and the images were identical.)

    I would like to think you are right.

    But you really can't tell from looking at a single change from saving a JPG. It takes multiple saves to be obvious, and even then it depends on the photo. A clear blue sky is perfect for seeing the defects appear. After 8 saves you can see them clearly. After 32 it looks terrible. I reckon that under 4 saves it is hard to tell.

    Please can an ACD person tell us the authoritative answer? (I can see files getting a bit smaller after a metadata change, which made me suspicious).

    Posted On August 21, 2008 - 10:28 AM (1 year ago) (Permalink to this post)
  • rbeal
    Member

    CariCreates said:

    That explanation makes sense. I am glad someone else understands what I've been talking about. Hopefully, the programming will be adjusted in future builds.
    Thanks for the info.

    It would be good to hear an ACD person confirm that they have understood what we have told them. It reduces one's faith in a product when it discards the odd photo on a random basis. If they make the change I've suggested then at least the photo would be safe.

    Posted On August 21, 2008 - 10:32 AM (1 year ago) (Permalink to this post)
  • rbeal said:

    I would like to think you are right.

    ... But you really can't tell from looking at a single change from saving a JPG. ...


    I'm not talking about doing a visual comparison: I put the images on two layers set to "Difference" mode, and the result was pure black (i.e. no difference at all).

    The file size difference is most probably due to some metadata being stripped out (I lose some camera-specific data fields for example) and/or repacked. As far as I'm concerned that data loss is the only negative to rewriting image files, but I've learnt to live with it because I believe it's far outweighed by the advantage of having my critical data stored (and so backed up) in the image files rather than having to reply on *any* database.

    Also consider:

    (1) Why would ACDSee bother to decompress and recompress when it's totally unnecessary?

    (2) In my experience, the speed at which images are rewritten also rules out the possibility.

    I can assure you that I would never have gone down the write-data-into-the-image-files route without being 100% certain beforehand. Some of my Jpegs have been rewritten numerous times and I can assure you the images are as good (or bad) as they were originally.

    But feel free to try it out for yourself if I can't convince you.

    Posted On August 22, 2008 - 07:44 AM (1 year ago) (Permalink to this post)
  • rbeal
    Member

    John_R said:

    I'm not talking about doing a visual comparison: I put the images on two layers set to "Difference" mode, and the result was pure black (i.e. no difference at all).

    The file size difference is most probably due to some metadata being stripped out (I lose some camera-specific data fields for example) and/or repacked. As far as I'm concerned that data loss is the only negative to rewriting image files, but I've learnt to live with it because I believe it's far outweighed by the advantage of having my critical data stored (and so backed up) in the image files rather than having to reply on *any* database.

    Also consider:

    (1) Why would ACDSee bother to decompress and recompress when it's totally unnecessary?

    (2) In my experience, the speed at which images are rewritten also rules out the possibility.

    I can assure you that I would never have gone down the write-data-into-the-image-files route without being 100% certain beforehand. Some of my Jpegs have been rewritten numerous times and I can assure you the images are as good (or bad) as they were originally.

    But feel free to try it out for yourself if I can't convince you.


    You are correct, I am convinced. Thank you for explaining what you did.
    Before your message, I did a test myself, doing 12 changes one after the other. No degradation.

    Posted On August 22, 2008 - 08:21 AM (1 year ago) (Permalink to this post)
  • Marc Sabatella
    Moderator

    rbeal said:

    It would be good to hear an ACD person confirm that they have understood what we have told them.

    Note this forum is a place for users to discuss things amongst ourselves. Although folks from ACD do sometimes read and respond, if you want to involve them directly, it is always best to submit a support ticket by clicking the Support Form link at top left of this page.

    Posted On August 22, 2008 - 02:58 PM (1 year ago) (Permalink to this post)

Subscribe to this topic via RSS

Reply

You must log in to post.