I believe the problem you have been seeing is a combination of two things:
- A fairly large number of events being generated on the machine (although it is not excessively large, so this is not enough on its own).
- A fairly loaded, multi-user machine where Opus may not always get much uninterrupted CPU time and is frequently preempted by other CPU work. (It could also be caused by very high contention for disk or other resources, virtual memory swapping, etc. I can't tell the exact bottleneck from the logs, only that there appears to be one.)
That combination appears to be causing your Opus windows to be unable to process the changes as fast as they are happening.
We have added two new settings which allow you to tweak how long Opus will process change events for at a time, and my hope is that changing these will solve the problem in your environment.
I have sent a private message with a link to a new test version, which has two new settings:
-
notify_max_time
The maximum amount of time, in milliseconds, each file display will spend processing change notifications from the filesystem before considering other inputs and events.
Defaults to 50 milliseconds. In rare situations, you may need to raise this from its default value if events are being generated faster than they are consumed. You can also specify 0 (zero) to process change events indefinitely, although you would probably only want to do so as a test, not as a permanent setting. If this is set to zero, or set too high, file displays could become less responsive to user input when a lot of filesystem events are being generated.
This is a global setting. If you change it for one user on a machine then it will affect all other users, as is most likely required. On a multi-user system, if the setting is changed by one user, the others will not see the change until they restart Opus.
-
notify_min_items
The minimum number of events to process before checking the notify_max_time time limit. See the description of notify_max_time, above, for situations where you may wish to raise this, and how the setting behaves for multiple users.
This test version won't output extra debug information like the previous one, as I don't think we will need it now. (Or, if we do, it will likely be different information that we need to look at.)
Initially, the test version will behave the same as older versions, as the new settings need to be changed to make a difference.
When you are able to, please install the new test version and change Preferences / Miscellaneous / Advanced: notify_max_time to 200 as an initial test.
If you still find there are times when changes don't appear (or take a very long time to appear; more than ~4 seconds), try setting it even higher, or set it to 0 (zero).
The higher you go the more possible it is for the file display to become slow to respond to user input while dealing with a flood of events, but the faster it will process the events in turn.
You probably won't need to change notify_min_items, the second setting, unless you find that you need to use really large values (or zero) for the first setting to make a difference. In that eventuality, please post here and we can make recommendations.
Many thanks for your time and help testing this, as always!
on DebugView's toolbar, it will show you if it is filtering things:
