Paul Kuliniewicz » Music Applet http://www.kuliniewicz.org/blog After all, it could only cost you your life, and you got that for free. Mon, 28 Jan 2013 03:25:49 +0000 en-US hourly 1 http://wordpress.org/?v=3.8.5 http://creativecommons.org/licenses/by-nc-nd/3.0/us/ Panflute http://www.kuliniewicz.org/blog/archives/2009/08/17/panflute/ http://www.kuliniewicz.org/blog/archives/2009/08/17/panflute/#comments Tue, 18 Aug 2009 02:37:05 +0000 http://www.kuliniewicz.org/blog/?p=1483 Panflute is the new black Music Applet.

Let me explain.

Panflute is slated to be the successor to Music Applet. Its fundamental architectural change is the complete separation of the part that draws the panel applet from the part that figures out how to talk to the backend music player. By “complete”, I mean that Panflute makes them entirely separate programs. This opens the possibility of other software also using the Panflute backend instead of figuring out its own way to talk to a dozen different music players. A panel applet is just one possibility — you might want a desklet, or whatever GNOME 3.0 will replace panel applets with, or an alarm clock, or something else I can’t even think of.

The goal of the Panflute backend is to make everything look like it has a nice, clean MPRIS interface. MPRIS is great because it specifies a common interface for programs to talk to music players. MPRIS isn’t so great because many popular players (such as Rhythmbox and Banshee) don’t use it, and many players that do implement it either deviate from the spec in some areas (such as Audacious) or have some odd quirks about their interpretation of the spec (such as Amarok). The Panflute backend papers over all these issues, presenting a single, common, consistent interface, regardless of what player is actually running. It also adds some (clearly marked) extensions to MPRIS to provide features not available in MPRIS 1.0, such as setting metadata (particularly ratings) for the current song, or having a convenient way to get updated position information without having to resort to polling.

Panflute also provides a panel applet to replace the old Music Applet. At this time not much has changed feature-wise, but by doing a ground-up reimplementation, I’ve been able to throw out a bunch of legacy code to work with now-fairly-old libraries and to redesign things to support more flexible layout of the applet’s content, such as the oft-requested support for fat panels.

Perhaps most importantly, however, is the fact that I’m using Launchpad to host development of Panflute instead of doing things directly off of kuliniewicz.org. This means I’ve now done something I should’ve done a long time ago and started using a proper bug tracker instead of relying on e-mail. Finally.

The plan for now is to get Panflute up to feature-parity with the most recent release of Music Applet and make that a 0.something release. The 1.0 release will try to include as many feature requests from Music Applet as I can manage, as well as a testing tool to help verify that the code that handles talking to each music player works as expected, and to map out what functionality isn’t available. (Hey, that’s another thing that can exploit the applet/backend separation!) The 1.0 release should also make sure those player support modules implement as much of the MPRIS spec as possible; so far I’ve been focusing on the /Player object (which the applet makes heavy use of) and largely ignoring the /TrackList object (which it ignores completely). Obviously, for the Panflute backend to be generally useful for other developers, it needs to be full-featured.

I really ought to formalize the above paragraph a bit and get a proper blueprint for future development up in Launchpad….

Anyway, the Panflute code hosted on Launchpad is functional, with all applet features except pop-up notifications implemented and backend support for Rhythmbox, Banshee, Amarok, Audacious, Muine, and VLC implemented. There’s still some rough edges, particularly how the applet doesn’t yet bother to start the backend process, but those issues will be easy enough to fix. (And now that there’s an actual bug tracker, you can file a bug if something is amiss and/or missing.)

]]>
http://www.kuliniewicz.org/blog/archives/2009/08/17/panflute/feed/ 8
Music Applet 2.5.1 released http://www.kuliniewicz.org/blog/archives/2009/01/12/music-applet-251-released/ http://www.kuliniewicz.org/blog/archives/2009/01/12/music-applet-251-released/#comments Tue, 13 Jan 2009 03:11:55 +0000 http://www.kuliniewicz.org/blog/?p=1115 Hot on the heels of the previous version, Music Applet 2.5.1 has been released. This version is purely a bug-fix release and adds no new features. It does, however, fix a bug that could leave the applet in a hung state when the music player closes, and it fixes a bug in fetching album art from Rhythmbox.

]]>
http://www.kuliniewicz.org/blog/archives/2009/01/12/music-applet-251-released/feed/ 4
Music Applet 2.5.0 released http://www.kuliniewicz.org/blog/archives/2009/01/01/music-applet-250-released/ http://www.kuliniewicz.org/blog/archives/2009/01/01/music-applet-250-released/#comments Fri, 02 Jan 2009 00:27:15 +0000 http://www.kuliniewicz.org/blog/?p=1107 Keeping my word, Music Applet 2.5.0 is now available. This release adds support for the long-awaited Amarok 2. It also fixed lots of bugs. In particular, the applet will no longer try to take over your entire panel if you play a song with a long title, and handling of metadata when playing Internet radio streams is vastly improved. There are additional bug fixes too; check the release notes for details.

]]>
http://www.kuliniewicz.org/blog/archives/2009/01/01/music-applet-250-released/feed/ 6
Music Applet 2.4.2 released http://www.kuliniewicz.org/blog/archives/2008/08/10/music-applet-242-released/ http://www.kuliniewicz.org/blog/archives/2008/08/10/music-applet-242-released/#comments Mon, 11 Aug 2008 01:33:29 +0000 http://www.kuliniewicz.org/blog/?p=832 Music Applet 2.4.2 is out. This is another bugfix-and-translation-updates-only release. In particular, it fixes the slow creep in CPU usage after each song and updates the Polish (pl) translation.

]]>
http://www.kuliniewicz.org/blog/archives/2008/08/10/music-applet-242-released/feed/ 6
Music Applet 2.4.1 released http://www.kuliniewicz.org/blog/archives/2008/07/27/music-applet-241-released/ http://www.kuliniewicz.org/blog/archives/2008/07/27/music-applet-241-released/#comments Sun, 27 Jul 2008 18:46:44 +0000 http://www.kuliniewicz.org/blog/?p=811 Music Applet 2.4.1 has been released. This is a bug-fix release, with no new features. The dependency on the deprecated python-dcop, previous used for Amarok support, has been removed. A bug in password handling for MPD has also been fixed. See the release notes for details.

]]>
http://www.kuliniewicz.org/blog/archives/2008/07/27/music-applet-241-released/feed/ 3
Music Applet 2.4.0 released http://www.kuliniewicz.org/blog/archives/2008/06/10/music-applet-240-released/ http://www.kuliniewicz.org/blog/archives/2008/06/10/music-applet-240-released/#comments Wed, 11 Jun 2008 02:47:37 +0000 http://www.kuliniewicz.org/blog/?p=789 Music Applet 2.4.0 has just been released. The main change is that it now supports the recently-released Banshee 1.0, in addition to older versions of Banshee. There’s also improved support for debugging crashes, as well as an updated Czech (cs) translation.

Unfortunately, the new version of Banshee doesn’t provide a way to manipulate song ratings. Once that gets fixed in Banshee, I’ll update Music Applet accordingly.

A few technical notes on Banshee 1.0 support: since this new version of Banshee completely changed its D-Bus interface, there’s now two plugins for Banshee: the old one and the new one. While it’s inelegant to have two plugins for what the user sees as one program, it’s the only reasonable technical solution, given that the two versions of Banshee are completely different as far as Music Applet is concerned. If you have problems with Banshee support after upgrading the applet, check to make sure the new plugin (now called “Banshee”) is enabled. The old plugin has been renamed “Banshee (pre-1.0)”. I have no plans to remove support for old versions of Banshee any time soon.

]]>
http://www.kuliniewicz.org/blog/archives/2008/06/10/music-applet-240-released/feed/ 3
Music Applet 2.3.1 released http://www.kuliniewicz.org/blog/archives/2008/04/13/music-applet-231-released/ http://www.kuliniewicz.org/blog/archives/2008/04/13/music-applet-231-released/#comments Mon, 14 Apr 2008 02:09:17 +0000 http://www.kuliniewicz.org/blog/archives/2008/04/13/music-applet-231-released/ A new release of Music Applet, version 2.3.1, is now available. This is primary a brown-paper-bag release, fixing the crasher that, in hindsight, probably affected everyone trying to use 2.3.0. If you were one of them, try upgrading to 2.3.1 and see if that fixes things for you.

For those interested, I’ve done a write-up of what was causing the bug and why it took me so long to figure it out.

There’s also a few other bug fixes, as well as a bunch of new translations for Czech (cs), German (de), Spanish (es), French (fr_FR), and Russian (ru).

]]>
http://www.kuliniewicz.org/blog/archives/2008/04/13/music-applet-231-released/feed/ 1
Brown paper bag http://www.kuliniewicz.org/blog/archives/2008/04/13/brown-paper-bag/ http://www.kuliniewicz.org/blog/archives/2008/04/13/brown-paper-bag/#comments Mon, 14 Apr 2008 02:02:58 +0000 http://www.kuliniewicz.org/blog/archives/2008/04/13/brown-paper-bag/ For those of you who ran into the bug in Music Applet 2.3.0 where the applet would seem to crash as soon as you started it, well, I finally figured out what was going on. It turns out to be a blatant brown-paper-bag bug, and to proper chastise myself for releasing Music Applet with it, I will now detail what its cause was and how I discovered it.

Since I have Debian’s music-applet package installed, during development I install the new code in a separate directory and run it from there. This leaves the problem of actually loading the applet from its nonstandard location. Normally, when you add an applet to a panel, Bonobo checks its database to see what program needs to be run. However, if the program is already running, it will connect to it instead of starting a new instance. So, when testing new code, I start the new applet code from the command line, and then add it to the panel.

This way, I don’t have to touch the system files to run the new code. This method also gives me an opportunity to augment the Python path with the directory where the new code’s modules are, since naturally they’re in a nonstandard location too. It furthermore has the advantage of printing the output on stdout and stderr to the console, whereas if Bonobo started the applet, they’d wind up in /dev/null, which is bad for debugging.

Now, several people reported the crash-on-startup-if-Amarok-support-is-enabled bug, but I was completely unable to reproduce it on my system. None of them had a stacktrace or core file or any other debugging output to offer. However, they were all using Ubuntu and Python 2.5, whereas Debian still uses Python 2.4 by default. It looked like the trouble might lie there.

After jumping through hoops to get the applet running on my system under Python 2.5 (complicated by the fact that Debian for some reason doesn’t have versions of the DCOP modules for Python 2.5), I still wasn’t able to reproduce the problem. Naturally, if I can’t reproduce the problem, and I can’t get any good details from the bug reports, I can’t figure out what’s causing the bug, let alone verify that any fix I come up with works.

I finally decided to go all-out and try to reproduce the exact circumstances of the crash on my machine, without completely wrecking the copy of the applet provided by Debian. I hacked the Bonobo .server file for the applet to point to the local copy of the applet, and then hacked the applet startup code to explicitly run under Python 2.5. Oddly, when the applet started, it would identify its version of 2.2.1 (the version provided in Debian) and not 2.3.0.bzr (the version installed locally), nor would it have any of the features added in 2.3.0, including the Amarok plugin.

After banging my head on this for a while, I realized that even though Bonobo was running the local copy of the applet’s startup code, that startup code was then loading the support modules installed in the system paths — the 2.2.1 code — instead of the local code. When starting the applet from Bonobo, there’s no opportunity to tweak the include path like you get from the command line. I then further hacked the applet to add the right paths to sys.path, and finally it started working, in that it stopped working and crashed like it was supposed to. Or, not supposed to, but you know what I mean.

Finally, I was getting somewhere. To track down the line causing the crash, I started putting lines like this in the code to trace the control flow:

os.system("xmessage 'About to start thread'")

This would pop up a crude dialog box with the message, which I relied on instead of printing to stdout or stderr since, well, those were going to /dev/null now. After playing around with things for a while, I tracked down the offending line of code:

self.__plugin._app = kdecore.KApplication (sys.argv, "music-applet")

Thinking it might be throwing an exception for some reason, I tried wrapping it in a try/except block, but no luck. That was definitely the line, but still no clue why it was failing so spectacularly. Thinking there might be something on stdout or stderr that could help, I realized I could point them at files on applet startup so I could read them after the fact:

sys.stdout = open ("/home/paul/music-applet/debug.stdout")
sys.stderr = open ("/home/paul/music-applet/debug.stderr")

Now I was seeing the normal debugging spew from the applet, but still no messages about the crash. It then hit me that this was only going to affect my Python code; everything else would still be using the “true” stdout and stderr. I’d have to literally dupe the system into redirecting the underlying file descriptors into writing into my debug files:

new_stdout = open ("/home/paul/music-applet/debug.stdout", "w")
new_stderr = open ("/home/paul/music-applet/debug.stderr", "w")
 
os.dup2(new_stdout.fileno(), sys.stdout.fileno())
os.dup2(new_stderr.fileno(), sys.stderr.fileno())

Aha! Now this showed up in the output right before the crash:

music-applet: Unknown option '--oaf-activate-iid=OAFIID:GNOME_Music_Applet_Factory'.
music-applet: Use --help to get a list of available command line options.

That option is one of the things that Bonobo puts on the command line when it starts an applet, and isn’t one of the things I was giving to the applet when launching it manually. Aha? Checking the source code of the KDE libraries for that error message turned up this:

void
KCmdLineArgs::usage(const QString &error)
{
    assert(KGlobal::_locale);
    QCString localError = error.local8Bit();
    if (localError[error.length()-1] == '\n')
  localError = localError.left(error.length()-1);
    fprintf(stderr, "%s: %s\n", argv[0], localError.data());
 
    QString tmp = i18n("Use --help to get a list of available command line options.");
    localError = tmp.local8Bit();
    fprintf(stderr, "%s: %s\n", argv[0], localError.data());
    exit(254);
}

Aha! The KApplication constructor indirectly calls this when it sees something on the command line it doesn’t understand. It prints a message to stderr, and them immediately exits the program! The applet wasn’t crashing; the KDE libraries were terminating it because they didn’t understand the command-line arguments Bonobo uses!

Here’s where that brown paper bag comes in: this bug would affect anyone relying on Bonobo to start the applet. In other words, everyone who isn’t me. By always starting the applet from the command line first, I never tested the applet in the same runtime configuration that everyone else on the planet would be using, and so never encountered a bug that everyone else would suffer. The whole Python version thing was a red herring.

Now that I finally knew what was happening, the fix was trivial: strip out any command-line arguments before calling the KApplication constructor:

fake_argv = sys.argv[0:1]
self.__plugin._app = kdecore.KApplication (fake_argv, "music-applet")

However, I still maintain that if there is a hell, there is a special place in it reserved for people who write libraries that call exit(), and thus do not give the user of the library an opportunity to try to recover from an error.

Needless to say, this bug is fixed in 2.3.1.

]]>
http://www.kuliniewicz.org/blog/archives/2008/04/13/brown-paper-bag/feed/ 1
Call for help: Music Applet 2.3.0 crasher http://www.kuliniewicz.org/blog/archives/2008/02/13/call-for-help-music-applet-230-crasher/ http://www.kuliniewicz.org/blog/archives/2008/02/13/call-for-help-music-applet-230-crasher/#comments Thu, 14 Feb 2008 04:23:06 +0000 http://www.kuliniewicz.org/blog/archives/2008/02/13/call-for-help-music-applet-230-crasher/ Several users have reported that Music Applet 2.3.0 crashes for them. Unfortunately, I have been unable to reproduce this bug myself, and none of the crash reports I’ve received have contained enough detail to suggest where the problem might lie, other than hinting that it only happens with Python 2.5. Without figuring out more information about the cause of the problem, I have no way to fix it.

If you’re experiencing crashes, you can help by trying to find out what’s causing the crash. Here’s some suggestions on how you might be able to do this:

  • Run the applet from the command line before adding it to the panel, so that error messages will be printed to the console. See the FAQ for details on how to do this.
  • If the applet dumps core, use gdb to get a backtrace, and send that backtrace to me. That should at least identify the line of code where the crash occurs.
  • Try disabling all plugins by default. To do this, before running ./configure, edit the file data/music-applet.schemas.in. Look for the line that says:

    <default>[Amarok,Audacious,Banshee,Exaile,MPD,Muine,Quod Libet,Rhythmbox,VLC,XMMS,XMMS2]</default>

    And replace it with:

    <default>[]</default>

    If the applet no longer crashes on startup, try re-enabling plugins one by one until you find one that causes the crash.

  • Let me know the versions of everything the applet is using: Python, GTK, GNOME, D-Bus (and the Python bindings for it), and the player-specific libraries used by the plugins that (possibly) cause the crash.
  • Let me know exactly what you were doing with the applet when the crash happened (i.e., adding it to the panel, launching a player, clicking one of the buttons, etc.).

Without more information from someone who’s able to reproduce the crash themselves, there’s unfortunately nothing I can do to fix this problem. Thanks in advance to anyone who can help.

]]>
http://www.kuliniewicz.org/blog/archives/2008/02/13/call-for-help-music-applet-230-crasher/feed/ 3
Music Applet 2.3.0 Released http://www.kuliniewicz.org/blog/archives/2008/01/27/music-applet-230-released/ http://www.kuliniewicz.org/blog/archives/2008/01/27/music-applet-230-released/#comments Mon, 28 Jan 2008 03:41:38 +0000 http://www.kuliniewicz.org/blog/archives/2008/01/27/music-applet-230-released/ Music Applet 2.3.0 has been released. In addition to a bunch of bug fixes, this release adds support for Amarok, Audacious, and VLC (0.9.0 or later). It also adds support for getting album art from Rhythmbox (0.11.3 or later), and the frequently requested feature of displaying song information inside the applet itself. Check the release notes for the full details.

]]>
http://www.kuliniewicz.org/blog/archives/2008/01/27/music-applet-230-released/feed/ 11