[banshee/stable-2.6] PlayerEngine: avoid spurious *Stream events

[Andrés Aragoneses <aaragoneses src gnome org>]

commit 928981b8177ae13e01e722eaa8b4a396e7b4b0ce
Author: Andrés G. Aragoneses <knocte gmail com>
Date:   Fri Jan 24 01:56:03 2014 +0100

    PlayerEngine: avoid spurious *Stream events
    
    Since we merged GStreamer 1.0 support, MediaEngineTests
    started failing. They highlighted some events being
    received which didn't make much sense. After digging,
    I found out that there's a subtle difference in the
    order of events that we receive from GStreamer 1.x,
    comparing it to the one we got from GStreamer 0.10.
    
    This is from GStreamer 0.10:
    
    [1 Debug 01:22:48.263] Player state change: Idle -> Loading
    [1 Debug 01:22:48.346] Player state change: Loading -> Loaded
    [1 Debug 01:22:48.352] (libbanshee:player) Triggering track-change signal
    [1 Debug 01:22:48.360] Player state change: Loaded -> Playing
    
    
    And this is from GStreamer 1.x:
    
    [1 Debug 01:31:15.719] Player state change: Idle -> Loading
    [1 Debug 01:31:15.793] (libbanshee:player) Triggering track-change signal
    [1 Debug 01:31:15.804] Player state change: Loading -> Loaded
    [1 Debug 01:31:15.810] Player state change: Loaded -> Playing
    
    This shouldn't have much repercussion you might think, but it
    turns out that our Gapless support was relying on this order:
    if a track-change signal was received and we're *not* in Loaded
    state, it means a transition: so we need to send an EndOfStream
    event, a StartOfStream event, aaaand increment the playcount of
    the previous song.
    
    Now this code must take in account how GStreamer 1.x sends
    events, so it needs to check against the Loading (not just
    Loaded) state.
    
    This may have caused subtle bugs, especially regarding the
    playcount, and especially considering that some of our
    lovely packagers of some distros decided to include the
    GStreamer 1.x support patches as downstream patches. This
    means, that I'm going to backport this fix as well to the
    stable branch so we can keep things in order for upcoming
    2.6.2 version.
    
    This makes the test pass again when using the native
    backend. I'm *not* modifying the GStreamerSharp (managed)
    backend yet because other tests are still failing for that
    one, and the code for this is slightly different there
    (i.e. it doesn't have the GaplessEnabled check).

 .../Banshee.GStreamer/PlayerEngine.cs              |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/src/Backends/Banshee.GStreamer/Banshee.GStreamer/PlayerEngine.cs 
b/src/Backends/Banshee.GStreamer/Banshee.GStreamer/PlayerEngine.cs
index 278ff51..475fa6c 100644
--- a/src/Backends/Banshee.GStreamer/Banshee.GStreamer/PlayerEngine.cs
+++ b/src/Backends/Banshee.GStreamer/Banshee.GStreamer/PlayerEngine.cs
@@ -417,7 +417,7 @@ namespace Banshee.GStreamer
 
                 // If the state is anything other than loaded, assume we were just playing a track and should
                 // EoS it and increment its playcount etc.
-                if (CurrentState != PlayerState.Loaded) {
+                if (CurrentState != PlayerState.Loaded && CurrentState != PlayerState.Loading) {
                     ServiceManager.PlayerEngine.IncrementLastPlayed (1.0);
                     OnEventChanged (PlayerEvent.EndOfStream);
                     OnEventChanged (PlayerEvent.StartOfStream);