When I selected “Switch Library” and selected a (2+TB) library on an external USB3.2 NVME drive. Aspect has been “Loading Library…” for 2+ hours
Library would load in 1 min or less
…
MacOS Sequoia 15(24A335)
15" MacBook Pro (Apple M1 Max, 64 GB)
No logs generated
can provide library file
The most likely cause for this would be if for some reason the metadata cache of the library has been cleared/deleted/corrupted. In that case, the metadata would be reloaded from the original files as part of the library loading process. It should be possible to verify this by looking at the log file at $TMPDIR/aspect-log.sdl (in the Terminal app, enter open $TMPDIR and locate the aspect-log.sdl file in the Finder window that opens).
If this happens repeatedly, without any crashes involved, this would point to a corrupted metadata cache. In that case it would be especially important to determine the underlying error by looking at the log file. A workaround in that case is to completely delete the .cache/metadata folder contained within the library folder (it may be necessary press Cmd+Shift+. to see the hidden .cache folder).
There is a fix for a similar issue in 1.0.0-rc.8, but in that case, the application would hang in the loading state indefinitely.
Thank you for your response. I just realized that I failed to specify the version of Aspect I was running. This issue presented on the latest version 1.0.0-rc8.
I have some more experiences to report, ,but I’m not sure if they are related, so if not, please let me know and I’ll be happy to open a separate incident.
Because of the above, combined with my failure to see your very timely response until just now, I chose to archive the previous library and try to recreate from scratch. The rebuild process has been running since shortly after I reported this issue on 2/28 and is still consuming 44GB of memory, 160% CPU (42 hrs of cpu time), and only .5% GPU (27 hrs of GPU time).
I am happy to share the sdl but at 1.5GB, even zip’d, it’s 75MB.
Additional details:
find /Volumes/Photos -type f | wc -l reports 321,302 files (almost all raw, jpg and video files)Let me know if there is other information I can offer to help troubleshoot. If you have a way for me to send the SDL, please let me know.
One more update. Analyzing Images completed for the initial large library and CPU utilization dropped to .8%, as expected. GPU spiked a bit to 8-10% at times during usage but, again, seems well within operating norms.
Then I decided to connect my iPhone XIII Pro Max running iOS 18.3.1 and CPU immediately spiked to 200-300% with spikes over 600%! Of course “Analyzing Images…” kicked back in again, so I’m guessing that’s a significant contributor.
The time consumption for the initial scanning/analyzing process definitely is way off for an M1 with an NVME SSD based storage. One interesting piece of information would be the RAW file format(s) that are present among the photos, since an issue in the RAW file handling would be one possible cause here.
As for the log file, can you maybe send me just the start of the process (e.g. cat $TMPDIR/aspect-log.sdl | head -n 10000 > aspect-log-shortened.sdl)? Maybe it’s possible to pinpoint where exactly this is taking so long.
In the meantime, I’ll try to reproduce the setup on an M1 Mac Mini (latest macOS) to make sure this is not some general issue with that setup.
I ran a small test:
Initial scanning took 3 min, the image analysis (which includes computing a full hash of all files) took around 15-20 min. Scaling that up, means that you should be looking at around 20 min for scanning and up to maybe 3,5h for the image analysis. In terms of memory usage, it went up slowly to about 1,2 GB, but then stayed stable.
So there definitely must be something else going on here.
I really appreciate your quick and thorough feedback! Per request, I’ve uploaded a zip of the first 1000 entries in my log file. If you need more entries or followup after review, please let me know.
Continuing on the performance feedback story, yesterday I attempted to delete a duplicate set of photos, kicking off around 3:00 PM. That process is still running, though I notice there is a dialog box reporting it cannot delete a file. Unfortunately I cannot dismiss that dialog box to see if that allows the process to continue. I am not sure if there is another modal dialog preventing me from selecting or if it simply because the process is hung (my cursor is the pinwheel).
Aspect is flagged as “Not Responding” in Activity Monitor. Am I safe to force kill the process or is there another way I can restore functionality without killing?
CPU Usage 100%-150%
GPU Usage <1%
Memory 54GB
aspect-log-shortened.sdl.zip (83.3 KB)
Aspect is flagged as “Not Responding” in Activity Monitor. Am I safe to force kill the process or is there another way I can restore functionality without killing?
It should be safe to force-quit in this state - as long as only the image analysis is running, the worst that can happen is that some images need to be analyzed again*. I’ll replicate the issue locally to take a look at what happens with the UI there.
Incidentally, something related to this error message might actually also explain the performance issue during scanning/analyzing. Due to the compiler implementation for generating stack traces, logging exceptions on macOS is unfortunately extremely slow (>100ms, which quickly adds up if it occurs for each image in a large set). Can you maybe try to see what grep -c "Full exception" $TMPDIR/aspect-log.sdl prints?
As for the original problem, from the log it turned out that indeed both caches, global and library, have been damaged, probably because the application got terminated earlier while it was actively caching metadata. I’ve implemented an automatic workaround for the next release (the application attempting to recreate the cache automatically when it cannot be loaded), but for now you should be back to normal after deleting the cache directories manually (<path to library>/.cache and ~/Library/Caches/Aspect/globalcache) and letting it run through once more.
Apart from that , the images that are in the partial log file seemed to be loaded with decent speed - extrapolating from the ~2,000 files, the total ~200,000 files should take around 46 minutes. However, in this part of the loading process there were only JPEGs and a few PNGs involved, so there might still be an issue with RAWs or possibly video files, in case it doesn’t turn to be exception logging related.
* However, killing it while the file system is being organized, or during a synchronization with another device may lead to some bad side-effects, such as seemingly reverting to an older version of the library catalog.
I’ll replicate the issue locally to take a look at what happens with the UI there.
I couldn’t get the UI to hang like that (changed the permission of a folder to read-only to trigger the errors). However, it’s clear that this must be changed to only show a single error message box with a list of errors instead of one dialog per file.
Interestingly, this only shows up 2 times, so seems unlikely to be the cause.
I currently have a 577M log file and a 218M crash report. I’m happy to pass them along so you can have the full picture. All log entries would be working against the same set of photos.
Alternatively, if there are certain analyses I can run on my end, like average or highest file process times, I’m happy to do so on my end and send over the results.
Aspect crashed last night (hence the crash log) while reloading the library. I launched again this am and left it alone. I’m not sure how long it took to load as I’m just returning to that computer but it is less than 7 hours.
Aspect is still very sluggish, possibly because it is “Analyzing Images…” and using 29 GB of memory and 100-200% CPU.
Since the library is loading, just taking a long time, would it help or hurt for me to delete cache directories at this point?
Edit: Aspect is presumably idle at this point as it doesn’t show any messages. CPU is hovering around 1-2% until I scroll one page up at which point it immediately spikes to 90% then a latent spike to 150%. Of note, memory appears to be increasing as it is now sitting at 32GB.
I currently have a 577M log file and a 218M crash report. I’m happy to pass them along so you can have the full picture. All log entries would be working against the same set of photos.
Alternatively, if there are certain analyses I can run on my end, like average or highest file process times, I’m happy to do so on my end and send over the results.
Do you maybe have access to a Google Drive or similar where you can share it? I’d mainly aim to get a distribution of the load times to hopefully single out a certain type of file. This will require writing a small program that parses the log file to match the load start/end markers with their corresponding time keys.
Since the library is loading, just taking a long time, would it help or hurt for me to delete cache directories at this point?
I’d recommend doing it, because in the current state it’s never caching anything on disk and just has to reload everything every time.
Aspect is presumably idle at this point as it doesn’t show any messages. CPU is hovering around 1-2% until I scroll one page up at which point it immediately spikes to 90% then a latent spike to 150%. Of note, memory appears to be increasing as it is now sitting at 32GB.
I’ve observed that on macOS memory use seems to creep up over time, but haven’t been able to pinpoint what that memory is getting used for. This is probably rooted Objective-C memory management, which also happens in third party code. I’ve noted this in a ticket (#1509) to schedule another debugging session later.
I have a few updates on this chain. Most important of which is that, based on the last 36 hours on rc9 it looks like, things seem to have really stabilized!
The other update is that I discovered what was causing the error on the deletes as seen in the screenshot in message 7 above. Turns out some of the paths had the uchg flag set, thus preventing my Mac from deleting. Once I ran chflags -R nouchg /Volumes/Photos/ to recursively clear the flag, all is right again!
Last thing, and this is probably a feature request, is that in troubleshooting the above on RC9 I had to dismiss the message for each individual file with no way to break the loop short of force quit. It would be nice to:
Skip All Occurrences)Cancel)Let me know if you’d like me to create a FR for any of the above. Including here the scenario came up while debugging this issue.
Thanks to you and the team for the great work and quick turnaround!!
For the next release, this is now mitigated using an error summary dialog — it will then go through all files, collecting any errors along the way, and will then only display a single message box listing all errors at once.