GNOME Bugzilla – Bug 609434
Seeking in mp3s doesn't work with gstreamer0.10-ffmpeg
Last modified: 2010-02-12 07:09:26 UTC
It seems like two gstreamer packages support mp3 playback, -ffmpeg and -ugly. With either of these installed, playback works fine, but if -ugly isn't installed it's impossible to seek when an mp3 is playing in Banshee. I see two possible solutions: 1. If this is Banshee's problem, not gstreamer's, then fixing the issue would be the obvious solutions. 2. If this is a limitation of -ffmpeg's mp3 support, then Banshee should prompt the user to install -ugly (as it would have if no mp3 support was found. Bug 591886 comment 27 discovered this problem after that report had been closed. Rather than reopen a report that was already packed with comments, it seemed simpler to file a clean, new bug report.
@Jack, when you didn't have -ugly, were you able to seek in mp3s using other players (Totem, Rhythmbox)? I'm marking this as NEEDINFO, but if you didn't check or don't remember, I'll gladly test it out myself.
@Michael If I remove the -ugly package, Totem displays the same problem as Banshee (no length given for mp3 file) and it says "streaming" at the bottom. So, this is is either a bug with the -ffmpeg package (that is allowing mp3 playback at all) or, if it is the intended behavior of that -ffmpeg package, a problem with Banshee not requiring the -ugly package despite -ffmpeg being installed.
I can second Jack's experience, before installing -ugly I couldn't seek in totem, rhythmbox or banshee, the mp3's played fine but I couldn't seek and in totem and rhythmbox the files showed time unknown. Now, even with -ugly, I had to reimport my music in rhythmbox to be able to seek.
Hopefully there's a gstreamer bug somewhere to take care of that issue, then, but it sounds like there's not much Banshee can do to fix the problem. Banshee devs, would it be appropriate to encourage users to install -ugly even if they already have -ffmpeg? something like a warning that let's users know they won't be getting the full experience with their mp3s unless they install additional/alternative codecs?
(In reply to comment #4) > Hopefully there's a gstreamer bug somewhere to take care of that issue, then, > but it sounds like there's not much Banshee can do to fix the problem. It looks very much like bug 162833.
(In reply to comment #5) > (In reply to comment #4) > > Hopefully there's a gstreamer bug somewhere to take care of that issue, then, > > but it sounds like there's not much Banshee can do to fix the problem. > > It looks very much like bug 162833. Hmm, you're very right, but that bug has been closed for a little over 4 years... strange. Also, from that bug report it looks like seeking is definitely supposed to work with -ffmpeg, so maybe Banshee shouldn't try to work around it. What do you think, Alexander? Is there anything for Banshee to do in the situation? Should we reopen that Gstreamer bug or file a new one?
I found an ubuntu bug report in launchpad related to this: https://bugs.launchpad.net/rhythmbox/+bug/373534 I am not sure if the bug is with the -ffmpeg source or with Ubuntu's package.
(In reply to comment #2) > @Michael If I remove the -ugly package, Totem displays the same problem as > Banshee (no length given for mp3 file) and it says "streaming" at the bottom. > So, this is is either a bug with the -ffmpeg package (that is allowing mp3 > playback at all) or, if it is the intended behavior of that -ffmpeg package, a > problem with Banshee not requiring the -ugly package despite -ffmpeg being > installed. I can reproduce this on Arch. I closing this bug as a dupe of bug 162833 and re-opening that one. *** This bug has been marked as a duplicate of bug 162833 ***