GNOME Bugzilla – Bug 334753
Rhythmbox crashes when importing folder recursively
Last modified: 2006-03-18 03:13:22 UTC
Distribution: Ubuntu 6.04 (dapper) Package: rhythmbox Severity: critical Version: GNOME2.14.0 0.9.3 Gnome-Distributor: Ubuntu Synopsis: Rhythmbox crashes when importing folder recursively Bugzilla-Product: rhythmbox Bugzilla-Component: Importing Bugzilla-Version: 0.9.3 BugBuddy-GnomeVersion: 2.0 (2.14.0) Description: Description of the crash: Crash when importing folder having subfolders Steps to reproduce the crash: 1. Import folder with some mp3s and subfolders containing more mp3 Expected Results: Ideally it should import folders and subfolders nicely. How often does this happen? Everytime the action is executed Additional Information: Setting the monitor library folder leads to crash on startup. Debugging Information: Backtrace was generated from '/usr/bin/rhythmbox' (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1226615104 (LWP 8330)] [New Thread -1246823504 (LWP 8333)] [New Thread -1238430800 (LWP 8332)] (no debugging symbols found) 0xffffe410 in __kernel_vsyscall ()
+ Trace 66980
Thread 1 (Thread -1226615104 (LWP 8330))
------- Bug created by bug-buddy at 2006-03-16 12:29 -------
This is probably caused by a specific mp3. Can you try and narrow down which mp3 is causing it by importing each subdirectory separately, then import each file separately?
rhythmbox -d can help pinpoint the problematic file more rapidly.
Created attachment 61423 [details] crash log with rhythmbox -d I created softlinks to all the mp3s in a test folder. Ran rhythmbox -d as suggested and got the attached crash.log Another observation - This crash occurs on any other folder without any sub-folders and only mp3s. ( tried with different set of mp3s also ). I have the fluendo mp3 plugin for gstreamer v0.10
This is the same issue (at least on the rhythmbox side of things) as bug 334829 - gstreamer is feeding us weird data. The file that's causing the problem in that particular instance seems to be /media/hda4/chet/new%20stuff/02%20-%20Rang%20De%20Basanti%20-%20Rang%20De%20Basanti%20%5Bwww.alldesimp3.tk%5D.mp3 Can you try running gst-launch-0.10 -t filesrc location=/media/hda4/chet/new%20stuff/02%20-%20Rang%20De%20Basanti%20-%20Rang%20De%20Basanti%20%5Bwww.alldesimp3.tk%5D.mp3 ! decodebin ! fakesink The output should look like this: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FOUND TAG : found by element "id3demux0". title: [WWW.aLLdESImp3.TK] artist: Rang De Basanti [www.alldesimp3.tk] album: Rang De Basanti [www.alldesimp3.tk] date: 2005-01-01 comment: [WWW.aLLdESImp3.TK] track number: 0 copyright: [WWW.aLLdESImp3.TK] genre: Hindi OST [www.alldesimp3.tk] FOUND TAG : found by element "mad0". layer: 3 mode: joint emphasis: none audio codec: MPEG-1 layer 3 bitrate: 128000 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 6569585000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... but I'm guessing that one of the fields will be corrupted.
Good call. Fixing the bad ID3 tag for that mp3 fixed the crash. Guess gstreamer needs bit more error resilence. BTW what line(s) in the crash log indicated the problem ?
The messages immediately before the assertion failure indicated it was the file read after AllahKeBandhe.mp3, and I found the name of the file by searching back for 'successfully read metadata for file'. Since I was able to read the file OK using GStreamer CVS, I think the underlying problem in GStreamer has been fixed, so I'm marking this a duplicate of bug 334167 (I don't know where I got 334829 from..). *** This bug has been marked as a duplicate of 334167 ***