Version: 3.2.2 (using 4.2.2 (KDE 4.2.2), Debian packages) Compiler: cc OS: Linux (x86_64) release 2.6.26-1-amd64 Steps to reproduce : 1: Launch Juk 2: Play tracks with it 3: Stop (do not pause, really stop) 4: Restart playing => No sound (the progress bar works) To have sound again, go to the next track (notice that the fade out of the previously muted song works so you hear it fade although it was not played)
Hmh, strange one. I've a different behaviour in trunk, but can confirm this for 3.2.2 (kde 4.2.2). In trunk it's slightly different (player stops at all and you can't start playing again). Yet another task, should be fixed when looking at #165786
It happened with 4.2.2 here, but I can't reproduce either behaviour with trunk. Can you confirm if this is still valid?
I can confirm this running 4.2.3. I can confirm this running trunk of JuK, running QT 4.5.1, phonon 4.3.1 and the rest of kde 4.2.3. I didn't recompile / install the whole kde trunk, but the problem could be located everywhere. After stopping, 105 waekups/s is quite enough to take a look at it. 15.5% (105.0) juk : schedule_hrtimeout_range (hrtimer_wakeup)
Oh, and I'd prefer if it solved itself, since I quite failed finding what causes this last week. My first thought was about phonon mediaobjects not being stopped correctly, but that one is clean. I'd need to trace what causes all this wakeups, but have no idea how to do so.
Damn, wrong bug ... i was wrong in this case. Yes, this one seems to be fixed.
Heh, OK. I'll close it as FIXED.
Could this bug pls. be reopened? I'm seeing it with JuK 3.2.3, Kde 4.2.4, Qt 4.5.1, phonon 4.3.1. The first song of the album or playlist does not play in 75% of the cases, and the "fix" is to select Next, then Previous.