I’m experiencing a critical issue with DEVONthink that’s affecting my ability to work. I’ve been trying to open the application for the past hour and a half, and all I’m getting is the spinning beach ball of death.
What I’ve Tried:
Initial Attempt: When I first tried to open DEVONthink, I was met with the spinning beach ball, making the app completely unresponsive. Tried to force quit and reopen several times at intervals of ~15-20 mins.
System Restart and Update: I shut down my computer, and it ran an update. After rebooting, I tried to open DEVONthink again, only to encounter the same issue.
FYI I’m running Ventura 13.5.1 on a 2018 Macbook Pro
Questions:
Could this be related to space issues on my computer?
Age of computer?
Is it possible that my DEVONthink databases have grown too large, causing the app to become unresponsive?
Any help or guidance would be greatly appreciated, as I need to resolve this issue urgently to continue using DEVONthink effectively.
Re 1: what is the size of your disk on the computer, and how much of it is “free” and available? To help resolve clear out Trash in both DEVONthink and the file system (in case there is a lot there).
Re 2: Unlikely. 2018 for a Mac is not unusual. Unless there is some sort of hardware flaw.
Re 3: Unlikely, unless there is insufficient disk space to support what you call “large”. DEVONthink databases are not monolithic and can grow much larger than you may think.
As it’s hard to debug this sort of issue here, I’m guessing @BLUEFROG will invite you to send in a Support request via the Help menu (press Option key to see).
Not that it’s a contest, but I can beat that. I’ve had DT be unresponsive overnight. The issue for me, per Support, was that some large video files were added to an indexed location. DT was stuck indexing and checksumming these files. (Apparently it doesn’t skip files when that operation makes no sense.) The situation was made more difficult because there’s no way to stop an operation in progress. In my case the only route to recovery was to disconnect from the drive where the files were stored so that DT no longer saw them as being present.
How would it decide that indexing and check-summing a large file makes “no sense”? I’d assume the sensible cause of action is to handle all files equally, so that users are not risking data corruption and can search their content.
@chrillek Well, not so much “large files” just file types that have no searchable content. Altho if performance in a known issue, which it appears to be for a non-cancellable operation, skipping or delaying files above a threshold size might make sense.
@rmschne FYI, I am deliberately indexing large video files from an external hard drive that is only sometimes connected. It’s for the purpose of linking to specific times in meeting recordings (and all the other awesome DT capabilities) but not having the ability to store those important videos locally.
30 GB of 500 free. I cleared out both system and DT trash per your post. I regularly clear out system trash, but realized that I rarely clear DT trash. Thanks for the reminder.
@GordonMeyer Thanks for the insight. What would happen if you force quit DT in that situation?
I am finding myself having to do that quite a bit, most often to eject a hard drive that wont do so “because DT is using it” as it says in the dialogue box. Often times, though, I made no changes to the files, just connected to watch some media or something, and then could not eject the drive, so I end up having to force closing DT to disconnect the HD.
There is quite a bit of media on each of the two main external drives that I connect… assuming that is probably relevant.
If you’re indexing them into an active database but not connecting the drive, why don’t you index into a separate video database that you only open when you connect the drive?
Also, if the beachballing recurs, please do this…
Open a support ticket.
Do a Spotlight search for Activity Monitor. Select our application in the list of processes - it should show “(Not Responding)” and the name in red - and press Command-Option-S to run a sample on it. When the sample window opens, press the Save button and save it to your Desktop. Please attach this text file to your Support Ticket so we can inspect it. Thanks!
Ahh, interesting. Ok, I’ve started the process and eliminated ~150 GB of indexed items from that drive. To have to content available in the relevant folders, I’ve grabbed a DT link to the large item(s) in the new video DB and placed the links in the relevant folders in the main DB. Let’s see!
I’m back to some severe issues with my main databases here any help appreciated. Here’s an overview so far.
System Specs (updated since original post):
MacBook Pro (2023, 14-inch), Apple M3 Pro chip, 18 GB RAM
Running Sequoia 15.1
225 GB free of 1 TB storage
Database Details:
~178,000 items (~584.3 GB)
~520,943 unique words, ~40 million total
6,019 groups, with 729 indexed
Steps Taken:
Disk Check and System Maintenance:
Verified and repaired main hard drive using Disk Utility and Onyx (based on advice from this post). OnyX revealed some disk corruption, which I repaired via macOS First Aid.
Ensured ample free space (225 GB) and confirmed no large video files are being indexed.
Rebuild Attempts:
Ran multiple rebuilds of the primary database. Each time, DEVONthink successfully exported all files, but crashed every time midway through re-import (around 720,000 files out of 828,000), which caused the app to quit unexpectedly. I tried this 4-5 times
Several of the rebuild attempts ended with the database appearing empty in DEVONthink, though Finder shows it’s full size (approx. 80 GB).
After running a repair on the “empty” database, DEVONthink imported all files into a single “Orphaned Files” folder (approx. 98,000 files).
Backup and Time Machine Restores:
Internal backups did not resolve the corruption issues, so I restored a Time Machine backup from Oct. 23 (most recent backup I had pre-corruption issues).
I attempted to restore this database 4-5 times, but DEVONthink crashed every time, with progress and organization lost after each crash.
I’ve tried all the usual verification and repair functions, turning off Spotlight indexing, and following the advice here and from other forum posts, but nothing seems to fully resolve the issue.
Questions:
Is there a way to preserve the database structure more reliably during a rebuild, or a method to remap files and folder hierarchy without causing DEVONthink to crash?
Would you recommend any additional steps to stabilize this large database, or is there an alternative way to rebuild it safely?
As some people here say they want to index video files, I was just checking and that would have been my next question!! Cheers.
any help appreciated. Here’s an overview so far.