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 tests 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.
parent
17b119f4
Please register or sign in to comment