Delayed first read of folders

Hi,
I noticed that when DO reads a new folder for the first time it takes considerably longer then the following times.

During the first read a splash is shown saying "Reading folder ..."

I already deactivated the content recognition for folders - but this still happens.

It´s not too bad - only takes maybe 2 seconds for the first time a folder is read (although the folder only has 2-4 files), but wondering if I could avoid that delay.

Thanks and best regards - Peter

Either the drive is very slow (network folder?) or it has spun-down and the delay is because it takes time to spin up again.

Subsequent reads will be faster because the directory listing has been cached by Windows and/or the drive is still spinning and hasn't gone to sleep yet.

Unless there is something very unusual going on (e.g. a folder with thousands of shortcuts, and you have Opus configured to sort folder-shortcuts as folders; or using Flat View at the top of a huge directory structure), the time taken to read the directory listing is entirely down to the hardware and the operating system, and how fast they can provide the list of files. The speed should be the same no matter which program you use (and if you load the listing in one program, then load it in another, the second one should be fast due to the caching).

Hi Leo,

the drives are local PC hard drives - and I´m sure they have not spun down (I keep my local drives running all time as I think frequent restarts of desktop drives are not a good idea).
Also other directories that opus had "looked into" before are read instantanious, without the popup that the screenshot shows being visible.

The directories ususally contain maybe only 2-4 files, some of them being rather large though, around 2-6 Gig. Also this can´t be due to caching, as the same directories are read fast even after a reboot, after they have been "looked into" at least once (reboot should clear the cache).

One thing that came to my mind and that I will test:
It might be caused by the antivirus checking the file for viruses during first visit and thus delaying the access for DO, while on future visits antivirus might have cached the information that the file had been checked before ... I will verify that by turning of antivirus and also doing the same with explorer instead of DO.

I thought that was caused by DO doing some file type analysis in oder to check folder contents - thus I did not think about antivirus - but in fact it might be totally out of DOs responsibility.

Thanks for the reply - I let you in know after some more tests.

Regards - Peter

Not sure what you mean there. Looking in them the first time after rebooting once then put them back in the cache.

I agree that anti-virus is worth looking into. Maybe it is blocking Opus for a long time while it is trying to inspect the directory or files.

If those large files are archives, see if turning off the folder tree helps, too. (Or keeping the folder tree but turning off display of archives within it.)

Are you calculating checksums? For large files that can be a bit slow.

Regards, AB

Checksum calculation should be done via a background thread so they shouldn't cause this, unless opening the files at all is causing an anti-virus scanner (or similar) to block the whole process while it does its thing.

Hi again Leo,

what I meant was that after a reboot even the first look at a folder that was looked into before the reboot does not show any delay.

Anyway here is some more information after some more tests:

  • I tried disabling the realtime virus scanner (Avira antivir premium) but that did not make any difference. First read of any newly created folder with large files shows a about 2 second delay
  • Folders does only contain some large files that are not archives, but usually .m2ts files from my cam.
  • I found that also windows explorer shows the same effect of the delay. So obviously that must be something on a lower level. I currently suspect that Antivir still checks into the files, just ignores the results when disabled. Don´t want to un-install Antivir for this test, obviously disabling is not sufficient
  • I´ll try the same in my test windows that does not Antivir installed or will try to unload Antivir from memory by killing it´s processes

Anyway - I don´t think DO has to do anything with the root cause.

Regards - MacSass