Announcement

Collapse
No announcement yet.

Survey for catalog size

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Survey for catalog size

    With AC Pro/Ulti 2020 I now again have a version that needs over 30 seconds to switch from manage mode to view mode with a db of just 280,000 catalogued photos. For me this a party pooper I will surely not invite, AC Pro 8 needs less than 3 seconds.

    I begin to wonder how many photos AC users usually have in their db's, 'cause hardly anyone gives a damn about it.
    So, how many items do you have catalogued in your AC database?
    7
    less than 5,000 photos
    0%
    0
    5,000 to 25,000 photos
    14.29%
    1
    25,000 to 125,000 photos
    28.57%
    2
    125,000 to 625,000 photos
    57.14%
    4
    more than 625,000 photos
    0%
    0

  • #2
    Although, I am bitten by a couple other recurring bugs (like maximum horizontal resolution when trying to edit a panorama), fortunately, I am not currently bitten by the mode switching bug. I am always under 3 seconds, many times under 1 second when switching between any mode. This is true for switching modes with files over a wireless network or on local storage.

    For reference, some stats: 24GB database; ~167,000 files.
    I would be happy to try different configurations to try to help troubleshoot. (Sometimes it is easier to find the root cause by braking a working system.).
    I guess I could try to duplicate my entire files set (167k files x 2 = 334k files) to see if that kills the system.

    I was bitten by the bug once. I remember the pain.
    I think you helped me exorcise the demon. At that time, my database was close to 60GB (if I remember correctly). The fix was to change the "default" export setting to "resize > long edge > 200pixels; format: JPG, quality 50%). Then... ughhh..... rebuild the database. If I remember the previous explanation, it was the "default" setting helped define the quality of the thumbnail in the database. I am not sure I believed it at first. But the result of the change d it was a correct fix.

    Thus, When I install a new update, BEFORE I import the old database, I set the default export to something like stated above.... then do the import of the old database.

    This seemed to keep my transition from 2019 to 2020 going without a hitch.

    Comment


    • #3
      Holy Moly! 1 sec for over 150,000 files. This encourages to drill down deep into the problem as it's probably not the sheer amount of catalogued items but the number of keywords defined or assigned, or the number of categories, or collections, or whatever . . . This will give splendid amusement for long stormy autumn nights, so I'll dig in and hope to be back before thanksgiving :-)

      Comment


      • #4
        Hi Emil,
        Have you tried resetting your layout? In Manage mode, View | Reset Layout, there were a couple of people on the forum saying that improved their mode switching performance.

        Comment


        • #5
          Hi Ben,
          Thanks for the suggestion but this doesn't help. I did even more than that and removed "HKCU\ACD Systems" to have everything reset with one exception: I disabled FR which was eating up my CPU.

          As one of the first steps I compared accesses to files and registry with "Process Monitor" and found that AC Pro 8 needs 4 "ReadFile" operations for Keywords.dbf and Keywords.cdx, while AC Ulti 2020 needs over 70,000 operations when switching from manage mode to view mode. A closer look also tells that AC reads the same portion several times.

          Both installations are as identical as possible: (almost) identical DBs and default user settings. Both dBs contain 9,000 different AC-keywords, but none is assigned to the selected image.

          For a short test I replaced Keyword.cdx and Keyword.dbf with copies from a fresh and empty db. With this the change a mode switch takes less then 3 seconds. But this of course isn't a solution; I need the keywords. So I'll keep on drilling :-)

          Comment


          • #6
            I may be able to help confirm somethings to help you get out and take pictures of the fall colors instead of troubleshooting AC databases.

            I have no where near 9000 keywords. Actually, I have zero AC-Keywords. I may have 400 IPTC Keywords at most. Maybe you are on to something with that keyword test. I would expect 9000 items should be a quick read/sort for a modern database. Preferably one that could operate off of a standalone database. Maybe v2021 will have an updated back-end.

            (I also have FR turned off.)

            Comment


            • #7
              You're right Gus shooting indian summer photos is much more fun then debugging a poorly maintained app. But I also have to run AC several hours a day, as it helps me to make a living!

              I actually don't really need the AC-keywords. As you, I'm fine with the IPTC-keywords. The 9,000 existing AC-keywords are just many years old remains. But what am I going to do if ACDSystems decides to foul the handling of IPTC meta data too? So, I keep on digging and post what I find. Perhaps someone becomes smart of it . . .

              I wonder why AC does actually need to read all AC-keywords from the db just to show a single image w/o any assigned keyword in view mode.
              Last edited by Emil; 10-10-2019, 02:09 AM.

              Comment


              • #8
                This is a tough one Emil. You've helped so many people on this forum, myself included, I certainly wish I could return the favors.

                70,000 db operations when switching between modes certainly seems excessive. I am guessing you've already grabbed the low hanging fruit like OS, application, cache, database on NVMe on the PCIe bus for storage.... database optimization and the like. Obviously, these only treat the symptom and not the root cause.

                I've read that it seems like latest versions of windows can fight a bit with VMware. If you are running in a VM instance, it may be worth trying a native Win installation.

                ​As there is something strange going on with the database transactions and us mortals don't have access to schema, raw database, or other developer style hooks, this is a tricky problem.

                So I get out my shotgun and look for things that could possibly cause db transactions so I can turn things off (hopefully without killing good functionality).... Not knowing anything other than trying to remove transactions, maybe one (or more) of these could help.

                Warning: I have very LOW confidence any of these will work as I am only working of guess of things that _may_ cause a transaction when switching modes.

                Options > Database > [uncheck_set_database_date_to_EXIF_date]
                Options > Database > Metadata > [uncheck_ImportExifAndIptcMeatadataFromCatalog]; in case ACD is trying to update 70000 dates for some unknown reason
                Options > Database > Metadata > [uncheck_ImportExifAndIptcMeatadataFromCatalog]; so ACD doesn't need to link IPTX/EXIF to the datalog
                Options > Database > IPTC COnflicts > [uncheck_both_of these_so_ACD_has no_reason_to double_check_anything]
                Options > View Mode > uncheck_ACDQuickView; in case it is the quickview that triggers a bunch of transactions ( I have had problems with QuickView, so I tend to disable it anyway)
                Options > ACDSee Pica view > disable; in case it is this feature that wants to reload keywords for some strange reason

                Comment


                • #9
                  Originally posted by GusPanella View Post
                  This is a tough one Emil.
                  Yepp!

                  I am guessing you've already grabbed the low hanging fruit like OS, application, cache, database on NVMe on the PCIe bus for storage....
                  Yes, both apps are installed on the same physical machine. All user config is set to defaults except FR and both use the same db. AC 2020 is using a converted copy of course.

                  [QUOTE]As there is something strange going on with the database transactions and us mortals don't have access to schema, raw database, or other developer style hooks, this is a tricky problem.[QUOTE]Yes, but we can bang it! So I decided to create a script to stuff the db with lots of data a see how things go. The script can be found on github. It's brand new and not yet finished, but it works; at least for me :-) I plan to do some stress tests with it and report.

                  Comment


                  • #10
                    I downloaded your Python script; generated a text file from an edited config.ini; created a new database; imported the text file.
                    The text file was a tiny 1.8MB so you wouldn't expect any issues.

                    Although I don't believe hardware is the case, it may be reasonable to rule out hardware configuration differences between the two systems. Is there a config.ini that will created a txt file large enough to duplicate the problem on your system? If yes, I could run the same config.ini. When the problem is duplicated, I think we can rule out any hardware difference between our two systems.


                    Comment

                    Working...
                    X