Tweet
We have noticed that several users on this forum and via email have been experiencing problems with Media Player 9.0 in AutoPlay Media Studio 4.0. We have been looking into these issues and this thread is where we will post what we know of the issues and what can be done about them.
AutoPlay Media Studio 4.0 uses the Windows Media Player 6.4 ActiveX control for the embedded Media Player objects. Until recently, this COM interface was provided by the file msdxm.ocx (in your system folder). However, with Media Player 9.0, Microsoft has changed the interfaces to the Media Player ActiveX control.
Now, in good COM fashion, they have provided a new control for this since they have changed existing interfaces. The new media player control uses wmp.ocx and wmp.dll to provide the ActiveX interface. They use a different CLSID then the 6.4 interface, so that is OK.
The problem is that (for reasons beyond my comprehension) Microsoft has also provided a new file called wmpdxm.ocx which is a "Media Player 6.4 Shim" and registered it with the same CLSID as the old msdxm.ocx file. I imagine that this new file, in theory, is supposed to provide compatible, old interfaces to the new interfaces in the 9.0 control. That is fine, but the problem is that the interfaces do not seem to be completely compatible in all ways with the way that the old control acted.
By now you are saying, "OK, nerd, but how does that help me?" Stick with me...
It seems that the most reported problems with this new system have been reported regarding the AMS40 design environment acting wierd or in some cases hanging.
We have several workarounds if you experience these problems:
1. Turn off the live preview of Media Player objects
Go to Edit > Preferences and select the Objects category. In the Options section, uncheck the "Show live preview for Media Player Objects" option. This will cause the program not to use the ActiveX control at design-time on your pages.
2. Re-register the old 6.4 control
This method seems to be pretty solid and foolproof, from our experimentation. All we are going to do is tell the system to use the old msdxm.ocx control instead of the new wmpdxm.dll when using the 6.4 interfaces. To do this:
a) Select Start > Run on your system
b) Type "regsvr32.exe msdxm.ocx" and hit Enter
c) You should see a message saying that "DLLRegisterServer in msdxm.ocx succeeded".
At this point, everything should work as nicely as it always did. From what we know at this point, you can leave this setting in place without affecting the new Media Player 9.0 ActiveX control or the WMP application itself. In other words, applications like AMS40 (and Web pages, BTW) that reference the 6.4 control will use it properly and applications that use the new 9.0 control will also work properly.
If you experience problems or freak out and have doubts about my advice, you can always re-register the 9.0 "Shim" by doing the following:
a) Select Start > Run on your system
b) Type "regsvr32.exe wmpdxm.dll" and hit Enter
c) You should see a message saying that "DLLRegisterServer in wmpdxm.dll succeeded".
So far we have not had many reports of problems with the Media Player control on a user's system at runtime using the AMS40 runtime program. If you do hear of any or experience them yourself, please report them in detail here. We are especially interested in what type of media you are playing in the control (MPEG, AVI, WMV, etc.) as well as what AMS40 actions that you are using on them. If you have a user that really can't get around the problem for some reason, they can also use fix # 2 above.
Please don't let this post alarm you to much it is long and detailed because we are committed to giving you all of the information that we have to enable you to have the most reliable, dynamic application that you can. For the most part, we have not had very many reports of problems with WMP9.0 and many users with it have no troubles at all. As far as we know, it is not having much affect on the runtime side of things, so your users will be fine.
We'll post more information as it becomes available.
AutoPlay Media Studio 4.0 uses the Windows Media Player 6.4 ActiveX control for the embedded Media Player objects. Until recently, this COM interface was provided by the file msdxm.ocx (in your system folder). However, with Media Player 9.0, Microsoft has changed the interfaces to the Media Player ActiveX control.
Now, in good COM fashion, they have provided a new control for this since they have changed existing interfaces. The new media player control uses wmp.ocx and wmp.dll to provide the ActiveX interface. They use a different CLSID then the 6.4 interface, so that is OK.
The problem is that (for reasons beyond my comprehension) Microsoft has also provided a new file called wmpdxm.ocx which is a "Media Player 6.4 Shim" and registered it with the same CLSID as the old msdxm.ocx file. I imagine that this new file, in theory, is supposed to provide compatible, old interfaces to the new interfaces in the 9.0 control. That is fine, but the problem is that the interfaces do not seem to be completely compatible in all ways with the way that the old control acted.
By now you are saying, "OK, nerd, but how does that help me?" Stick with me...
It seems that the most reported problems with this new system have been reported regarding the AMS40 design environment acting wierd or in some cases hanging.
We have several workarounds if you experience these problems:
1. Turn off the live preview of Media Player objects
Go to Edit > Preferences and select the Objects category. In the Options section, uncheck the "Show live preview for Media Player Objects" option. This will cause the program not to use the ActiveX control at design-time on your pages.
2. Re-register the old 6.4 control
This method seems to be pretty solid and foolproof, from our experimentation. All we are going to do is tell the system to use the old msdxm.ocx control instead of the new wmpdxm.dll when using the 6.4 interfaces. To do this:
a) Select Start > Run on your system
b) Type "regsvr32.exe msdxm.ocx" and hit Enter
c) You should see a message saying that "DLLRegisterServer in msdxm.ocx succeeded".
At this point, everything should work as nicely as it always did. From what we know at this point, you can leave this setting in place without affecting the new Media Player 9.0 ActiveX control or the WMP application itself. In other words, applications like AMS40 (and Web pages, BTW) that reference the 6.4 control will use it properly and applications that use the new 9.0 control will also work properly.
If you experience problems or freak out and have doubts about my advice, you can always re-register the 9.0 "Shim" by doing the following:
a) Select Start > Run on your system
b) Type "regsvr32.exe wmpdxm.dll" and hit Enter
c) You should see a message saying that "DLLRegisterServer in wmpdxm.dll succeeded".
So far we have not had many reports of problems with the Media Player control on a user's system at runtime using the AMS40 runtime program. If you do hear of any or experience them yourself, please report them in detail here. We are especially interested in what type of media you are playing in the control (MPEG, AVI, WMV, etc.) as well as what AMS40 actions that you are using on them. If you have a user that really can't get around the problem for some reason, they can also use fix # 2 above.
Please don't let this post alarm you to much it is long and detailed because we are committed to giving you all of the information that we have to enable you to have the most reliable, dynamic application that you can. For the most part, we have not had very many reports of problems with WMP9.0 and many users with it have no troubles at all. As far as we know, it is not having much affect on the runtime side of things, so your users will be fine.
We'll post more information as it becomes available.