GNOME Bugzilla – Bug 658579
Banshee crashes during BPM detection on an ogg file
Last modified: 2011-09-26 19:39:48 UTC
Created attachment 196007 [details] Banshee log after the crash When certain changes (undetermined yet) in the files contained in the Music folder are made by any external application (e.g. EasyTag). Banshee crashes a little time after start up (about 6 seconds). Step to reproduce (After finding a misspelled Album name): 1. Open EasyTag and browse the misspelled album. Do the necessary refactoring on the files: - The file format was OGG in all 13 files - The Album name change was: "40 dibujos ahi en el piso" >> "40 dibujos ahí en el piso" (notice the 'i' changed to 'í') - The folder name changes from the wrong misspelled name to the correct one. 2. Open Banshee. Works normal. 3. Do a Music folder re-scan. Still normal. 4. Close Banshee. 5. Reopen Banshee. Crash after 3 to 7 seconds. Every subsequent start of Banshee will have the same result. Running banshee in the terminal had some output related to the crash (A gdb backtrace and some messages). I'm attaching the banshee.log file (gathered as described in http://banshee.fm/contribute/file-bugs/) and the terminal output in separate files. OS: ArchLinux (linux-gnu, x86_64) (Rolling release, updated @ 2011-05-23 14:25:58 UTC)
Created attachment 196008 [details] Banshee terminal output when crash
Wrong update date in OS: is updated today 2011-09-08
Some further notes: When modified files are added when Banshee is running, the automatic music watcher (don't know the exact translation, is "Observador de colección" in Spanish) triggers normally and files are added, the can be reproduced, no crash. The Metadata repairer plugin can be activated or not, doesn't change the result. The PPM detector is most likely to cause the crash. It makes Banshee crash after a second or so after it is activated. (My guess is it fails to detect OGG Vorvis files PPM, but shouldn't crash). But doesn't crash when the files are first added. The option "write metadata in files" (Spanish: "Escribir metadatos en los archivos") in Preferences, has no effect on the crash, even in conjunction with the "music watcher" and "metadata repairer" plugins.
Thanks you for your bug report. The fact that libgstsoundtouch appears in the stacktrace does point towards BPM detection as being the cause of the crash, as it's the name of the GStreamer plugin used to analyze the tracks' BPM. So the problem is probably in the GStreamer plugin or in the SoundTouch library itself. To confirm that, the first step would be to find out which file(s) exactly cause the problem, and then try to reproduce it by doing the BPM detection directly with GStreamer. For that, you can use the following command from a terminal : gst-launch-0.10 -m filesrc location=/path/to/file.ogg ! decodebin2 ! audioconvert ! bpmdetect ! fakesink
Ok, if failed with the first file I tested: $ export LC_ALL=C $ gst-launch-0.10 -m filesrc location=~/Música/Divididos/40\ dibujos\ ahí\ en\ el\ piso/Divididos\ -\ 01\ -\ Camaron\ bombay.ogg ! decodebin2 ! audioconvert ! bpmdetect ! fakesink I'm attaching the output.
Created attachment 196026 [details] GStreamer BPM detection fail output
Thank you for the information. I'm forwarding this issue to the GStreamer guys, they'll probably be able to figure out whether the problem is with the bpmdetect plugin or SoundTouch itself.
I vaguely remember issues relating to out of sync libsoundtouch and the gstreamer plugin. Can you try rebuilding the plugin with the current libsoundtouch you have, and see if that crash persists ?
Thanks for taking the time to report this bug. This bug report isn't very useful because it doesn't describe the bug well. If you have time and can still reproduce the bug, please read http://bugzilla.gnome.org/bug-HOWTO.html and add a description of how to reproduce this bug. You'll also need to add a stack trace; please see http://live.gnome.org/GettingTraces for more information about how to do so. Thanks in advance!
Created attachment 196153 [details] GStreamer BPM detection fail trace Here is the trace I managed to generate. There is a part missing, after struggling for almost 3 hours to compile gstreamer0.10-bad (both from git and ArchLinux stock package ver 0.10.22-1). It fails to compile (both with and without debug symbols). There is some error in make I can't find, maybe you can give me a hint on finding documentation? I've run under gdb: (gdb) exec gst-launch-0.10 (gdb) run -m filesrc location=~/Música/Divididos/40\ dibujos\ ahí\ en\ el\ piso/Divididos\ -\ 01\ -\ Camaron\ bombay.ogg ! decodebin2 ! audioconvert ! bpmdetect ! fakesink To reproduce the error in comment#5 I built every package that appears in the (more) incomplete backtrace except gstreamer0.10-bad* Tried both builds of all gstreamer and soundtouch packages (stock and git) and always had the same issue when running the above command. Hope this helps, if not please let me know if I can do more.
Sadly, it's likely gst-pluginsbad you need to build, as this is where the bpmdetect plugin lives. How does it fail to compile ? Like, attach make output ?
Ok... Building again with '-d' option attached to 'make' The makedepends (In case some library is missing) makedepends=('pkgconfig' 'gstreamer0.10-base>=0.10.34' 'xvidcore' 'libdca' 'bzip2' 'libdc1394' 'neon' 'faac' 'musicbrainz' 'faad2' 'libmms' 'libcdaudio' 'libmpcdec' 'mjpegtools' 'libdvdnav' 'libmodplug' 'jasper' 'liblrdf' 'libofa' 'soundtouch' 'libvdpau' 'schroedinger' 'libass' 'libvpx' 'gsm' 'libgme' 'rtmpdump' 'libsndfile' 'librsvg') Here is the steps I followed (basically the build function of the PKGBUILD): cd "${srcdir}/gst-plugins-bad-${pkgver}" ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var \ --disable-static --enable-experimental \ --with-package-name="GStreamer Bad Plugins (Archlinux)" \ --with-package-origin="http://www.archlinux.org/" || return 1 make -d || return 1 sed -e 's/gst sys ext/gst/' -i Makefile Fails in make. The output is huge. I'll try to attach it but the last 15 lines are: Reaping winning child 0x1ea8a30 PID 16748 Removing child 0x1ea8a30 PID 16748 from chain. Considering target file `all'. File `all' was considered already. make[3]: Leaving directory `/home/joaquin/abs/gstreamer0.10-bad/src/gst-plugins-bad-0.10.22/ext/cog' Reaping winning child 0x1738e40 PID 16688 Removing child 0x1738e40 PID 16688 from chain. make[2]: Leaving directory `/home/joaquin/abs/gstreamer0.10-bad/src/gst-plugins-bad-0.10.22/ext' Reaping losing child 0x239f710 PID 6179 make[1]: *** [all-recursive] Error 1 Removing child 0x239f710 PID 6179 from chain. make[1]: Leaving directory `/home/joaquin/abs/gstreamer0.10-bad/src/gst-plugins-bad-0.10.22' Reaping losing child 0xf48d00 PID 6177 make: *** [all] Error 2 Removing child 0xf48d00 PID 6177 from chain.
The output of make is 160Mib so, no go for attachment
I don't think we need the full output that make generates with the -d option. All we need is the (input and) output of ./configure and make V=1. Please don't do anything weird or mess with the Makefiles, just run ./autogen.sh or ./configure (with options if needed) and then 'make'.
or make -j1 V=1 even to make the failure log easier to read.
Can't believe it... The bug was in a included file. Now Banshee works with BPM enabled. This bug is a packaging issue for ArchLinux. Sorry I've bothered you with an invalid report...
The solution: package "raptor" (libldrf dependency) changed the includes files location. moved: /usr/include/raptor.h > /usr/include/raptor2/raptor.h /usr/include/raptor2.h > /usr/include/raptor2/raptor2.h Fixed by symlinking. Not sure if it is a libldrf issue or raptor or just packaging. I'm reporting this in ArchLinux Bugtracker. But surely is not gstreamer bug.
*** Bug 660069 has been marked as a duplicate of this bug. ***