Tearing my hair out trying to solve this problem. After a reboot or after fully terminating DO, there is a 50 second delay when creating the first lister during which DO is non responsive.
I have been playing around with disabling various shell extensions, but the results are inconclusive. It may solve the problem for the next DO restart, but with a subsequent termination and restart, the delay is back. This is very puzzling.
Is there a way of creating a log file to determine the cause of the delay?
Try going to coll:// and see if any collections there have huge amount of files inside them. If you clear them the issue should be resolved (until the collections refill again). This is a known issue which will hopefully be rectified in some future Opus version.
It could also happen if network drives on servers that don't exist are being referenced somewhere, since there's a 30 second timeout on them (set by Windows, not Opus).
You can use Process Monitor to see which files/folders are being accessed while the delay happens, which usually points to what's going on:
You can also make some process snapshots while the delay is happening and send them to us if you want us to see if those indicate what's happening:
OK - nothing to do with collections. It was a network drive powered down, so a simple cause. I've had that drive for years, and it is often turned off, but I've never noticed a 50 second delay before with DO starting up. Might this be a small change within DO?
I can't think of any recent changes that would affect that.
Offline network drives have always been problematic. There are ways to deal with them but it depends on exactly why it was being accessed. (Folder tabs open? Toolbar buttons pointing to them, or icons on them? etc.)
Turning off the folder tree removes the delay completely. Then turn it on immediately and still no delay. That's a good workaround. I'll try getting you some proc-mon logs.
Thanks for trying that. It's interesting as I don't know, at least off the top of my head, what it would do differently when initially opening with a tree vs opening and then turning the tree on.
Logs would definitely be interesting to see here, in case there's something we can change to avoid the delay.
The delay is happening when Opus asks Windows if that drive has any icon overlays (to indicate different states like offline, synched, etc.).
I'm not sure why it's only slow if the tree opens at the same time as the lister. Maybe it's something we can move to a background thread, though, although that isn't a trivial change. (And even if that was done, there may be other things that cause delays, in Opus or in other software. Mapping drive letters to things that aren't always online can cause problems.)
At the moment, only that or not mapping the drive when it doesn't exist.
I tend to use UNC paths for drives that aren't always online. (In fact, I just use those in general. No really need for drive letters at all for network drives.)
I use the drive letters for backup utilities. What are UNC paths? Sounds like a plan...
Another clue for you. I've placed a button on the toolbar to open/close the folder tree. If I restart opus with no tree (so no delay) but use the toolbar button to open the tree, there is now a delay again - but not as long!
UNC paths are the things you map the drive letters to.
If Y:\ is mapped to \\169.254.228.144\qnap you can just access \\169.254.228.144\qnap directly without creating the drive letter at all. Similarly for \\synology\video and so on.
Earlier you said there was no delay if the tree was turned on after opening the window? I expect it comes down to the OS caching the fact the server is unavailable, which Windows seems to do per process instead of system-wide, for some inexplicable reason.
OK - I understand. I can reference the appropriate network locations using UNC paths in my backup software, I guess.
Excuse my ignorance now (I work on a need-to-know basis at 71 years of age!) but if I remove the drive letter mapping, is there quick way to access those locations via some sort of button shortcut within opus without typing the location into the pathbar?
Aliases will definitely not cause any delays (except when actually used). The others could still trigger a delay, I think, but are less likely to than the tree.
(This is from memory, which is why I'm not completely sure. It's actually quite hard to test things to check which of the options cause delays, since it doesn't happen for random server names, only ones that have existed in the past, and it generally only happens once or once in a while, with the failure then being cached and happening quickly most of the time.)
OK. I've removed all network drive letter mapping. Using UNC paths in my backup software works perfectly. No delays on startup with the QNAP powered off. Much less cluttered folder tree and more drive letters available. Using Favorites to access the QNAP and Synology is very convenient. Perfect. Isn't it satisfying when you learn a better way of doing things!
