Opus folder content refresh speed

Help & Support
#37

I tweaked the scriptlet(?). This is what I'm using:

copy move WHENEXISTS=rename to "{filepath|\}XXXrecycle"

I replaced the original Delete command in Dopus with the above. So when I select "delete", it moves to root\XXXrecycle. But, you have to create the XXXrecycle folder first.
On my system at least, moving files to the same drive is instant, while deleting permanently or to recycle bin takes 1-5 seconds, and in thumbnail mode it can take a really long time if a large number of files is selected.
Also I'm using 10.5.2 x64 if that makes a difference. The only problem I've encountered is that a few times there was an error message, even though the files were moved correctly. I don't know why that is tho.

Additionally, I made a Autohotkey script that moves all contents from all the XXXrecycle folders into the real recycle bin once per hour, so I can survey if I've deleted something I needed before I empty the recycle bin.

#38

Surely doing that is going to cause more problems than it is worth to not have to wait half a second for the file display to update after deleting several files?

#39

Statistically, definitely! haha.

But I'm a real stickler when it comes to UX, everything has to be snappy or I'm annoyed :stuck_out_tongue:
So far it works good, apart from that weird error message. I was wondering if you had an idea why it pops up? It only appears, maybe 10% of the files I've test deleted. could it be the way Dopus or the file operation parses the path names?
Totally understand if you don't wanna bother assisting me in my experiments btw :wink:

#40

(it would be nice to have an edit function in the forum)

The error message appears seemingly randomly when i "delete" more than one file at a time.

#41

What is the error message?

The FAQ explains why editing is disabled in this part of the forum.

#42

"An error occurred moving XXX: an unknown error occurred."

Still, the file is moved. :S

#43

I'm not sure but it may be due to using {filepath} as part of the destination so the command is potentially run once per file instead of once in total for all files.

Putting "dopusrt /cmd " (without the quotes) at the start of the line may fix it. If not, I'd advise not using that solution. (I'd advise that anyway, of course. :slight_smile:)

#44

Thanks i'm gonna try that. What abot using @set dir= or {allfilepath}?

#45

I was fooling with DOpus advanced settings and found something new.
The problem with refresh speed does not occur when "no external change notify" is set to true (which is not default). Anyone can confirm that?
Maybe that information will help in investigating.

#46

If that helps then it could be that something is flooding or delaying the change notification system (in Windows) and having a knock-on effect on when Opus processes the changes.

You can check using DebugView and turning on the notify_debug and shellchange_debug settings mentioned here. (Turn no_external_change_notify off again as well.)

If you see a fast, constant stream of changes going by when nothing much is going on, then that may be part of the problem. Or, if you don't see notifications for the operation you just did until a while after it has completed, that may also explain things.

#47

Nothing is flooding and according to DebugView all changes (file deletion) happened in about 20 ms (although DOpus refreshed after 0,5 s). Maybe someone else will find something interesting.

#48

[quote="daroc"]I was fooling with DOpus advanced settings and found something new.
The problem with refresh speed does not occur when "no external change notify" is set to true (which is not default). Anyone can confirm that?
Maybe that information will help in investigating.[/quote]

Do you mean that the "redraw lag" doesn't happen if "no external change notify" is set to true? Have you tried deleting a bunch of images in thumbnail mode with the same results? Maybe 20-50 files.

#49

I created 200 identical (copied) png files, 6,70 KB each. Then tried to delete them in list view, details view and in thumbnails view (and in all tested modes it was the same, the only difference may be the number of files that are visible for 1 second after they are deleted). For testing purposes I disabled progress indicators delay so they appear instantly.

When "no external change notify" was set to false (which is default) and I clicked my Delete QUIET button:

  1. progress indicator appeared
  2. after about 0,2 second 190 files disappeared; progress window disappeared
  3. after 1 second the other 10 files disappeared

When "no external changes notify" was set to true and I clicked Delete QUIET button:

  1. progress indicator appeared
  2. after about 0,2 second all 200 files disappeared; progress window disappeared
#50

I tried deleting 156 pics in thumbnail mode. I got the same results you got.

I would say the file change listener in Dopus probably slows it down a bit?

Thanks for the discovery btw, now I can get rid of my semi-annoying workaround :smiley:

#51

So far only one person has tried what I asked...

(Looking at what I said again, it may also be worth turning on Preferences / Miscellaneous / Advanced: shellchange_debug in addition to notify_debug. I've updated the post so it's all in one place. And make sure no_external_change_notify is off or the test will be pointless.)

#52

I'll get to troubleshooting, gimme a day or so :stuck_out_tongue:

#53

[quote="leo"]So far only one person has tried what I asked...

(Looking at what I said again, it may also be worth turning on Preferences / Miscellaneous / Advanced: shellchange_debug in addition to notify_debug. I've updated the post so it's all in one place. And make sure no_external_change_notify is off or the test will be pointless.)[/quote]

When turning on the debug options, where does the actual debug show up?

#54

In DebugView. See near the bottom of the page I linked to: Changes to folders are not being detected

#55

Unless I'm doing stuff in Opus, DebugView is completely blank. Doesn't appear to be any flooding or weird stuff going on in the background!

#56

If it's completely blank then something is misconfigured.