I have just had this phenomenon happen to me, and I looked in /tmp/xerrs.log. Retrovol has a segmentation fault, with this error:
Invalid unclassed pointer in cast to 'GtkImage'
I'll post a pm to pizzasgood.
Comments:Posted on 3 May 2010, 7:57 by Pizzasgood
Version 0.6 uploaded
I think the bug you're describing might come from restarting Fbpanel. Retrovol had issues if the tray program exited while it was running. Basically, the tray icon is a window, and when the tray exits, the tray icon's window closes. I've now adjusted it to hide the window instead of closing it, and then attempt to reshow the window during the periodic update routine in case a new tray has been launched. Seems to work.
This version also fixes a couple other minor bugs and adds balance support (in the sense that alsamixer does it - instead of directly controlling balance you just change the volume of either the left or right channel, by holding the Shift or Ctrl keys, respectively). It's also a bit more resilient in the event that it becomes a zombie process.
Posted on 3 May 2010, 8:44 by BarryK
No, the crash occurred at first startup of the desktop.
When 'fixmenus' is run, it calls 'pfbpanel' to update the Fbpanel menu and that does restart fbpanel, however the script first kills the tray applets, restarts fbpanel then restarts the tray applets.
Here is the code in /usr/sbin/pfbpanel:
if [ "`pidof fbpanel`" != "" ];then
#hack, need to kill then restart the notification-tray applets...
#now kill and restart the panel...
[ "`which freememapplet_tray`" != "" ] && freememapplet_tray &
[ "`which blinky_tray`" != "" ] && blinky_tray &
if [ "`which retrovol`" != "" ];then
if [ "`retrovol -help 2>&1 | grep '\-show'`" != "" ];then
retrovol & #100119 tray volume control by pizzasgood.
retrovol -hide & #100413 versions after 0.2.
[ -f /root/Startup/traytemp ] && /root/Startup/traytemp &
[ -f /root/Startup/vattery ] && /root/Startup/vattery &
[ -f /root/Startup/powerapplet_tray ] && /root/Startup/powerapplet_tray &
if [ "$2" = start ]; then
Posted on 4 May 2010, 9:01 by Pizzasgood
Maybe it's related to /var/cache/fontconfig. When I boot a fresh iso in qemu, it had the error you mention at first, but then it goes away if I manually run retrovol or restart X or reboot. But if I delete /var/cache/fontconfig, sometimes it comes back. When I killed X, wrote an infinite while loop that ran in the background deleting everything in that directory, and then restarted X with that loop running, retrovol consistently didn't work. The same happened if I powered down, mounted the save file, and removed the directory. So I think maybe there's a race condition somewhere that sometimes results in retrovol attempting to run before the font cache is set up properly if it wasn't already?