I've found the source of this problem. I was going to path it, but then I had a closer look and decided not to. The problem is in debian/patches/19_all_play_audiocd, and it is easily patched with the information I will provide in this mail. However, you shouldn't do it.
The proper solution is to delete debian/patches/19_all_play_audiocd. 19_all_play_audiocd is a complete WTF, and should never have been applied. I'll give you the short summary first, and the long and boring one afterwards: * The UI is completely wrong * The code is buggy (obviously) * It provides basically no new functionality and only creates extra work for the maintainer Long description: The patch includes the tab "CD Audio" in Preferences. This looks like a pretty wierd place to put it if you ask me, I would expect this setting to be in the settings of the input plugin. And wait a second, it is! Actually, for the "Play -> AudioCD" menu item to work, both the directories must be set to the same thing! This is of course completely horrible from a usability point of view. The "Play -> CD Audio" menu item itself is also from the patch, and is in fact the only real functionality it provides. This menu button does the same thing as pressing "Play -> Play Directory" and selecting the directory would do. This only serves to make people think there's something different with audio CDs. There isn't, they work just as normal directories. The menu item is only creating confusion. Okay, over to the code. In xmms/prefswin.c there is a function prefswin_audiocd_browse_cb (added by 19_all_play_audiocd). I'll quote it here with numbered lines: 1 static gint prefswin_audiocd_browse_cb(GtkWidget * w, gpointer data) 2 { 3 GtkWidget *prefswin_audiocd_browser; 4 prefswin_audiocd_browser = xmms_create_dir_browser(_("Select directory to add:"), gtk_entry_get_text(GTK_ENTRY(prefswin_audiocd_cddadirectory)), GTK_SELECTION_SINGLE, prefswin_audiocd_browse_handler); 5 gtk_signal_connect(GTK_OBJECT(prefswin_audiocd_browser), "destroy", GTK_SIGNAL_FUNC(gtk_widget_destroyed), &prefswin_audiocd_browser); 6 gtk_window_set_transient_for(GTK_WINDOW(prefswin_audiocd_browser), GTK_WINDOW(prefswin)); 7 gtk_widget_show(prefswin_audiocd_browser); 8 return (TRUE); 9 } Notice that *prefswin_audiocd_browser declared in line 3 is local to the function. When I removed the gtk_signal_connect in line 5, everything seems to work fine. I found no good docs for GTK 1.x on this, but it's probably about the same in 2.x I hope. According to http://developer.gimp.org/api/2.0/gtk/GtkWidget.html#gtk-widget-destroyed "gtk_widget_destroyed sets *widget_pointer to NULL if widget_pointer != NULL. [...] Useful for example to avoid multiple copies of the same dialog." Looking around the source, it seems gtk_widget_destroyed is used mostly on global variables, which makes sense for detecting if the window is already open and just stashed away somewhere. Currently you can open an infinite amount of identical windows from the Browse button. The solution to this is declaring *prefswin_audiocd_browser outside the function, and wrapping the entire function body in an if (!prefswin_audiocd_browser) { /* body */ }. This is how it is done in all other windows in XMMS using xmms_create_dir_browser. As a sidenote, returning int from this function is also wierd. All other *_cb functions return void, but this one returns TRUE unconditionally. I don't know why, but suspect incompetence. The maintainer hell part is pretty obvious. Today there are 29 patches in debian/patches, quite a few of then weird stuff nobody asked for. Take for instance 12_all_sortbytime, which sorts the playlist after the length of the tracks. Who on earth would want that? Next time the package is updated from upstream, most of these patches will fail. The poor maintainer will have to apply almost every patch manually. My guess is that it will not be very fun. The effect in the long run will probably be that it will not be very tempting to update the source from upstream, in practise creating a fork. That being said, removing the patch now will probably force you to re-apply patch 20 to 51 manually. It might be a good idea to just update the entire thing from CVS first, since that will be about the same amount of work and will probably fix a few other bugs as well. For instance I hear rumors on IRC about an accidentally shuffled enum in the CVS snapshot used in the current package. It will also add functionality I'm waiting for ;o) -- Knut Auvor Grythe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]