Recently in musictracker Category


| No Comments
If your appreciate my work on open source software, and would like to buy me a beer to say thank you, you can do so by clicking this button ;-)


musictracker 0.4.7 changes

| No Comments
  • Correct the way we retrieve track artist info from WMP (#16)
  • Fix a problem where tune status could sometimes get left with stale data (e.g. if player was closed whilst pidgin was closed)
  • Apply patch from hyperair adding a timeout to dbus calls, so they cannot block indefinitely (hanging pidgin) if something has gone wrong in the target application (#13)
  • Fix restoring saved status so it correctly restores account-specific saved status (#11)
  • Attempt to avoid being told "MSN: Friendly name changes too rapidly" when player is stopped
  • Some more tidying up
  • Update libmpdclient to latest svn (revision 7402) (this fixes a file descriptor leak when an IPv6-enabled MPD is running) (#137, maybe #12?)
  • Enable MPD client in windows build
  • Fix type conversion warnings when building for x64 (#18)
  • Use dopen/dlsym to access XMMS2 client library, so it doesn't become a run-time dependency if we build with XMM2 support enabled

x86_64 crosscompilation

| No Comments

I don't actually have an x86_64 machine to build or test stuff on, but since I had some issues reported with x86_64 compilation, I was wondering if I could cross-compile to x86_64 on my x86 machine to reproduce them.

Generating the toolchain on gentoo is pretty easy thanks to crossdev

USE="-*" crossdev -S --target x86_64-pc-linux-gnu

The gentoo cross-compilation guide explains how to cross-compile arbitrary packages

ROOT=/usr/x86_64-pc-linux-gnu/ CBUILD="i686-pc-linux-gnu" CHOST="x86_64-pc-linux-gnu" emerge libpcre

Obviously can't test any of it works, though :S

Japanese text in mp3 tags to musictracker

| 1 Comment

Since my friend Kacey gave me a nice J-Pop mp3 with some japanese text in the tag, I've been able to do some testing to see if these characters can get passed from the player into musictracker and hence to the status message....

jon@clairmont $ mid3v2 10\ 世界はこの手の中に.mp3
IDv2 tag info for 10 世界はこの手の中に.mp3:
APIC= (PNG, 105828 bytes)
TENC=iTunes v7.7.1

This all seems to work swimmingly on various players under Linux, but under Windows it's more complex...

  • GetWindowText() on the foobar2000 window just returns a load of "?" characters, presumably because they don't exist in the local codepage (unlike accented characters like ö which survive this translation intact). Using GetWindowTextW() to retrieve the title in wide-character form then converting it to UTF-8 seems to work fine.
  • Winamp makes an utter hash of returning these characters via the (legacy) IPC_GET_EXTENDED_FILE_INFO interface we are using. Updating to use IPC_GET_EXTENDED_FILE_INFOW fixes this. We also need to use GetWindowTextW() as above for looking at the window title (which we use for stream information)
  • The mysterious wmp9.dll seems incapable of returning these correctly from Windows Media Player.... yet another reason to replace this code with something else....
  • This all works fine with iTunes, but it doesn't seem possible to actually display the song title correctly in iTunes, since it uses a fixed font (Lucida Grande?) which you can't seem to change and which doesn't have the glyphs. Later: turning on East Asian language support in Windows XP fixes this, presumably as it lets Windows do it's font linking thing to find the glyphs in another font...

So now I know more about this windows wide character nonsense than I ever wanted to. Oh, and I'm now one of the top listeners to Nanase Aikawa on :-)

pidgin monotone crosscompile for win32

| No Comments

Some notes on cross-compiling current monotone pidgin for win32. Don't do this if you have even less of an idea about what you are doing than me :-)

  • You'll need a i686-mingw32 toolchain, obviously :-)
  • run ./ to use autotools to prepare the monotone sources for building
  • BuildingWinPidgin has most of the steps, but a few things didn't quite work for me
  • windres: icon file `some path' does not contain icon data
  • windres doesn't seem to do string literal concatentation after preprocessing, so the paths for various pixmaps aren't merged with the filename. Work around by editing the .rc file to have the correct full pathname (this is a bug in my version of windres)
  • makensis doesn't seem to like command switches introduced with "/", so change the Makefile.mingw to use "-"
  • makensis fails "Error: no branding image found in chosen UI!"
  • Workaround: comment out the line "!define MUI_HEADERIMAGE" in the .nsi file (this is a bug in my version of makensis)
  • makensis fails "Invalid command: System::Call"
  • gcc can't build the System plug-in properly. Workaround is to copy over Plugins\System.dll from a Windows install of nsis
  • Relative paths to gtk_installer in seem to have one too many "..\"
  • The msnp9 protocol plugin is the one built by default for windows at the moment, not the shiny new msnp15 protocol plugin (the opposite way around to the linux build). Since this is the thing I wanted to test with, change to match :-)

pidgin-musictracker has one additional dependency, libpcre, so you'll need to place a static library of that into win32-dev to link with as well...

patch frenzy!

| No Comments

Work through the old musictracker issues, looking for ones with patches attached, applying and testing them. Lots of stuff:

  • patch from chet.the.gray for Listen player support (#13)
  • patch from puthali.HB for feed support (#48) feed stuff needs some work.... breaks player autodetection at the moment if a account name is set, perhaps it should look at timestamp and infer off it is more than 5 minutes (configurable?) in the past; the parsing looking for a non-standard hyphen character separating artist and title in the feed data is also questionable.

  • patch from patrick.dessalle for Audacious 1.4 support (#86)
  • patch from hyperair for Banshee 1.0 support (#87)
  • patch from thelrix for XMPP user tune support (#96)
  • patch from ZeeGeek for XMMS2 player support (#121)

    XMMS2 patch is a bit problematic in that it wants to directly link with xmmsclient library, which gives us a built-time dependency on it. Rejig the autoconfiscation slightly so we can build without it being present, but this still has the problem that binaries which are built with the xmmsclient support have a run-time dependency on it. Should use dlopen/dlsym (as xmms1 support does) to avoid depending on presence of library? (otherwise pidgin can't load it if the library is absent)

  • Improve "Toggle status changing" action so it has a dynamic menu item which reflects the current Enabled/Disabled state (#39), based on a patch by TorresMAT

    pidgin core doesn't provide a way to do this directly, so this involves some kludging, but it's so needed, an action to toggle with no way of knowing if we are currently on or off is just confusing

  • Rhythmbox: Slightly improve the way we report information for streams (#35), based on a patch by eemil.lagerspetz
  • Winamp: don't screw up titles which contain hyphens, try to still do something useful with streams (#59) based on a patch by leonardo.monteiro.fernandes

    Winamp player code has some crazy stuff to try to guess the title from the winamp window title when we are playing a stream; sadly this screws up if their is a hypen in the title, which seems to cause lots of people problems; Streams are generally problematic as they probably only have a streamtitle, not all the fields we expect from a mp3....

  • amarok: Check for running dcopserver to avoid problems when dcop blocks for long enough that we appear to hang pidgin (#68), Don't spam stderr with "call failed" errors from trying to dcop amarok

    Not quite able to reliably reproduce the problem case, although I have seen it occasionally: if there is no dcopserver running, sometimes 'dcop' blocks for a while before reporting failure; unfortunately this seems to be the same or longer than our player check interval so we hang pidigin. Othertimes dcop returns immediately with an error, can't quite work out what causing the difference.

Musictracker project fork

| No Comments

No responses from the existing project owner, so decided to create a fork pidgin-musictracker

Creating a project at google-code and cloning the existing svn repository is surprisingly painless.

Checkin the changes from my patch, and then do some scripting work to automate the release process. Existing makefile omits the windows installer generation stage, so add rules for that (pleased to find that nsis Gentoo package exists, so I can build the windows installer under linux)

This scripting also generates development snapshots

musictracker is a most excellent now-playing plugin for the Pidgin multiprotocol IM client.

Unfortunately it seems to be un-maintained at the moment.

Here's an unofficial release with fixes for the bugs which irritate me

musictracker.dll for Windows for linux x86
musictracker-0.4.2-unofficial.patch source patch

Edit:if you want to tell me about a problem with this plugin, please go here rather than leaving a comment... I'll see it quicker :-)

Edit2:I've created a fork of musictracker at google code, go there for the most recent version

2008-07-10 (Version 0.4.2 unofficial)

  • Fix finding window for Foobar2000 and later
  • Don't crash if track info from player isn't valid UTF-8!
  • Get UTF-8 track info from iTunes and WMP
  • Avoid damaging valid UTF-8 track info when removing unprintable characters
  • If the track info message is empty, try to restore the status message selected in UI (e.g. for when your player stopped message is empty)
  • Remove use of modified MSN protocol plugin to append now-playing info to nickname (I suggest you use msn-pecan which supports personal messages)
  • Fixed to build with latest purple

About this Archive

This page is an archive of recent entries in the musictracker category.

Images is the previous category.

Projects is the next category.

Find recent content on the main index or look in the archives to find all content.