GNOME Bugzilla – Bug 591886
Seek bar does not work in Banshee 1.6 Beta 2
Last modified: 2010-02-09 16:01:05 UTC
Please describe the problem: The song position is always at the left and positioning in a song is not possible. Same behavior with popup seek bar (t button). It worked in Beta 1. Version 1.6 Beta 2 from Launchpad PPA Ubuntu Jaunty Steps to reproduce: 1. play any song 2. 3. Actual results: The song position is always at the left and positioning in a song is not possible. Expected results: position should be shown and positioning should be possible Does this happen every time? yes Other information:
I wasn't able to reproduce this. There were some changes to the seek bar recently, to fix some bugs (bug 539395 and bug 591016), but I don't see how these could have broken it. Does this happen with local files (not streaming) ? Please start banshee from a terminal with "banshee --debug" and post the output here. It might give some useful information.
Created attachment 140869 [details] crash report from first notebook
Created attachment 140870 [details] debug report, netbook
Created attachment 140871 [details] because of a bugzilla bug I was not able to commit a comment -see here!
Hi, I found out: Now every banshee version does not work anymore. I reinstalled banshee, the mono-runtime and dependencies. No change. So it could be only a problem of my installation. Maybe a former installed self-compiled banshee-1 1.6 beta 1 deb caused this. But at that time everything worked perfektly in banshee (from ppa) and self-compiled banshee-1. The problem appeared after new PPA version was installed. Now I reinstalled my self-compiled and both versions work! My self-compiled banshee-1 is a deb which installs everything in /usr/lib/banshee-1. This is the same as the PPA banshee uses. So probably some files are overwritten and added and it works. My self-compiled version is 20MByte big.
I'm experiencing the same issue but only with FLACs. MP3s are seekable whereas trying to seek a FLAC file causes the playback to stop completely. Clicking pause and play has no effect. Running this on Ubuntu Karmic with: banshee 1.5.1-1 (Banshee 1.6 Beta 2 (1.5.1)) mono 2.4.2.3+dfsg-2 While writing this, the music suddenly started playing at the correct position - after a delay of several minutes! Let me know if there's any more information I can provide.
Created attachment 146380 [details] Output of banshee --debug
My bug disappeared since I used Ubuntu Karmic with same files and Banshee version. Seems that it only appears under certain circumstances, e.g. version of Mono, GTK,... @Johannes: I do not know exactly your situation. But some files do not allow seeking. Did you try other mediaplayers like Rhythmbox?
I just tried playing the exact same file in Rhythmbox and Banshee. Seeking in Rhythmbox is working fine. Seeking in Banshee causes the playback to stop for some minutes before continuing at the new location. I can provide any of these FLACs if you want to test for yourself.
Unfortunately I'm not a developer of Banshee. But if you do not get response from them, you should file a new bug. This here has been cold for a while.
Information requested in comment #1 has been provided. I am thus reopening. Dear reporters, please provide the files that are needed to reproduce the problem (i,e. FLAC files) by uploading them here to bugzilla. Thanks in advance.
I was unable to upload the FLAC to bugzilla because of file size restrictions, but it's available here: http://folk.ntnu.no/johannj/billyholiday-YourMothersSonInLaw.flac The file is unseekable in Banshee 1.6 Beta 2 (1.5.1) on Karmic. It was converted to FLAC from MP3 using SoundConverter 1.4.4.
Johannes: It is a known issue that seeking in flac files is broken. See Bug 587643. Steffen: I looked through your --debug log and the problem might be related to gstreamer and asf/wma files. It looks like the file you were trying to seek in was a .wma file, and gstreamer didn't have the right codec to calculate the bpm (but it could still play the file?). Without knowing the bpm, it would make sense that Banshee couldn't let you seek. When you upgraded to Karmic, gstreamer was also updated. Apparently, gstreamer now has what it needs to determine the bpm and let you seek in the file. This may have been out of Banshee's scope from the beginning. Just to make sure, it would be helpful if you would run banshee with --debug again and try to play the song (home/steffen/Dokumente/Sprache/Spaninsch/Kurs CD 1/01. Track(48).wma) now. I'm wondering if there are still any gstreamer messages in the log. Thanks!
Johannes: FLAC seeking is bug 587643.
I assume this is a duplicate of bug 587643 then?
See my Comment 13. Steffen's issue wasn't related to flac files, but it was instead a gstreamer issue related to windows media / asf decoding in gstreamer. It might be out of Banshee's scope to handle this better, though. Also, I'm marking this back to NEEDINFO per my last comment. I had changed it to that, but I think it got cancelled out since so many of us were commenting here at the same time.
*** Bug 609008 has been marked as a duplicate of this bug. ***
I have the same problem on 1.5.3 from the PPA and on git-master. I am using ubuntu 9.10. The seekbar does not move from the far left at any point during playback (on all my files including ordinary mp3 files). It is the same for the seekbar on the gnome panel notification area popup. When running banshee --debug and playing a file nothing interesting seems to be reported: [Debug 19:05:06.738] Player state change: Idle -> Loading [Debug 19:05:06.964] Player state change: Loading -> Loaded [Debug 19:05:06.999] Player state change: Loaded -> Playing [Debug 19:05:07.115] Creating Pango.Layout, configuring Cairo.Context [Debug 19:05:07.115] Creating Pango.Layout, configuring Cairo.Context [Debug 19:05:08.005] TrackInfoDisplay RenderAnimation: 18.00 FPS [Debug 19:05:30.642] Player state change: Playing -> Paused Any other info I can provide?
There seem to be several different things going on in this report. Steffen's problem [fixed?]: Probably a gstreamer issue specifically related to wma/asf audio. Updating to a new version of gstreamer seemed to fix the problem. Johannes' problem [duplicate]: Specific to flac files, making it a duplicate of bug 587643. Jack's problem [mystery]: Related to mp3 files and Banshee 1.5.3 on Ubuntu 9.10. Unfortunately, I'm also using mp3 files with 1.5.3 on Ubuntu 9.10, so there must be something else to it. Jack, did you use version of Banshee prior to 1.5.3? If so, is 1.5.3 the first version where you encountered this problem? Does the problem happen with all tracks or only specific files? If it only happens with specific files, is Banshee able to (correctly) calculate the track length for those files? If Banshee doesn't know how long a song is, it can't allow seeking. Do you have files that aren't mp3 (or flac) in your library? Does this issue also happen with ogg files?
I have used Banshee for a long time. It definitely worked at some point in the past... but, I don't remember when. I just noticed it today. (Happens in both 1.5.3 PPA and git master) It happens for every mp3 file in my library. The seekbar does work fine for .ogg files though. I don't have any .wma files to test. It happens both on my laptop and netbook (both running karmic) - both have banshee ppa installed. Think the PPA broke something that also affects the git master?
My problem with the seekbar was fixed in a unstable build. I do not think this issue was related to wma/asf-audio because I only use mp3, ogg and m4p audio files.
So, sounds like I have caught Steffen's bug since it was also mp3s. It probably wasn't fixed in an unstable build - but was fixed by something in your environment or libraries maybe? The question is what...
(In reply to comment #21) > My problem with the seekbar was fixed in a unstable build. I do not think this > issue was related to wma/asf-audio because I only use mp3, ogg and m4p audio > files. Steffen, from your comment 3: > [Debug 01:37:41.036] GStreamer running beat detection on > /home/steffen/Dokumente/Sprache/Spaninsch/Kurs CD 1/01. Track(48).wma > bpm_detect got error: A Advanced Streaming Format (ASF) demuxer plugin > is required to play this stream, but not installed. from the log, it looks like you have at least one .wma file in your library, and gstreamer definitely wasn't handling that file well. There could have been other - mp3-related - errors that weren't showing up in the log though, similar to Jack's issue. And from your comment 8: > My bug disappeared since I used Ubuntu Karmic with same files > and Banshee version. You said that updating to Karmic (and as a result, updating your gstreamer packages) fixed your problem, and that you were using the same version of Banshee. This would explain everything if the issue was gstreamer-related. Either way, there is definitely some problem here. Since you're both (all three of us, if you include me) using Ubuntu 9.10, you (we) should all have the same version of gstreamer and related plugins, unless we're getting updates them from different repositories. Could you all report your versions as they're listed in Synaptic? For me: package: version: libgstreamer0.10-0 0.10.25-2 gstreamer0.10-plugins-base 0.10.25-2 gstreamer0.10-plugins-good 0.10.16-1 gstreamer0.10-plugins-bad 0.10.14-4 gstreamer0.10-plugins-ugly 0.10.12-1 I think that should be most of the important ones. With that combination and Banshee from git master, I'm not experiencing any problems with mp3s. If gstreamer isn't the problem, then I'm pretty much out of ideas - especially with nothing interesting in the --debug log. Developers? ideas?
We had all the same gstreamer files... but, I was missing the "ugly" package. Once, I installed it, the bug went away! Thanks! I guess this package should be made a dependency for Banshee to work properly?
Awesome! I thought -ugly was supposed to be required even to play mp3 files; that's interesting that you were able to play them without the plugin. Generally, I also think that Banshee is supposed to offer to install the package for you if you try to play an mp3 without it. Why Banshee didn't offer to install mp3 support, and why your mp3s worked (to a degree) without it is still a mystery, but the core of this issue seems to be taken care of for everyone now, so I'm going to mark it as FIXED. If I'm leaving someone out, feel free to re-open this. Jack, if you feel like pursuing the issue of Banshee not offering to install gstreamer0.10-plugins-ugly for you, you might want to do some searching through Bugzilla, or ask about it on the mailing list (or in IRC).
@Michael: Maybe there was a WMA file in my libary but this bug appeared with a podcast in mp3 or ogg. As mentioned I also compiled a lot and have actually a few PPAs installed. bluez-gstreamer 4.51-0ubuntu2 gstreamer-tools 0.10.25-2 gstreamer0.10-alsa 0.10.25-2ubuntu1.2 gstreamer0.10-ffmpeg 0.10.9-2~ppa9.10+1 gstreamer0.10-nice 0.0.10-1~ppa9.10+1 gstreamer0.10-pitfdll 0.9.1.1+cvs20080215-1ubuntu1 gstreamer0.10-plugins-bad 0.10.14-4ubuntu1 gstreamer0.10-plugins-bad-multiverse 0.10.13-0ubuntu1 gstreamer0.10-plugins-base 0.10.25-2ubuntu1.2 gstreamer0.10-plugins-base-apps 0.10.25-2ubuntu1.2 gstreamer0.10-plugins-good 0.10.16-1ubuntu3 gstreamer0.10-plugins-ugly 0.10.12-1 gstreamer0.10-plugins-ugly-multiverse 0.10.12-0ubuntu1 gstreamer0.10-pulseaudio 0.10.16-1ubuntu3 gstreamer0.10-tools 0.10.25-2 gstreamer0.10-x 0.10.25-2ubuntu1.2 libgstreamer-plugins-base0.10-0 0.10.25-2ubuntu1.2 libgstreamer0.10-0 0.10.25-2
Martin - I found out that I am able to play the MP3s (without ugly and with seekbar not working) through the package gstreamer0.10-ffmpeg. If I remove this package, then I cannot play the mp3s at all and I am prompted by Banshee to 'search for codecs' as you suggested. During the search it offers me the gstreamer0.10-ffmpeg gstreamer0.10-fluendo-mp3 and gstreamer0.10-plugins-ugly to install. So the problem seems to be that Banshee *thinks* it is ok with gstreamer0.10-ffmpeg, mp3s will play but the seekbar doesn't work without ugly. What do you think about this? Is it possible for Banshee to be smarter? Is there just a bug in the gstreamer-ffmpeg package and it should be able to do seekbar?
Jack, to keep things a little more organized (and because this report is already getting pretty long), I decided to open a new report, Bug 609434, in light of your new findings. I already asked a question that you might be able to answer there, if you care to keep helping with the debugging.