Version: 1.2 (using KDE KDE 3.3.0)
Installed from: Gentoo Packages
When I change to a different song, CPU usage goes to 100% for approx. a second, and the currently playing song will momentarily stop. It will then continue playing whilst fading out and moving to the next song.
It was suggested in IRC that the problem may be this: http://amarok.kde.org/wiki/index.php/FAQ#Why_is_there_always_a_gap_although_I_have_crossfading_enabled.3F, but I don't have that plugin installed. Someone else in IRC said they were experiencing the same problem on a Debian box.
I have this problem as well, and also, do not have the gst-ffmpeg plugin installed. I would love to have this problem resolved as the program is awesome otherwise.
Additional info: using amaroK (and KDE) from CVS_HEAD with GStreamer. Athlon 1.4GHz system with 768MB RAM.
I've been investigating today, and this bug seems to be GST related, as it doesn't happen when using aRts.
Downgrading GStreamer to 0.8.7 and gst-plugins 0.8.4 fixed it for me, actually.
Hmmm, interesting. I'm using xine for the moment. Can any devs shed some light on this? Should this be reported to the GStreamer project?
I recently realised that I was using software from the testing tree, so I've downgraded and also no longer experience the problem.
So it would seem that the bug is with GST 0.8.9 and/or GST-plugins 0.8.7. Are you on Gentoo too? If so then maybe it's a problem with the packages as opposed to GST itself.
I'll resolve this for now, and reopen it if you were using packages that are outside of testing for your distro.
I'm now using Amarok 1.2.1 which requires GST-plugins 0.8.7 and GST 0.8.9. Now the problem is back again. Should I report this to the GStreamer project?
I've got the same problem in debian sarge.
Compiled the 1.2.1 by myself with the gstreamer-plugins of debian sarge:
CVS commit by markey:
M +2 -2 ChangeLog 1.537
--- kdeextragear-1/amarok/ChangeLog #1.536:1.537
@@ -7,6 +7,6 @@
FIX: GStreamer-engine can now play vorbis radio streams properly, with
full metadata support. (BR 89821)
- FIX: GStreamer-engine now uses the modern "decodebin" autoplugger, which
- fixes the lag issues that some users had during crossfading.
+ FIX: GStreamer-engine now uses the "decodebin" autoplugger, which fixes
+ the lag issues that some users had during crossfading. (BR 99570)
Should be fixed in CVS HEAD. Please test.
Tested, works for me. Thanks a lot :D.
This seems to have re-appeared in CVS, to an extent. Maybe it was still kind of there all along.
Basically, crossfading is generally smooth(ish) between songs, but if you are cycling through multiple tracks then it starts to get very laggy. Is there anything that can be done?
I'm re-opening this because it's quite bad. Literally _every song change_ stutters. Also, the first second or two of a song will play quietly, then it will play at normal volume.
Is this bug like this one (http://bugs.kde.org/show_bug.cgi?id=102708).
The last comment makes it sound very much like that.
Yes, it is *exactly* like that one, but I also get some stuttering. I don't know if the two are related, so let's leave them both open and see if the developers are able to give us any more information.
I also have this problem. See the following for some details: http://bugs.kde.org/show_bug.cgi?id=102708#c5
As said in BR #96680, it seems we had five bugs for two problems, so let's try to make the bug database sane.
This bug seems to be a mix of #96680 and #102708, so please, add your specific comments to one of those bugs.
*** This bug has been marked as a duplicate of 102708 ***