I am not very happy with the stability of DevonThink Pro Office.
As I have written elsewhere, it begins to crawl on my 6GB machine once my library exceeds Bill DeVille’s “sweet spot” in size.
Now I am facing a more alarming problem: Occasionally (approximately once per day), the app crashes as I move an item in “Column” view (cmd-3). I suspect that this occurs when I attempt to move an icon to the first or last position of the column.
As a result of this bug, I lost 5hrs worth of work yesterday—an extensive and very detailed PDF annotation to a highly technical academic paper.
Today I lost a smaller amount of work, but the problem is distressing nonetheless.
Such a bug would have been understandable in a .0 release, but in .3.3, it seems surprising.
Sorry to hear about you losing your work, I would always save the file I was working on in devonthink as this will safe any changed annotations. Then you can avoid worry if the app crashes. Also I would probably use a more advanced annotation software for the PDF such as skim which would also allow saving changes. Sorry for the loss of 5hrs work but there are ways to use the software to avoid these problems happening even if the software crashes.
I also drag a copy of any important files to other backup folders on my mac for example the dropbox folder or import to evernote.
But I must say that the crash occurred as I was just dragging an icon in column view. It may have been provoked by some PDF routine, but there is nothing (apart from coincidence) to suggest that… I strongly suspect that it has to do with low free RAM conditions. I have this sizeable library (approx. 4.5 GB) which, for some reason, makes my 6GB machine craw. It eats up more and more RAM literally by the minute, especially when I save files. In this case also, however, this is only conjecture.
At any rate, DT is overdue for an auto-save feature. Support for Lion versions would also be highly welcome.
Yet I would happily trade a bunch of new features for some more thorough testing and optimization.
Diagnosing a problem like this is difficult – as you know. Over here, I also have a 6GB machine on 10.7.3. DTPO is open with four databases, totaling 12.5GB among them, the largest of which has 5.2GB. My machine runs for weeks at a time with that same DTPO footprint running continually. I only mention this because I see hundreds of hours of continual stability with a very similar circumstance as what @macula described. So, maybe there’s something else? Have you submitted crash reports to Support?
Like korm’s situation is mine: My Mac is up almost all the time and with the exception of 2 backup routines per day for which I close my DtPO databases, DtPO is always active and gets constant use. 4 databases open least, these 4 makes 8gb, the largest of them is close to 5gb yet. No signs of slowing down and DtPO opens these four in 10 seconds including start up of the program. And this happens on a 4gb iMac 24 from Mid 2007.
I see the spinning wheel often, when I drag files to folders, which happens when I move the mouse over other folders in the list of folders in the three-pane-view. I found this happens less, when I use the overlay window (Menubar>Tools>Show groups and tags), which I often call when I have to sort many individual files. Otherwise instead of dragging many items at once, I prefer to use the “move to”-command via the contextual window (ctrl-click) or from the menubar.
I did retrieve the crash reports. They are quite long, obviously, but a couple of lines strike me as most relevant:
Assertion failed: (table!=nil && position!=NSNotFound && [table rowAtPos]==self), function -[KRecord removeFromTable:position:], file /Users/criss/Documents/Projekte/Devon/../DevonThink/KRecord.m, line 3087.
Looks like something that could be easily reproduced and debugged. Then of course, you never know.
This aside, the slowdown that I have described persists after emptying the cache. It is most severe the first time I create or modify a note after waking up my machine. I just tried to create a blank rtf and it took 4 minutes (!!!) for the beach ball to stop spinning. During that time, the Activity Monitor revealed a hyperactive kernel_task owned by ROOT and consuming more than 15% of the CPU.