Yep, will have another look at that for the upcoming bugfix release, maybe I can find the reason for this.Known issue.
https://github.com//WifiRemote/issues/2
I attached a log files.
Wifi Remote plugin is in folder ....plugin\process\WifiRemote.dll
Mediaportal Configuration->Plugins->Process Plugins - no WiFi Remote Icon.
[2014-01-30 22:21:11,446] [Log ] [MPMain ] [INFO ] - PluginManager: Plugin: 'C:\Program Files (x86)\Team MediaPortal\MediaPortal\Plugins\process\WifiRemote.dll' / Version: 0.8.0.0
[2014-01-30 22:21:11,466] [Error ] [MPMain ] [ERROR] - Exception while loading IPlugin instances: WifiRemote.WifiRemote
[2014-01-30 22:21:11,466] [Error ] [MPMain ] [ERROR] - System.InvalidCastException: Unable to cast object of type 'WifiRemote.WifiRemote' to type 'MediaPortal.GUI.Library.IPlugin'.
[2014-01-30 22:21:11,466] [Error ] [MPMain ] [ERROR] - Unable to cast object of type 'WifiRemote.WifiRemote' to type 'MediaPortal.GUI.Library.IPlugin'.
I'm trying to design a plan of attack in creating an RTI (think Crestron etc) driver for MediaPortal - the wifiRemote is the perfect api to play with. My initial barrier to entry is hinging on the ability to access the api. So IF I have a REST client, and I sent a GET request to the machine with MediaPortal on it at 10.0.0.14 using port 8017 (default) with say the 'Identify' command - would it not be a GET request to http://10.0.0.14:8017/identify ?