Version: 2.3.0.90 (using 4.4.3 (KDE 4.4.3), Debian packages) Compiler: cc OS: Linux (i686) release 2.6.33-3.slh.7-sidux-686 There seems to be no way to proceed in the current played track to another position: you cannot click somewhere in the track progress bar to jump forward or backward and you cannot drag the progress slider to another position. As there also are no fast-forward or rewind buttons (I'd prefer the first two options because they are more precise) you must here the track until the position comes you are interested in. Unlucky too, when you want to quickly preview tracks or compare tracks.
Seeking works fine here in git master. What Phonon engine are you using? Have you tried others?
...and what kind of media? (streams are usually not searchable)
@Comment#2: Local mp3 files, no streams. Engine is Gstreamer, because xine engine since ever cannot handle wav files correctly and therefore is no option for the whole system. When I mouse over the handle in the progress bar it is highlighted and shows a tooltip "jump to <current position>". But it is not possible to drag it to any other position. Hmm. It does work with xine backend... So it's obviously a bug in the gstreamer part...
Reprodusible on OpenSolaris, amarok 2.3.1, gstreamer backend.
see comment #3. this is (likely) either a bug in phonon-gstreamer or gstreamer itself. personally i suggest to use phonon-vlc (if your distro already provides it or you compile yourself), as - xine seems to be "undermaintained" (and has a remaining flac bug?!) and - gstreamer -aside this bug- has (here) serious sound and performance issues (and from trying songbird: that's not phonon relatd) :-(
Setup: Amarok 2.3.2 KDE 4.4.5 Test Result: Everything works properly here.
Reassigning, this should have been done already.
Seeking works fine on Phonon git. Could you please send me a test file by mail or try yourself with Phonon and Phonon-GStreamer from Git. Thanks.
*** Bug 262331 has been marked as a duplicate of this bug. ***
*** Bug 263053 has been marked as a duplicate of this bug. ***
*** Bug 266658 has been marked as a duplicate of this bug. ***
reassigning to the new bugzilla product for better bug tracing of the various backends. Sorry for the noise.
Experiencing the same behaviour here under Kubuntu 11.04, KDE 4.6.2, Amarok 2.4.0, Phonon Gstreamer backend 4.5.0. Sporadically, some files lose the fast forward / rewind scrubber control on the track progression bar in Amaraok. When this happens, it is impossible to change position with the track. This is not consistent - some tracks the scrubber control seems to work normally while others never work (at least during my testing). Some however seem to get the scrubber back if the it was present for the previous track though I have not been able to reliably reproduce this. I have only tried this on MP3s so far, not sure whether this affects other file formats. Did not happen until I upgraded to 4.6 (via Natty). I have tried running Amarok in debug mode but so far have not noticed anything different between when tracks work properly and when the scrubber goes AWOL.
(In reply to comment #13) > This is not consistent - some tracks the scrubber control seems to work > normally while others never work (at least during my testing). -> use mp3val on those files (and the working ones) Also information about the mp3 type (variable/fixed/average encoding, what encoder, junk id3 tags from iTunes etc.) might be relevant.
Unfortunately, mp3val is not showing anything meaningful. Here are two tracks, the first tends to get a scrubber control OK and the second tends to not though it is not 100% either way. mostly works: INFO: "/some/path/Sundaes/A2 - Kuba Elektrik.mp3": 11526 MPEG frames (MPEG 1 Layer III), +ID3v1+ID3v2, CBR mostly fails: INFO: "/some/path/We Are Black Noise/A2 - S411.mp3": 9849 MPEG frames (MPEG 1 Layer III), +ID3v1+ID3v2, CBR Amarok shows that both file are encoded at 320kbps and 44.1khz. Another set of MP3s come out like this: seems to always work correctly: INFO: "/some/path/le_syndicat/Rectal Struggle/Side A.mp3": 70739 MPEG frames (MPEG 1 Layer III), +ID3v2, Xing header seems to always lose the scrubber: INFO: "/some/path/le_syndicat/recitude__le_syndicat_16__k7/recitude [le syndicat 16] k7/le syndicat - rectitude side b.mp3": 70065 MPEG frames (MPEG 1 Layer III), +ID3v1+ID3v2, no VBR header The last file's error message suggests the missing VBR record may be responsible but other files that do work will stop working after clicking on it. Perhaps there is a flag or status byte somewhere not getting reset? As an aside, I am finding with file that fail that Amararok is adding spurious books marks to the tracks. Not sure if that is related to the controls going wonky or not but I do not remember this happening previously. Cheers Cheers
Thank you for the information.
Please get us a log: http://techbase.kde.org/Development/Tutorials/Debugging/Phonon
Created attachment 59520 [details] Example log file displaying problematic scrubbing control behaviour The attached log file shows an Amarok session where tracks sporadically lose or gain the ability to fast forward / rewind. Amarok started up with last session showing a list of tracks within a given folder. I was clicking on a specific track and trying to drag the scrubbing control a few times. I would then try a different track until the state changed (i.e. "working properly" or "not working properly") and then go back to the previous track to see if the behaviour changed. The log file includes at least one case where a track that initially did not work changed to working and vice versa. Tracks when not working trigger a "track not seekable" error like this: amarok: BEGIN: void EngineController::seek(int) amarok: [EngineController] Stream is not seekable. amarok: END__: void EngineController::seek(int) [Took: 0s] That state changes with any obvious pattern however. As an aside, I had to switch to using the "main" toolbar to get a scrub control to show at all for problematic tracks though it still wasn't draggable. In slim mode when tracks were not seekable, they had no scrub control visible at all and it was not possible to trigger the seek error. The logfile has had local paths mangled and some extra playlist related flotsam removed from the start up section (figured you didn't need to know about the random subset of my music collection that Amarok decided to enumerate playlists for on startup). For the files in question, mp3val states the following about them: (MPEG 1 Layer III), +ID3v1+ID3v2, CBR If you need something more specific let me know. Cheers
I added some debugging code to phonon-gstreamer. Please rebuild phonon-gstreamer from git and set the GST_DEBUG_DUMP_DOT_DIR environment variable to something such as /tmp/, re-run amarok, and attach whatever 'phonon-updateSeekable-*.dot' files you see in /tmp/. As part of the attachment description, please include the filename.
*** Bug 273284 has been marked as a duplicate of this bug. ***
*** Bug 273159 has been marked as a duplicate of this bug. ***
This issue is happening in my system too... [Test Results]: This issue is only happening when I use Gstreamer Phonon Backend since I can seek all my MP3 files when I use any other phonon backend like XINE or VLC... This issue is also happening in Amarok 2.4.1, Dolphin and all program that are based in Phonon infrastructure. [System Information]: Extra Codecs Repositories: Medibuntu; Kubuntu Backports; Ubuntu X-SWAT Updates (For NVIDIA latest Drivers) Phonon version: 4:4.7.0really4.5.0-0ubuntu3 VLC Phonon Backend version: 0.4.0-0ubuntu1 XINE Phonon Backend version :4:4.7.0really4.4.4-0ubuntu3 GStreamer Phonon Backend version: 4:4.7.0really4.5.0-0ubuntu2.1 Distribution: Kubuntu 11.04 Installed Codec Packs: w32codecs; kubuntu-restricted-extras Media Players installed: SMplayer; VLC; Banshee; Rhythmbox; Amarok 2.4.1 Sound Playback Software and Drivers: ALSA-BASE (1.0.24+dfsg-0ubuntu1); PulseAudio (1:0.9.22+stable-queue-24-g67d18-0ubuntu3.1) Thanks for your attention, André M.
[SYSTEM INFO - CONTINUATION]: KDE 4.6.2 KERNEL: 2.6.38-8-GENERIC-PAE
Please all, check comment #19 and provide the feedback we asked for.
*** Bug 276164 has been marked as a duplicate of this bug. ***
How can I do it? I don't know how to get git files and check this issue... Thanks for your help, -- André Madureira
After discussion with the Phonon developers the problem appears to be the codec provided by Gstreamer, so please report this upstream, not much we can do on our side, sorry. You can also alternatively use the phonon-backend-vlc instead.
(In reply to comment #27) > After discussion with the Phonon developers the problem appears to be the codec > provided by Gstreamer, so please report this upstream, not much we can do on > our side, sorry. > You can also alternatively use the phonon-backend-vlc instead. Have filed a bug here: https://bugzilla.gnome.org/show_bug.cgi?id=653124
Thy shall read here to fix this: http://ubuntuforums.org/showthread.php?t=1435189 Also Rob's bug report seems to be a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=162833 perhaps you should mention that (or mark it as duplicate yourself).
(In reply to comment #29) > Thy shall read here to fix this: > http://ubuntuforums.org/showthread.php?t=1435189 > > Also Rob's bug report seems to be a duplicate of > https://bugzilla.gnome.org/show_bug.cgi?id=162833 perhaps you should mention > that (or mark it as duplicate yourself). The solution is based on installing the plain gstreamer0.10-plugins-ugly plugins, rather than the multiverse variant. I don't seem to be able to find the non-multiverse version. I have all software sources enabled on Kubuntu 11.04. So this hasn't solved anything for me. That said, not sure I've got backports... Would I need that? More to the point, should I need that?
(In reply to comment #29) As for the duplicate: I have Kubuntu 11.04 with all latest supported packages, including gstreamer0.10-plugins-good, and I'm still unable to seek sometimes. Has this update been done to the gstreamer good plugins since 11.04 was released? As otherwise, the bug is very much still there... Or it's not a duplicate. Rob
I'm on suse 11.4 and can confirm this bug for amarok / gstreamer. Configuring phonon to use the xine backend the cue slider starts to work again.
I can confirm the problem on suse 11.4. I am using gstreamer-ffmpeg, so suppose the issue is as described here: http://lists.freedesktop.org/archives/gstreamer-devel/2011-April/031448.html The conclusion there is that gstreamer-ffmpeg is broken. But on the other hand, if gst123 can seek (which it can in my case), why is amarok not flexible enough to do the same?