GitLab

Conflicts:
	gstreamer/CMakeLists.txt
	gstreamer/backend.cpp

BUG:192603

BUG: 303478

BUG: 305333

BUG: 302033

REVIEW: 106010

when getting a state change while handling abouttofinish we get >=1
additional callbacks for the same track, so we discard any aboutToFinish
until either setNextSource (gapless case) or setSource
(non-gapless case) was called

i.e. we only handle aboutToFinish once for a track, any further cbs are
stuffed back down gstreamer's throat

- explicit ctors
- const ref foreach
- char for qstring operations
- include own header first
- proper include guards
- prefix inc > suffix inc

if we go to stopped after phonon handed us a source it will simply set
it as regular source, so we do not need any special handling for the
next source call at all

Conflicts:

	gstreamer/mediaobject.cpp

Conflicts:
	gstreamer/mediaobject.cpp

This reverts commit c26e0046.

The commit apparently tried to make pgst handle the queued source
setting, which was pretty much already handled by gstreamer and the
about-to-finish signal.

Conflicts:
	gstreamer/mediaobject.cpp

This did in fact properly work prior to the commit. The problem was
elsewhere.

This reverts commit 8deb772b.

add warning instead... vision for a fix pending (if there is one, which
I doubt)

gstreamer is a very funny thing in that it goes to paused before going to
stopped (Which is because gstreamer does not actually know stopped), to
prevent this we simply turn of statechange emission entirely while working
on endofstream (in which go to translated stopped) and emit but one
change to stopped

this only applies to non-gapless use cases

the apparent fix for timed deadlock of some apps broke gapless in
a way that nextsource calls would be entirely disregarded by the
pipeline

- cleanup & merge stop with unlock
- fix streamer unlocking
  - return if the reader got unlocked before the lock was acquired
  - always return right away, to reduce waiting time for possibly waiting
    functions
- turn on seekability
- make streamreader a pipeline member supposed to be reused after stop
  .
  gets thrown away on setting a new source because otherwise libphonon
  likes to assert out with the present streamer implementation
- stop reader also on stop()

When we try to change states, we stop waiting for the next track that
would otherwise be used for gapless playback. Stupid simple fix.

QLatin1String does not deepcopy, so we must only unref after it
was implicitly picked up by a QString

always returned after fist append. this in turn caused the pending buffer
to be no longer a multiple of the channel count ultimately leading to
a mismatch between per-channel buffer sizes (as catched by the
assert introduced 2 commits ago)

BUG: 279791

BUG:297596
FIXED-IN:4.6.1

Wrap the metadata in a lock just in case different gst plugins update metadata at the same time in different threads.

BUG:296606
FIXED-IN:4.6.1

REVIEWBOARD:101595
BUG:272243
FIXED-IN:4.6.1