Database FAIL

You know what’s not fun? Having MySQL report that one of the database tables your blog relies on crashed, making WordPress think it wasn’t yet installed, since the “am I installed yet” check relies on that crashed table.

Things should be working again, but if you see any weirdness, let me know.

Call for help: Music Applet 2.3.0 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.

GStreamer audio sinks are picky

If you ever get the urge to write your own GStreamer element, and one of the things your element will output is an audio stream, I have a word of advice that might save you a fair amount of frustration.

All of the typical sink elements that output an audio stream to a sound card (such as alsasink, esdsink, osssink, or even gconfaudiosink, which after all is probably just going to wrap one of the first three) require that your buffer offsets be measured according to the stream time (GST_FORMAT_TIME), and not any other way. It doesn’t matter if the caps you negotiated for your source pad clearly specified the sample size and rate, or even that you’re setting the timestamp for each of your buffers. If your offsets don’t use GST_FORMAT_TIME, it won’t work.

Specifically, you’ll wind up with this critical error message spit out by one of the base classes most of the audio sinks shipped with GStreamer inherit from:

GStreamer-CRITICAL **: gst_segment_clip: assertion `segment->format == format' failed

And that’s because that base class hard-codes GST_FORMAT_TIME as the segment format in its call to gst_segment_clip.

Note that the error message you get doesn’t clearly say that this is the reason it fails, unless you happen to install the debugging symbols for all the GStreamer libraries and plugins, and then go into a debugger to see what’s calling that function (after remembering to set the G_DEBUG environment variable to fatal_criticals so you get a core dump at the site of the problem), and then look up that part of the GStreamer source code to find out about the hard-coded use of GST_FORMAT_TIME.

Now, for those of you who notice what category this was posted under, yes, this means I’ve been tinkering with Wallace again. In particular, I’m completely rewriting how it uses GStreamer to output audio and video streams from the emulator into something useful (i.e., either playing the streams or encoding them to a video file). I’ve come to the conclusion that my old methodology was fundamentally completely wrong, and it’s a wonder I was able to make it work at all, kind of sort of.

This time, I’m having GStreamer drive execution of the emulator itself, instead of handling that on my own and trying to shovel its output into the pipeline, which makes scheduling and timing really really brittle. Now, each time GStreamer thinks the emulator should produce some more output, it will call (through the nesemulator element I’m writing) the emulator more or less directly. This ends up simplifying a good chunk of code, since GStreamer is (naturally) pretty good at figuring out when it needs more output data. At least, GStreamer is going to do a much better job than my abusing g_idle_add and nanosleep.

Also, instead of treating nesemulator as a source element, it will act as a decoder element. So what input stream does it take? Why, a sequence of button inputs, of course! GStreamer’s fakesrc can be coaxed into providing a null input for testing nesemulator quite nicely. Of course, I’ll need to write a new element to poll user input and convert that into the right button presses, but I was going to have to do that in one way or another anyway. Even better, this approach provides a cleaner way to implement playback of FCEU movie files: write another element that decodes a .fcm file into the corresponding input sequence, and stream that into the nesemulator element.

In fact, this approach can also be used to write an NSF decoder element, by wrapping the nesemulator element, discarding its video output, and controlling selection of which song to play. If you were ever longing to listen to 8-bit music in Rhythmbox, that’d let you do it.

For the moment, though, I just have a rough but functional implementation of nesemulator, which lets you do simple stuff like this:

gst-launch-0.10 fakesrc sizetype=2 sizemin=4 sizemax=4 filltype=2 ! nesemulator name=emu location=Mega\ Man\ 2\ \(U\).nes emu.video_src ! queue ! ffmpegcolorspace ! xvimagesink emu.audio_src ! queue ! audioconvert ! alsasink

You know, in case you get the urge to watch the intro to one of the greatest video games of all time.