Compatiblity with music players' msn features/plugins

The pidgin plugin has the ability to support "any player with a 'Send "Now Playing" information to MSN Messenger' feature" and I was wondering if that could somehow be added to the emesene music plugin.

By adding this feature you will be able to cover a lot music players without having to add each individually. Not all players may have the msn feature built in, but may have a plugin themselves that add it.

[c10ud]

no idea what that is, but emesene with the MPRIS support covers nearly every FOSS player. as for windows, etc. i have no idea :)

This was more for windows I guess, since linux seems to be covered.
From the look of it the pidgin plugin is using something called MsnMsgrUiManager (http://code.google.com/p/psymp3/wiki/MsnMsgrUiManager) to work with players such as WMP, iTunes, Songbird + LiveTweeter, Spotify, and some others. aMSN is also using MsnMsgrUiManager for its music plugin.

EDIT: This is pidgins msn-compat.c http://code.google.com/p/pidgin-musictracker/source/browse/trunk/src/msn-compat.c

[c10ud]

seems like the clients just create an hidden window with some particular id mimicking the official client's window and handle messages incoming from players (yes, seems like in windows players actively send their music data to wlm instead of wlm fetching them from somewhere) it could easily doable in python i guess

http://www.google.it/search?q=msnmsgruimanager+python

[segin]

Sorry to chime in late on this one, but I'm actually happy to see my documentation being referenced! (I wrote the doc on the MsnMsgrUiManager window that syst3mfailur3 linked to above.)

There's only one other "protocol" on Windows that's "standard". It's the Winamp "protocol". Note that I put "protocol" in quotations as it's not a protocol in the strict sense, and it sucks because it involves the messenger attaching to the media player as a debugger (!), allocating memory in it's memory space, sending a window message to have the player fill a struct in said allocated memory, copying the struct into the messenger's local process space, and then finally cleaning up (deallocate the memory allocated in the media player's process and finally detach)

The reason that this mess is done like this is because this interface is the API interface for Winamp plug-ins, which run in-process, and some of the window message parameters are process-local pointers. KVIrc's solution was to write a Winamp plug-in and have the plug-in hook the API window message loop to add new calls, which returned the data in a safe but slow manner (one. character. per. call.) On the other hand, this actually makes it very easy to support using Winamp plug-ins in other media players. AIMP2, a Russian clone of Winamp, supports Winamp plug-ins, and it's easy to see how they do it.

There is another method for Windows Media Player where MSN Messenger does pull the data from WMP using a COM interface, as opposed to having it pushed to MSN via a window message. See: http://code.google.com/p/pidgin-musictracker/source/browse/trunk/src/wmp.c and http://code.google.com/p/pidgin-musictracker/source/browse/trunk/src/disphelper.c

See the source I wrote in PsyMP3 1.x to handle those Winamp window messages: http://code.google.com/p/psymp3/source/browse/branches/1-CURRENT/winamp-ipc.bas
And the associated header for that source file: http://code.google.com/p/psymp3/source/browse/branches/1-CURRENT/winamp-ipc.bi

Here's the KVIrc source code for their end of their extended interface: https://svn.kvirc.de/kvirc/browser/trunk/kvirc/src/modules/mediaplayer/MpWinampInterface.cpp

And pidgin-musictracker source that uses the wtf method I just outlined above: http://code.google.com/p/pidgin-musictracker/source/browse/trunk/src/winamp.c