ACDSee Pro 2 and 2.5

Back to Topic OverviewPost New Reply

Resilience needed

(7 posts)

  • RobotDude
    Member

    Having just processed 2000+ images, I thought I would share my experience and hopefully improve future releases of ACDSee Pro.

     

    Very frustrating to do a Batch Process on a group of files and to find that ACDSee crashes frequently and seemingly randomly.  I needed to Batch Process 2000+ files from my Honeymoon.  I had hoped I could run the Batch Process overnight but found that ACDSee crashed shortly after I started the process.  I had to spoon feed ACDSee 50 images at a time.  This took days to complete - hardly a 'Batch Process'!

    The frequent crashing of ACDSee is a serious issue that needs ACDSee to urgently address.

    ACDSee Pro 2.5 needs to be resilient otherwise why use 'Pro' in the title?  No 'Pro', whose livelihood depends on this software, would seriously use this software.

    Posted On October 10, 2008 - 08:56 AM (1 year ago) (Permalink to this post)

  • Marc Sabatella
    Moderator

    I agree, stability needs to be addressed.

    FWIW, I find that things do improve noticeably after a reboot.  I suspect there are resource usage issues.  Also, while I would be hesitant to do anything to 2000 files at a time, I regularly do batches of several hundred with no problems.

     

    Posted On October 10, 2008 - 05:04 PM (1 year ago) (Permalink to this post)

  • fonebone
    Member

    did you have a shadow/highlight operation included in you batch ? That's where I suspect some of the crashed during batch processing originate from?

    Posted On October 10, 2008 - 06:58 PM (1 year ago) (Permalink to this post)

  • RobotDude
    Member

    Yes I am using Shadow/Highlights in my Batch Process.  Don't really have any other choice really!

    I agree with Marc that rebooting does help but it is not that clear cut as the problem will return.  I agree that by Batch Processing 2000+ files it is more likely that an error may occur.  However, I am of the opinion (from my programming days) that if the process works for one file it should, if the coding is robust, it should work for any number of files. 

    The main problem ACDSee has is that it has only one way of handling errors and that is to exit.  This made worse by the reason why not being logged so that the user and the ACDSee developers are none the wiser.  The result is that the error remains, cannot be repeated by the developers and continues into later versions.

    Posted On October 10, 2008 - 09:21 PM (1 year ago) (Permalink to this post)

  • fonebone
    Member

    RobotDude said:

    The main problem ACDSee has is that it has only one way of handling errors and that is to exit.  This made worse by the reason why not being logged so that the user and the ACDSee developers are none the wiser.  The result is that the error remains, cannot be repeated by the developers and continues into later versions.

    I agree, if we had a proper mechanism to capture the error including a dump (like there is in other products) for sending to ACDSee, i think they much more quickly could improve their product quality.

    Posted On October 11, 2008 - 04:58 AM (1 year ago) (Permalink to this post)

  • NA
    Inactive

    RobotDude said:

    ....  However, I am of the opinion (from my programming days) that if the process works for one file it should, if the coding is robust, it should work for any number of files...

    Sure, if, as you say, the coding is robust.

    When a process on a computer finishes (like shadow/highlight processeing of an image) it should release the system resources it has employed, like for instance system memory. If it doesn't those resources may not be available for other processes until the computer has been rebooted. This is referred to as a "memory leak"

    However, the appliation software (Pro 2.5 perhaps) may contain code which oversees the processes it has started, and if they don't release resources by themselves it will do it for them. This is referred to as "garbage collection".

    Probably such a garbage collection mechanism ought to be built into the operating system, i.e. Windows itself; to the best of my knowledge it is not.

    So there are three possible lines of defense against memory leaks. If none of these are implemented, the processing of each image in batch mode will erode the available memory until none is available and the computer crashes.

    Pro 2.5 will request Windows for resources; it may be Windows not answering Pro's request, so who's it really that stops responding? If the system is out of resources Pro really can't produce a log message or such like, but Windows, which is managing resources ought to do so having reserved resources for such an eventuality.

    Did anyone ever monitor their computer's resource usage during extended batch processing?

    Posted On October 29, 2008 - 09:04 AM (1 year ago) (Permalink to this post)

  • fonebone
    Member

    I have observed some strange windows thread behavior, see this for details: Occasional Crashes in raw processing

    Posted On October 29, 2008 - 08:56 PM (1 year ago) (Permalink to this post)

Subscribe to this topic via RSS

Reply

You must log in to post.