Summary: | seeker bar jumps to beginning while seeking "tinystepwise" ;-) | ||
---|---|---|---|
Product: | [Applications] amarok | Reporter: | Dario Nuevo <dn> |
Component: | general | Assignee: | Amarok Developers <amarok-bugs-dist> |
Status: | RESOLVED NOT A BUG | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | 1.2.2 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Dario Nuevo
2005-03-19 12:27:16 UTC
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 |