I have directory with lot of files - about 5000 or more. Many types of files including video files, music files etc. Is any method to prevent Opus to read and scan this directory for file details? It makes my HDD crazy (directory was listed and works but Opus still collect some unnecessary data) and slowing down my CPU a lot. I have no special extra fields in lister so I don't know why Opus is trying to scan every file in this big directory even after displaying all files.
Explorer itself shows the same directory and needs maybe 5-10 seconds more to finish analyze everything. Opus needs lot of time and HDD going crazy. Filemon shows that Opus read all files - one by one. Even if I set only "filename" as the only field in lister.
Hmm, I'm struggling to think what might cause Opus to open the files if it's only displaying their names.
Could you post a screenshot of the window? Maybe there will be something in that which stands out as a possible trigger.
In Process Monitor -- I assume you meant that when you said Filemon; if not, it's the newer version of Filemon/Regmon by the same people -- can you right-click one of the lines showing Opus opening a movie file and then select Stack and post a screenshot the list that appears? That might indicate which component is causing the access so we can see if it's a plugin (movie.dll perhaps) or coming directly from dopus.exe.
Yes, I know that is new version of Filemon but as long as I can, I'll use Filemon, because new version is for maniacs. I need only basic informations so Filemon is good enough (and it's name of cat from old fairy-tale, so I remember that name better than new one) .
Basically - Filemon shows 90 lines of dopus.exe related to every file!
And quick additional information: listers has columns: filename, size and date (because this is attachments directory that I want to sort by date). So - similar than standard Explorer window.
Without the call stack that Procmon can show, there's nothing to be told from that log other than that some code running in the Opus process is reading from the file. The code could be anywhere - shell extension, virus checker, even a virus - there's no way to tell. Opus itself, however, doesn't do this.
[ul][li]The text plugin reading its config file as part of those logs seems strange to me. Try disabling that (in fact, try disabling all plugins under Settings - Preferences - Plugins) to see if it's related.
[/li]
[li]The files may also be opened to read their icons, if there is an icon handler shell extension installed for the .doc type. Turning on "show generic icons for all drives" in Preferences would stop that happening, if that's the cause. (Not sure where the option is off the top of my head, but if you type "generic icons" into the filter at the bottom of the prefs window it will highlight the option it for you.)
[/li]
[li]A screenshot of the window may still help spot something I haven't thought of that is turned on and might cause the files to be read.
[/li]
[li]Those procmon logs could be quite useful... You can always delete procmon after using it; it still doesn't require installation, you just run the exe, use it, then delete the exe.[/li][/ul]
Text plugin - i turned off that plugin and try without it before I give link to log. I also turn off other plugins but I no see any difference.
I never use any advanced icon handler (like thumbnail view for corel files etc). I use simply, normal icons.
Screenshot of standard window not help - is standard, single window, sort by date by default, with "name", "size" and "modified" column; no folder tree, no content detection, no tabs. Files are many types (that's my attachment directory) - doc, cdr, jpg, pdf, png, xls, mp3, tif, eps, zip and even some exe files.
Procmon and Filemon in Win XP works similar, so there is not a big difference except you'll get lot of unnecessary informations (like image below* for example).
I don't know that generic icons helps or not, but I don't want them (images are useful in exe case) and if Explorer can show directory without HDD "grinding" then I exepct that Opus can show me directory and just stop make hdd noise when directory listing and all icons are displayd.
Yes, the things we've already asked for that you seem reluctant to provide for some reason. Help us to help you.
[ul][li]The screenshot. (You might think it will be useless, and maybe it will be, but it might be useful and it doesn't take long to create a screenshot.)
[/li]
[li]The procmon stack window. (This will show the call-stack leading up to the file access so we can see which DLLs are involved. It will give us a huge clue about which code is triggering the file access. It is NOT something that filemon can show and it is NOT the same as the filemon disk-activity trace. It is additional information about a single item within that trace and is a feature added to procmon which was never in filemon.)
[/li]
[li]Try using generic icons, as requested. (It doesn't matter whether or not you want to keep using generic icons. You can change the setting back after doing a quick test. All we want to do is verify whether or not icon handlers are involved. If they are not involved then we don't have to think about them anymore; if they are involved then we can concentrate on them and investigate why there is a problem.)[/li][/ul]
None of these things will take more than 30 seconds to try.
Generic icons - no difference. Still HDD going crazy.
What exactly i should made in procmon to give you that important details?
By the way - is any difference between procmon that shows details about Opus and Explorer in my computer and any other? As I said - Explorer shows me files in normal way, without HDD grinding. So if it's any difference between Explorer view and Opus view - anyone can check this. Especially you because I am not so advanced in that as you.
[ul][li]In the screenshot I see there's "00:00" in the status bar. Is that one of the fields which shows the play-time of media files? If so, that would cause Opus to open (some) audio/video files, which is a possible explanation. (Sometimes buggy video codecs go wrong when told to look at files they don't handle correctly.)
[/li]
[li]In ProcMon, right-click one of the lines showing Opus opening a movie file and then select Stack and post a screenshot of the list that appears.[/li][/ul]
By the way - should be nice to check this, because i have no many mp3 or audio files in attachment directory, so maybe Opus should check only audio files when shows total time?
It should already only check audio (and video) files for that field.
Some plugins may open all files to check their types (although I'm not sure if that applies in this case), but that is usually very fast and wouldn't cause lots of HDD access.
My bet is that a video codec is going crazy on one of your files as I've seen that in the past. Just a bet though.
Maybe, but filemon shows me that every file, including GIF, PNG etc. are accessing - one by one (before I remove that mp3 total time count). It's not important but I think worth to check.
It's probably not those files causing things to go crazy, though.
If you want to check, create a copy of the dir with only the GIF / PNG files and see if it still happens.
(I guess this depends on what we both think of as "crazy"; I assume we're talking about the HDD making a lot of noise and getting stuck on a particular file for tens of seconds. Just opening each of the 1000 or so files, reading a few bytes from their headers to confirm their types, and then closing them shouldn't be that noticeable. Although it could trigger anti-virus to scan the files because they got opened, I guess. I think most A/V would cache the fact it had already scanned those files and not do much next time they were opened, though.)
I'm using computers by years and I'm not so big fan of AV software. I prefer to control my computer other ways - like Firewall with Application Behaviour feature and internet/system monitors plus virus scanning outside OS from time to time. So I know how AV software can be annyoing but that is not my problem. The only program that scanning my files is DOpus.
I need only basic informations so Filemon is good enough (and it's name of cat from old fairy-tale, so I remember that name better than new one) 
.
