To recap from the Ubuntu report:

I instrumented ConnectedSeekSlider.cs with debugging statements and found that PlayerEngine.Position (supposedly, the number of milliseconds into the track you currently are) is not reset on track change in gapless mode.

The bug was tricky to track down, because sometimes when changing tracks, the slider continues to show both position and new track length, and sometimes it reverts to only showing total play time.

If the new track's length (PlayerEngine.Length) is *longer* than the "position" (PlayerEngine.Position) then the slider will show the "position" and the new track length.  However, the "position" will be the sum of previous play time, not the actual position in the new track, so the slider will appear to be far into the new track, even though the new track has just started.  Once the "position" (once again, the sum of previous play time) becomes greater than the track length, the slider will no longer show the track length, but merely the "position".  (In the code, the slider still has the current track's length as one of its attributes, but it no longer displays it.)

If you move the slider, this forces the PlayerEngine to seek to the relative location on the track, e.g., if you move the slider to the 50% position while a 3 minute long track is playing, the PlayerEngine will seek to 1 minute 30 seconds into the current track.  This resets PlayerEngine.Position and thus the slider behaves properly again, for a time.

Unfortunately, this is as far as I got.  There are some fairly opaque interactions between Banshee and GStreamer (which Banshee uses as the actual playback engine).  I spent several hours digging through the respective code bases, and I still have no clue how gapless playback works or which module is actually responsible for this bug.

(In reply to launchpad comment no. 3)
> I instrumented ConnectedSeekSlider.cs with debugging statements and found that
> the PlayerEngine is not resetting its Position attribute (the number of
> milliseconds into the track it is) when it rolls over to a new track. If the
> new track is shorter than the current "position" (the sum of previous
> positions) then the slider will show only the "position", not the time on the
> current track. If you move the slider, this forces the PlayerEngine to reset
> its Position and thus the slider behaves properly again, for a time.

Thanks for the investigation!

> I am currently looking into why the PlayerEngine is not resetting its
> position on track change.

If you got this far, I'm sure you will eventually figure out the ultimate reason, and writing a patch to fix it.

One thing that may help you to figure this out is print the stacktrace on each debug statement, for example:

System.Console.WriteLine("___this is a debug statement, stacktrace:" + System.Environment.StackTrace);

This way, you can know from which part of the code the PlayerEngine was ordered to reset, so you can figure out why it doesn't happen in a certain situation.

After further examination, I am thinking that this is a bug/shortcoming in GStreamer, not in Banshee.  Banshee merely reports the position information that GStreamer provides.  Furthermore, GStreamer provides correct position information for some files (OGG Vorbis) and not others (FLAC).

This might happen because Vorbis has a special GStreamer plugin (ext/vorbis/gstvorbis{parse,dec}.c) whereas FLAC does not.  This is speculation, because I find the layers of abstraction and the lack of comments/documentation to make GStreamer really difficult to understand.  If I am right, then to parse FLACs in gapless mode, someone will need to engineer a FLAC plugin for GStreamer.  That requires a greater time commitment than I can make for the foreseeable future.

https://bugzilla.gnome.org/show_bug.cgi?id=664433

Here is the GStreamer bug report I filed.

I experience the same issue with mp3-files on Ubuntu 11.10 with Gnome3 ppa and Banshee 2.2.1.
Am I the only one or was this obvious that this is also an mp3 issue?

Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Please feel free to reopen this ticket (or rather transfer the project
to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the
responsibility for active development again.
See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.