GNOME Bugzilla – Bug 648252
crashes when starting the playback of another track from list (banshee & rhythmbox)
Last modified: 2011-04-26 15:54:37 UTC
If you wait for the first track to play to an end, the second track won't start - the application will crash instead
Created attachment 186320 [details] core dump
Please read this, http://live.gnome.org/Banshee/CommonQuestions/Logs or run banshee --debug from console and paste here the result. cheers
Created attachment 186339 [details] full output of banshee --debug command
The problem seems to be outside of Banshee. Can you try to install all the debug packages for Banshee's dependencies to get a more complete stack trace from the underlying platform?
Created attachment 186549 [details] output of banshee --debug command with debug info for deps
Thank you, does this happen if you disable gapless playback?
(In reply to comment #6) > Thank you, does this happen if you disable gapless playback? Yes - it doesn't make a difference, it also generates identical debug output.
I will pass this one on to someone more clever than I, none of the standard suspects seem to be the cause.
savailonei, can you test with Banshee 2.0 or higher? If for those versions it's still the case, we can raise the importance of the bug.
Yes, it is still the same with version 2.0. I attach debug output, it looks identical to the previous one, though.
Created attachment 186591 [details] banshee 2.0 debug output
Thanks for the additional info? Can you properly play the same 2 tracks from other GStreamer-based players in your system? Please try totem or rhythmbox for instance.
s/info?/info./
(In reply to comment #12) > Thanks for the additional info? > > Can you properly play the same 2 tracks from other GStreamer-based players in > your system? Please try totem or rhythmbox for instance. rhythmbox crashed, I can supply debug output if required
If rhythmbox crashed, then this may be a GStreamer bug or a misconfiguration of your environment. There's nothing Banshee developers can do to fix this, so I'm moving it to GStreamer, hopefully they will be able to tell you what's wrong with your system or if it's a bug on their end.
You're using a system version of ffmpeg instead of the version that was included in gst-ffmpeg. Please try to reproduce this with the included version and please also keep debug symbols for gst-ffmpeg and ffmpeg.
(In reply to comment #16) > You're using a system version of ffmpeg instead of the version that was > included in gst-ffmpeg. Please try to reproduce this with the included version > and please also keep debug symbols for gst-ffmpeg and ffmpeg. I had gstreamer-ffmpeg already installed. I installed gstreamer-plugins-ugly and it solved the problem. I can also seek in files now. I would still consider this a bug tho - I'm not sure if it is gstreamer's bug or media player's that uses it, but the latter crashes.
Sure there's a bug somewhere but unless you can reproduce it with the ffmpeg version that was included in gst-ffmpeg we can't help much.
(In reply to comment #18) > Sure there's a bug somewhere but unless you can reproduce it with the ffmpeg > version that was included in gst-ffmpeg we can't help much. so, how do I switch to gst-ffmpeg version?
The easiest solution would be to recompile gst-ffmpeg from source instead of using your distribution packages.
which version of gst-ffmpeg i should compile?
Best would be 0.10.11. And install it in prefix=/usr
This bug does not occur if I compile and install gst-ffmpeg 0.10.11 from source. It does occur if I install gstreamer-ffmpeg-0.10.11-1 from fedora 14 official repo - notice that version matches.
Also it does not occur if I use fedora's gstreamer-ffmpeg-0.10.11-1 and fedora's gstreamer-plugins-ugly-0.10.16-2 . Fedora's gstreamer-ffmpeg without plugins-ugly crashes.
That's most probably a bug in the Fedora ffmpeg package. Please report this bug there