Skip to content
Commit 6c890659 authored by Andrés G. Aragoneses's avatar Andrés G. Aragoneses
Browse files

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
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment