MPG Context Menu ignored?

[Robert Morley]

First off, I'm using Vista SP1.

Okay, so here's the problem: I've got a handy utility that extracts the
closed captioning from MPG files and generates an SRT (subtitles) file for
them. In previous versions of Windows, I just added the various commands to
the context menu, either by the built-in editor or the registry. Obviously
in Vista, I'm forced to use the registry. No problem.

Imagine my surprise, however, when all of my changes to the HKCR .mpg entry
were completely ignored! And it's not just my changes, I can see where VLC
wanted to add its own context menu entries in there as well, and they're
being ignored as well. Even removing the .mpg entry entirely, in HKCR,
HKLM\Software\Classes, and HKCU\Software\Classes (it wasn't actually there),
had absolutely NO effect on the context menu for .mpg files
whatsoever...even after a reboot!

What gives?

How can I customize the context menu for MPG files in Vista SP1?



Thanks,
Rob

 

[Robert Morley]

Oh and an interesting addition to this: I just tried changing the extension
from .mpg to .mpeg, and the context menu's working just fine there!


Rob

 

[zachd [MSFT]]

You don't mention any of the details of your attempted registry change, so
it's hard to speculate. =\

 

[Robert Morley]

You don't mention any of the details of your attempted registry change,
so it's hard to speculate. =\

It didn't matter what I did within the .MPG, MPEGFile or
WMP11.AssocFile.MPEG keys...even deleting them didn't affect the context
menu for MPGs at all.

In the end, however, it turned out to be WMP and/or Vista overriding
anything I did due to having WMP flagged as the default media player. When
I turned off the "Enable access to this program" check box in the Default
Programs, the context menu for MPGs returned to what I would have expected.

I would've pursued the issue further, but as it turned out, I got hit by the
Windows Search 4.0 "Search failed to initialize" bug and was forced to
migrate to a new user profile to resolve the problem. As I'm sure you can
imagine, I didn't allow WMP to become the default media player this time
around, thus avoiding the problem altogether.

So problem's solved...if not quite by a method I'd normally recommend.



Rob

 

[zachd [MSFT]]

If you want to explain your methodology and what exactly you were setting, I
might have insight here. It's an area I know relatively well. If you're
happy with your one-off solution, rock on.

'enable access' within this context just sets shellex handlers - I'm not
sure how that'd collide with what you're doing. It'd be good to understand
what you were doing. =\

 

[Robert Morley]

I'm happy with the solution I found, though obviously it's not one I'd
recommend in the general case, so I attempted to recreate the problem, and
after a little playing, I was successful.

After creating a test user account, I figured out that contrary to what I
originally thought, it's not WMP that's at fault, though it may or may not
be a contributing factor. The real problem seems to be with PowerDVD 8.
Since WMP was the only thing showing up on the context menu and all other
players seemed to be ignored, I naturally blamed it on WMP. If you happen
to have a copy of PowerDVD 8 handy, here's how I triggered the problem.

Go into PDVD's Configuration menu, then on the Player tab, select Advanced,
and then go to the File Assocation tab. Associate MPG with PowerDVD, close
the various windows, and right-click on an MPG file to see the problematic
context menu. Looks fine, if somewhat different, until you attempt to
customize it.

The problem seems to be with HOW PowerDVD associates its files. Unlike most
apps, it adds association registry info to HKCU instead of HKLM. Even if
you later remove the .MPG entry from HKCU\Software\Classes, the association
seems to still "stick". Damned if I know how that works, but clearly
there's something else going on here.

I'm not as familiar with everything as you clearly are, and it's a little
late to be playing around right now for me, but if you'd like, I'll
duplicate the problem again tomorrow and compare before & after registry
snapshots to see if I can figure out more about what's going on. On the
other hand, if something I've said above tells you exactly what's going on,
so much the better.



Rob

 

[zachd [MSFT]]

Yeah, that's not nice on their part. If I were you I'd politely suggest to
their support that they change this.

I thought about doing this for WMP at some point, but realized that it'd
break every other vendor exactly like this so decided WMP didn't need to do
that. It's very important to play nice. =)