22
11
We have directories containing hundreds of video files. When using Windows Explorer (Windows 7 64 Pro) to browse and rearrange these directories, Explorer slows down to an unusable level, uses gigabytes of RAM, and pre-empts or slows other programs (such as Media Center) from using the same disk while this is in progress.
This is accompanied by a very slow-growing green bar in the Address slot.
What Explorer appears to be doing is reading the video file content to produce thumbnails, or obtain other metadata. This is not useful for our purposes, so we'd like to disable this behavior. How does one do that?
These threads may be related:
Superuser Prevent Windows Explorer from trying to extract metadata. [Explanation added 2014-04-11] This solution disables the registry's listing for a PropertyHandler for a particular filename extension. This could be useful, but is a little drastic -- would disable display of properties in Explorer for all directories, not just problem ones. (See more discussion in the answers.)
Superuser: "Sorting by Date - Very Slow" : The 'Date' column attempts to get EXIF data, and is distinct from the filesystem 'Date created' and 'Date modified' columns.
Microsoft: "Explorer - sort by date very very slow"
2014-04-14: Summary of suggestions and findings
I think at this point we're well satisfied with the answers, and remaining symptoms are unrelated to Windows Explorer. So, herewith a summary of suggestions and a few other things we learned.
General considerations
Disk wake-up: Initial slowness when accessing a disk after a long period of disuse may be attributable to the disk having gone to sleep.
Disk errors: Obviously if there are hardware errors which compel retries, this will gravely slow down Explorer and any other program.
Disk contention: Other programs performing intensive activity on the same drive will obviously contend with, and slow, Explorer's attempts to display a drive's contents. If Explorer needs to read only the directory, then impact may be minimal, but if Explorer also needs to read each file for metadata, then contention problems will be greatly magnified.
Disk contention from anti-virus software: Explorer's attempts to read metadata may prompt AV software to read and OK each file first. Consider disabling AV for trusted file types (for example, wtv files saved by Media Center).
Explorer settings
Disable display of thumbnails: "Organize" → "folder and search options" → "view" → put a checkmark in "always show icon instead of thumbnails" → press apply and close.
Disable gathering of video-specific metadata: Culprit folder → "properties" → "customize" → under "optimize this folder for:" open the drop down menu and choose "general items" → place the checkmark in the box under the drop down menu at "apply to all subfolders" → press apply and close.
Disable even more the gathering of video-specific metadata: In a culprit folder's "detail view", remove any columns based on video file metadata not in the file system's directory information. This includes the Length (duration) column, and also the Date column (based on video metadata, and distinct from the file system's "Date created" and "Date modified" columns.)
In the registry
Disable "Property Handlers" for video filename extensions (such as wtv, mp3 etc). This, of course, would apply system wide, not just for particular directories. Can be accomplished with RegEdit, or with 3rd party program ShellExView. (See Answers for details.)
More on thumbnail and other caches
We noted that after disabling thumbnails and metadata, when we re-enabled them, performance was speedy. (Ie: The green bar of slowness didn't return.) This suggests that the changes did something regarding the thumbnail cache(s), perhaps deleted them and later rebuilt them. Turns out that by default Explorer saves thumbnails in each directory (in thumbs.db) and also in the user's AppData\Local\Microsoft\Windows\Explorer directory in a set of thumbcache*.db files. It's possible these get into a bloated or otherwise slow state, and deleting them might prompt faster operation.
Not known (by us) is whether Explorer caches any other metadata info (such as Length, Date, Location, Protection and so on).
Other interactions
Not attributable to Explorer per se, but potentially useful clues.
We noted in Task Manager > Resource Monitor that Media Center was performing bad behavior that created a lot of disk activity: A media center component, ehrec.exe, would endlessly cycle through reading a few k of data from a particular set of video files -- on one drive, about 200 video files. It is as though Media Center is unable to complete reading metadata from those files, and just keeps trying to read files for which it doesn't have complete metadata. These files seem undamaged as far as the file system is concerned (can copy without problems). When we asked Explorer to display directories on this particular disk, conceivably Media Center's activity competed for disk access time. We disconnected this drive for other tests.
Thanks to all respondents.
The solution you've linked could well work, if the PropertyHandlers key contains the extension of your video files, then removing the GUID (which kinda just pointing to a dll with the metadata code in it) could well work. You can backup the key before hand. – cjb110 – 2014-04-10T07:20:50.580
@cjb110: Are you speculating that creating an essentially empty PropertyHandler key would pre-empt Explorer from fetching metadata? That seems plausible, but have you actually tried it? – gwideman – 2014-04-10T07:43:38.443
Pretty much, I would try but don't have a Win7 machine to hand. It's assuming that the PropertyHandler key is 'main' way to do this. If you don't see your extensions then I wouldn't bother...but it would be fairly harmless to try if they were there, as you can easily backup the higher level key. – cjb110 – 2014-04-10T08:54:09.567
Oh and removing the extension key completely seems better than removing or making the GUID invalid. – cjb110 – 2014-04-10T08:55:19.863
@cjb110 Light-bulb moment: In that PropertyHandler suggestion, I finally took note of the '#' prepended to the GUID, and realized it was to invalidate the GUID, not just some syntax to indicate a number. Doh! OK, now it's clear what that solution does. Thanks for the prod. – gwideman – 2014-04-10T22:34:34.773
1Well, this has been the first time i interacted on this site, and I must say that i am impressed by how things are handled here. I originally only wanted to join stackoverflow for some programming related questions, and feared that stackexchange turn out to be another "yahoo! answers". I am quite happy that this doesn't seem to be the case. Good to hear that you seem to have fixed your problem! Both of us seem to have learned something, also! Cheers! – keen – 2014-04-14T16:03:27.330