Version: 1.2.2 (using KDE 3.3.2, Gentoo) Compiler: gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1) OS: Linux (i686) release 2.6.10-gentoo-r6 what happens ---------------- i often have long full mixes tracks (about 70-80 minutes) and then i seek the file with tiny little steps (in the seeker bar), which are some minutes within the file. while seeking, the bar bounces back to the beginning of the seeking area, and then corrects itself to the correct position. a tiny bug, but it really disturbs if you notice it often expected behaviour --------------------- the slider should be stable.. meaning: where i drop it, there it should stay and not bounce around.. if it cannot be corrected, it should at least be animated or something ;-)) then it may not be interpreted as a bug, it would be a feature ;-) how to reproduce ---------------- - be sure to be in the jukebox mode (i never tried it with the additional player window, not checked that) - begin to play a track (i think it should be at least 5 mins of length) - now, begin to play with the seek bar, go ahead with tiny step towards the end of the track.. really tiny steps to hear it through.. always grab the bar and release it "some pixels later" ;-) --> the seek bar sometimes goes to the beginning of the track and jumps back to the original state -> why is it going to the beginning? fyi: also here, i compiled amarok directly from source, --enable-mysql & --without-arts..
I just reproduced this (using xine). Another fun thing to do is use the mouse wheel on the slider.
i just want to notice that the bug is till present in the 1.3-beta1. and it seems that the bug behaviour is heavily engine dependent. using the gstream-engine, the slider never slides back to the very beginning, instead it slides back to the previous slider position.. using xine, the slider jumps back to the very beginning of the slider if it jumps.. it seems to me (without looking at the code), that the slider is influenced directly by engine properties. maybe the slider should have engine-independent logic (which may lead to an asyncron slider, don't know). the bug is really annoying but seems to be hard to fix.. ;-)
I looked into it some weeks ago. xine-lib would just return 0 as the current position in these situations, so it's a bug in xine-lib IMO. I've seen in some other application CVS (IIRC it was kaffeine) people trying to workaround this in different ways, when I get the time I'll look for those again.
This bug also causes a nasty side effect if you send amarok.player.seekRelative(1) DCOP commands too fast: If a new seekRelative command arrives while the slider is at the beginning, the result will be that amarok seeks to the very beginning of the song. This makes fast seeking with keyboard commands practically impossible.
I use the mediacontrol applet and it's slider behave in the same way. I would like to be able to use the scroll wheel on it but the song keeps reseting to the beginning. I can only reproduce with xine.
Closing, because this is a bug in xine-lib, not amaroK. Also, it's possibly fixed in recent xine-lib versions.
This bug hasn't been reported at xine's bug tracker and I can't describe it there with satisfactory sophistication. I think somebody should report it there, so that work on it gets initiated. It doesn't seem to have been reported there. Also, shouldn't the resolution be WONTFIX instead of INVALID?
Still present in Amarok 1.4 beta 2 with libxine 1.1.1-1 in debian sid. Can't find any mention of it in the xine bugtracker.
the bug in libxine is still there at the time v1.4.4 is released.. strange