GNOME Bugzilla – Bug 756992
rhythmbox hangs after handling mod/xm/it (modplug) file when crossfade is enabled
Last modified: 2015-11-02 10:43:43 UTC
After playing a mod/xm/it file (via modplug) in a play list with crossfade enabled, rhythmbox loads and starts playing the next song, but the interface stops responding. Once the song completes, no further songs are played and the program must be killed. Also, switching to the song with next or double-click doesn't work properly and must be repeated. Again, the interface hangs after switching to another track. This is 100% repeatable for me, even with a tiny play list, and does not appear to occur with crossfade disabled.
Can you get a stack trace from it once it's hung?
Created attachment 313896 [details] gdb stack trace, all threads, no debug symbols
I've attached a stack trace. I am installing debug symbols for as many of the libraries as I can, but I'm running Gentoo so it'll take a while to rebuild. Before hanging there is also the following error. I don't know if it's related: Traceback (most recent call last):
+ Trace 235616
return s.next_search()
search.search(self.key, self.last_time, self.store, self.search_done, None)
path = self.filename(album, artist, ext)
album = album.replace('/', '-')
Created attachment 313898 [details] gdb stack trace, all threads
This is happening because modplug isn't a GstAudioDecoder, so it doesn't get the default sink event handling behaviour implemented there, which holds events until there's a buffer being sent downstream. Without that, we end up back in the decodebin pad probe and deadlock. Not really sure what to do about it, though.
commit d1d2f0e works around it. since modplug doesn't provide any useful tag events, it doesn't matter that we don't process them any more.
*** Bug 757463 has been marked as a duplicate of this bug. ***