@Dale#1976
Just to make sure it's not my plugin, can you disable mine and enable the built in MCE support and check if the problem still exists? If it still occurs then I guess you'll need to wait for a fix in the SVN, if it doesn't then I'll have to figure out what's changed and try to fix it
I've added the ability to "quick setup" a set top box for external channel changes in my latest version of the code, so as soon as I have your codes I'll start releasing the plugin with that enhancement. Thanks.
@opusnut:
The log entry about MceIr.dll is nothing to worry about. It's because that dll is not a plugin, but is needed by my plugin for interop. I will look at moving the file to avoid that log entry.
The lower section of the log shows that the commands are being mapped, but doesn't say anything about the blasting ... which is odd. Can you send me the "MCE Replacement.xml" from "MediaPortal\InputDeviceMappings\custom" ? That will show me what the mappings are and maybe show why they are failing. Also, turn on extended logging in the plugin and see if there is any more information in the log.
Have you tried mapping your ATI remote in the "different remote" section of my plugin?
When I started writing this plugin I actually put it straight into the MediaPortal source. Then I cut it out into a plugin, but once the plugin is 100% I will put it to the devs that it might be worth integrating. And as you say, this would let anyone with an MCE transceiver blast codes, no matter what input device they are using.
The way I think about this is that you would integrate my changes into the mapping form so anything can map to blast an IR command. And then have another section in the setup for choosing an IR blaster, this could be an MCE or USBUIRT, etc... This approach should work pretty well. But this is something that can only be considered once this plugin is 100%, I'm sure the devs would agree.
Thanks for your help.
Cheers,