Version: 2.3.0 (using KDE 4.4.2) OS: Linux Installed from: Gentoo Packages When playing mp3 files with a cuesheet in 2.2.2, everything worked fine. One song ended, the other began and the OSD popped up informing me of the new track's artist and name. There was no pause or anything alike. However, things changed in 2.3.0. Possibly due to individual tracks showing in the playlist, the "transition" is not so smooth anymore. When one song (in the big mp3 file) ended, there's a short but still noticeable pause of about 0.1 seconds and part of the mp3 file (roughly half a second maybe?) is played twice. I'm guessing the latter is because of the mp3 file being encoded with a variable bitrate and it isn't much of a disturbance. But the former is especially bothering when you're trying to listen to a mix of different tracks and the fade between two songs is interrupted. In case some of you have tried to burn a mix to a cd: it's like copying a DOA-created mix cd with a TOA recording mode, if you will; there's a gap between tracks where there should be none.
Part of the issue here is that Phonon does indeed not like seeking in vbr files. A fix for the gap in playback would be to have a check in the engine controller that checks if the current track and the next track are successive parts of the same source file, and in this case, not do the entire stop-select next track-start playback dance. This same fix would also prevent the gap that currently happens when playing tracks of a CD
On 2.4 beta2 song transitions don't work at all. Amarok simply stops playback after a track in a cue sheet album finishes.
Please check your version, there is no 2.4 beta 2 release.
This is an automated message from the triager: Amarok 2.4.1 has been released on May 8 already. Could you please upgrade and test if you can still reproduce this bug? Without feedback within a month we will close this bug as resolved. Thank you for your understanding.
For 2.4.1, I unfortunately cannot comment on the original problem because I also run into what is described in comment 2. Whenever a track ends, playback just plain stops and the playlist does not progress.
Possibly a phonon backend problem, try changing the backend and see if that helps.
Ok, so I tested all three backends that are available on Gentoo. xine: Playback stops after a track ends. I have to manually select and start the next one. Unlike with vlc, I can listen to any track on a big file. vlc: Playing the first track works fine. When the first one ends, playback stops. Trying to start any other track on that mp3 file, I see the progress bar filled out (i.e. 2:46/2:46), the song does not play. Playing a different cue'd mp3 file, I need two or three tries for thaz first track to start or else I hear half a second of a random track until it stops again. gstreamer: The first track plays like it should. Seeking is a lot more responsive and quicker than with xine or vlc. The first tracks ends and the playlist progresses correctly. However, upon progressing to the second track, the whole file starts over again and the progress bar shows 0:00 and is stuck there. Seeking by clicking the progress bar, the correct tracks plays and it shows the correct time again. Playing a random track from a different cue'd file, the latter also starts from the very beginning, but "reseeking" works as well. To round things off, these are the versions I have installed for the tested backends: media-video/ffmpeg-0.7_rc1 media-libs/phonon-4.5.0 kde-base/phonon-kde-4.6.3 media-libs/phonon-xine-4.4.4 media-libs/xine-lib-1.1.19 media-libs/phonon-vlc-0.4.0 media-video/vlc-1.1.9-r1 media-libs/phonon-gstreamer-4.5.1 media-libs/gstreamer-0.10.32-r1 media-plugins/gst-plugins-meta-0.10-r5 If you need any more info, just ping.
Thank you for the fast feedback :)
Setting component accordingly.
not reproducible amarok 2.6
To the OR: could you please test again with Amarok 2.6? It is available since August.
I'm sorry to say so, but no, this isn't fixed. I've tried both gstreamer and VLC as backends (version 4.6.2 and 0.6.1) on both my native machine running Gentoo and two VMs running Ubuntu 12.10 and Fedora 17. The latter were freshly set up from the official amd64 isos and updated to today's patches. Not one of those amarok 2.6.0 installations was able to play a single cue file correctly. Ubuntu was the least successful because it didn't even register the cue file in the same directory as the mp3 file and just showed my the single big mp3 in the playlist. Using gstreamer, double clicking a single song changes the title in the playlist, yes, but it plays the file from the very beginning, i.e. the first track. Clicking the progress bar at the top, I get to hear the song that's selected in the playlist. Transitions don't work at all, I hear the first track while the playlist progresses. Using the VLC backend, song transitions don't work either, playback just plain stops. Using either backend, restarting amarok yields interesting results on the playlist: There are in fact 19 or so tracks on the playlist, but they all lost their individual metadata like artist and song title and instead have the metadata of the big mp3 file, i.e. "DJ someguy - mixtape 42" instead of "Artist 1 - Title 2" and "Artist 2 ft. Artist 3 - Title sqrt(2)", same goes for the individual song lengths. This might explain the odd behavior of the gstreamer plugin. I really do appreciate and am thankful for the efforts people have put into this bug, but tbh, I migrated to audacious very well over two years ago by now and am happy as ever can be with a music player. I am resetting this to bug to REOPENED for the sake of other people potentially also affected by this, but I will not be responding to further fixes as I'm just not using this particular software anymore.
FWIW, I find it unlikely that this is in any way related to the backend as the entire cue business is an overlay functionality (i.e. phonon knows nothing of the cue). Bad state/signal handling in the overlay could however result in the described behavior. For future reference I'll quickly outline how track changing *should* work: best result option: When a given mark in the playback time (e.g. 3 seconds before relative end - that is the end of a track within the whole file) amarok does a look a head on whether the next track is the subsequent track of the cue and if that is the case it will simply swap the metadata/timevalues once the relative end was reached (i.e. Phonon's MO continues to play uninterrupted etc.). If the next track is not the next in the cue, but part of the cue, simply seek to it once relative end is reached. If it is not part of the cue at all stop playback and do regular next-source-setting. cheapest to implement: As above, but instead of keeping the MO playing on inter-cue track changes, a stop is forced and the entire playback is started from scratch. This is cheaper to implement because you could for the better part force a stop on end (being either realtive end or actual end), so the implemenation would likely not need special handling for cue. It however introduces obvious overhead WRT file access and pipline construction. For both I should note that one needs to ensure that the track data such as length and currentPos is sufficiently capsulated from the UI and phonon control code to conveniently inject cue data so that the UI gets absolute values (starts at 0:00, ends at 5:32) and phonon gets relative values (starts at 45:23, ends at 50:55). Not having proper capsulation here will cauese issues in the long run similar to those mentioned in comment #12.