AVI's causing high CPU in Explorer

[globaldonkey]

I have a strange CPU spiking problem. When I open a directory of AVI's (and
only AVI's, not MPG's or other video files) in Windows Explorer, and I hover
the mouse from file to file, my CPU has little spike's as it attempts to read
each file and display dimension / duration information on the bottom line of
explorer. Normally a bit of CPU spike wouldn't bother me, except that it
interferes with the mouse and makes it's movement very erratic.

Interestingly, this problem does NOT occur if I repeat the same test on a
directory full of AVI's on a Netbios share. The difference appears to be that
over Netbios, Explorer doesn't try and open each AVI to get the dimension /
duration info.

If I turn on the dimensions or duration column in Explorer and go to a
directory full of AVI's, It takes 3 or 4 seconds for explorer to display each
file's dimensions, and the CPU goes to about 60% on both CPU's.

[Bill's News]

"globaldonkey" > wrote in
message
...
>I have a strange CPU spiking problem. When I open a directory
>of AVI's (and
> only AVI's, not MPG's or other video files) in Windows
> Explorer, and I hover
> the mouse from file to file, my CPU has little spike's as it
> attempts to read
> each file and display dimension / duration information on the
> bottom line of
> explorer. Normally a bit of CPU spike wouldn't bother me,
> except that it
> interferes with the mouse and makes it's movement very
> erratic.
>
> Interestingly, this problem does NOT occur if I repeat the
> same test on a
> directory full of AVI's on a Netbios share. The difference
> appears to be that
> over Netbios, Explorer doesn't try and open each AVI to get
> the dimension /
> duration info.
>
> If I turn on the dimensions or duration column in Explorer and
> go to a
> directory full of AVI's, It takes 3 or 4 seconds for explorer
> to display each
> file's dimensions, and the CPU goes to about 60% on both
> CPU's.
>

It's not strange at all - it's third party, third world,
out-sourced programming! A broken forward reference in an AVI
file will send this code into a KIKI loop (named after a bird
which flies in ever diminishing circles until it disappears into
a dark place).

Search for old complaints about this. There are several
approaches to eradicating the cause and thus the effect.

Check out xpavifix, the ZIP file is 22,124 bytes.

Personally, I use this registry change:

To solve this problem, PERMANENTLY, do the following:

1. Run: regedt32
2. Go to

HKEY_CLASSES_ROOT\SystemFileAssociations\.avi\shel lex\PropertyHandler
3. Export the key (if you may want to restore it, I don't).
4. Delete the "Default" value which should be
"{87D62D94-71B3-4b9a-9489-5FE6850DC73E}"

Or, just copy this key from here and paste it into the
regedit search window.

N.B. You can also paste this key into a Google search to
verify what's said here.

NOTE: Once done, this will preclude Explorer's snooping and
display of supposed vital stats for AVI files. Keep a note
handy, in the event of a system restore or reload as you will
need to do this again.

[globaldonkey]

"Bill's News" wrote:

>
> "globaldonkey" > wrote in
> message
> ...
> >I have a strange CPU spiking problem. When I open a directory
> >of AVI's (and
> > only AVI's, not MPG's or other video files) in Windows
> > Explorer, and I hover
> > the mouse from file to file, my CPU has little spike's as it
> > attempts to read
> > each file and display dimension / duration information on the
> > bottom line of
> > explorer. Normally a bit of CPU spike wouldn't bother me,
> > except that it
> > interferes with the mouse and makes it's movement very
> > erratic.
> >
> > Interestingly, this problem does NOT occur if I repeat the
> > same test on a
> > directory full of AVI's on a Netbios share. The difference
> > appears to be that
> > over Netbios, Explorer doesn't try and open each AVI to get
> > the dimension /
> > duration info.
> >
> > If I turn on the dimensions or duration column in Explorer and
> > go to a
> > directory full of AVI's, It takes 3 or 4 seconds for explorer
> > to display each
> > file's dimensions, and the CPU goes to about 60% on both
> > CPU's.
> >
>
> It's not strange at all - it's third party, third world,
> out-sourced programming! A broken forward reference in an AVI
> file will send this code into a KIKI loop (named after a bird
> which flies in ever diminishing circles until it disappears into
> a dark place).
>
> Search for old complaints about this. There are several
> approaches to eradicating the cause and thus the effect.
>
> Check out xpavifix, the ZIP file is 22,124 bytes.
>
> Personally, I use this registry change:
>
> To solve this problem, PERMANENTLY, do the following:
>
> 1. Run: regedt32
> 2. Go to
>
> HKEY_CLASSES_ROOT\SystemFileAssociations\.avi\shel lex\PropertyHandler
> 3. Export the key (if you may want to restore it, I don't).
> 4. Delete the "Default" value which should be
> "{87D62D94-71B3-4b9a-9489-5FE6850DC73E}"
>
> Or, just copy this key from here and paste it into the
> regedit search window.
>
> N.B. You can also paste this key into a Google search to
> verify what's said here.
>
> NOTE: Once done, this will preclude Explorer's snooping and
> display of supposed vital stats for AVI files. Keep a note
> handy, in the event of a system restore or reload as you will
> need to do this again.
>
>
>
Does unregistering shmedia.dll do the same thing? I found this in another
forum. I did this, and it stopped explorer from "snooping" and solved my
problem.

Is there a fix that allows explorer to snoop, but does not spike the CPU?
From your initial description, it sounds like shmedia.dll is dodgy, which
supposes that it can / should be fixed?

[Bill's News]

"globaldonkey" > wrote in
message
...

<snip>

>>
> Does unregistering shmedia.dll do the same thing? I found this
> in another
> forum. I did this, and it stopped explorer from "snooping" and
> solved my
> problem.
>
> Is there a fix that allows explorer to snoop, but does not
> spike the CPU?
> From your initial description, it sounds like shmedia.dll is
> dodgy, which
> supposes that it can / should be fixed?

I had not read of the DLL and the simple solution of
unregistering for quite a while after having found and
implemented the registry change I noted. I suspect that the
result is the same, either way. Whatever method you use, leave
yourself a reminder for the inevitable reinstall of the OS.

Clearly that piece of code is poorly written. Everything one
could want to know about an AVI, for statistical purposes, is
located in the header. The header information is valid long
before the video/audio data is fully entered and the index
built. So there is no excuse for the behavior this code
exhibits.

There are other programs which examine AVI headers. AVICodec is
a handy tool http://avicodec.duby.info/.