Hi Guys,

I have spent quite some time and frustration trying to deal with this problem. I'll describe it first, then add what I have done so far.

When the currently playing track in the playlist ends, Amarok swaps to the next track but the thing that represents current track location (seek head?) rapidly advances through the track.
Sometimes the next track does begin playing, just quite late in the track. Often-times the next track (and a seemingly random number of others) get skipped (by the seek head scanning the whole way through) before a new track starts playing. Very rarely, it works as expected.

Now, a brief description of my environment:
Running Linux Mint 15 (with cinnamon). It was installed just a week ago, and appears to have no other issues.
My entire library is .aiff files.
My backend stuff is phonon gstreamer and pulseaudio.
Amarok version 2.8.0 using KDE 4.11.1

Other notes
This problem does not happen on the Banshee install which came with Mint15 by default.
This problem does not occur if I press to skip to the next track; only if it reaches the end on its own.
The problem seems to get worse the longer I wait before intervening.
I don't know anything about backends, and so my ability to search for solutions there is limited. My guess is that Banshee uses the same ones though, and since Banshee is not showing the same problems that cannot be the issue.

I am beginning to believe (but am by no means certain) that there is actually a pattern to the seeking.
My theory is that once a 5:00 (arbitrarily chosen) track finishes, an internal variable somewhere in Amarok doesn't reset the current location to 0:00. This means that it will try to find 5:00 in the next track. If the next track is shorter than 5:00, it ends up skipping it entirely.
This explains the worsening phenomenon. The next track to play after a 5:00 one must be longer, the next longer again, and so on. As the track length increases the fraction of tracks within the library which will be entirely skipped grows.

Final

I'm at the limit of my ability to self-help on this one. Usually I am able to solve these issues with enough perseverance, but I've been trying at this one for a couple of days now and feel no closer to fixing it than when I started.

I would be incredibly grateful if someone here can help me find a solution. Apart from this issue, Amarok looks like the best music library organizer that I've ever used.

Please check if the same issue also happens with other audio formats, e.g. MP3 or Ogg.

Hi Markey. Thanks for the response!

Testing
I loaded 20 .mp3s, 20 .wavs, and 20 .flacs into the library and created a playlist for each filetype.
After listening to 5 tracks from each playlist I haven't noticed the same issue occurring.
I don't consider my testing to be very extensive at this point -- it isn't beyond the realm of possibility that I got lucky -- but I thought I'd let you know all the same.

I'm quite surprised at this result so far. I included the information about having a single format library just in case it could be significant, but I assumed that the processing for it would have been all done by some element of the backend or a codec or something which would be shared with Banshee.

Other Discovery A
During the course of my testing I got tired of waiting for every track to play the whole way through, but I continued to do so because it seemed that the problem could not be replicated if I used my cursor to set the seek head near the end of the track. I've discovered something quite interesting which might help you debug the problem:

If I let my 5 minute track play all the way through, and there was an 8 minute track afterwards, it would seek through the first 5 minutes of the next track and then begin playing.
If I set the playback location on the 5 minute track to the end, the next track would start as expected.

Here's where it gets interesting:
If I set the playback location 1 minute before the end of the track, it would seek 1 minute into the next track (after the first track finished).
If I set the playback location 2 minutes before the end of the track, it would seek 2 minuets into the next track (after the first track finished).

This appears to be accurate to the second. Starting 7 seconds from the end seeks 7 seconds into the next track.

Other Discovery B
Since it seems that filetype is the issue, what else could I discover? Well obviously my issue occurred when .aiff transitioned to .aiff, but not .mp3 to .mp3... What about .aiff to .mp3 or vice versa?

.aiff -> .mp3 - behaves as expected (no issues)
.mp3 -> .aiff - causes some different (but similar) problems. When my 4:02 track ended, my .aiff track started at 4:01, but was not playing (despite the play/pause icon suggesting it was not paused). So I clicked the play/pause button once (to pause it), but then after trying to click it again (to unpause it), that button becomes unresponsive. It is impossible to press play. I have been able to replicate this issue, though the timing is not quite the same. When a 6:30 mp3 ended, the .aiff was stuck at 6:19 for some reason. If the mp3 is longer than the aiff, the aiff gets stuck at its end.

Exactly the same issue can be reproduced with wav -> aiff. I haven't bothered testing flac -> aiff.

Other Discovery C
It seems that whether this bug occurs is not 100% random. Or rather, it isn't a dice-roll on every transition. I have managed to construct a playlist with an .aiff file which causes none of these bugs no matter how many times I try. I don't know if that is a special property of the playlist or the 'special' .aiff track.

I'm toying with the idea that it could have something to do with improperly updated files, as I have been slowly improving the information stored within the track fields (metatags) within Amarok, and the problem may (or may not) have been getting worse over time. But I would be extremely sceptical of this theory, and haven't tested it yet.

Finally

If we assume that .aiff is the issue, are there any solutions other than converting my library? Surely I am not the first person to use .aiff with Amarok?
I'll keep testing and report back if anything interesting shows up.

So you see, AIFF is not a very common format. The less common something is, the higher the probability becomes that it doesn't work right (less testing...). It's one of the oldest formats around, from 1988 actually, and I don't know anyone else who uses it. For lossless audio compression these days FLAC is pretty much the standard.

At any rate, Amarok itself does not actually play anything. It delegates the decoding and playback to other libraries. First there is Phonon, and Phonon itself is an abstraction layer that uses either GStreamer or libVLC (which are abstraction layers as well...)

You can find out what backend you are using by clicking Help -> Diagnostics. So maybe you are lucky and the same bug won't happen with a different Phonon backend. Install it and give it a try.

That's pretty much what I expected.

But if that's the case, I still don't understand why this issue occurs in Amarok but not in Banshee. Amarok diagnostics are telling me I'm using Gstreamer, and although I can't find a similar diagnostic tool for Banshee, according to their faq (http://banshee.fm/support/faq/) they use Gstreamer as well. Any ideas?

Perhaps Banshee uses the newer GStreamer 1.x version. Phonon still uses the 0.10.x one.

Ah. Yes, that must be it.

Just so the thread has an answer as well as a question (for anyone who has the problem themselves).

Using phonon-backend-vlc instead of phonon-backend-gstreamer solves the problem.