The choice here is:
_ either rely on a hack in GnlFileSource to cache the emitted messages and emit them when the queue emits 'underrun'
_ have decodebin cache segment-done and emit it once the queues are drained.

*** Bug 397634 has been marked as a duplicate of this bug. ***

I discovered in Jokosher that the audio will end just before the position marker reaches the end of the clip, making things look a few millimetres off (which is not very much). However I think this bug has a larger impact than just that. The more pieces of audio you have in a gnlcomposition, the farther off the time and audio become. 
Note: I have not confirmed if this is the same bug or a different one, but see my theory below.

What I think is happening is gnonlin is receiving the SEGMENT_DONE message before the end of the clip, and it thinks I has to be at the end, so it sets its internal time to the value of the "stop" property on the media in an attempt to reduce the error of the time it took the SEGMENT_DONE to be processed. This makes the gaps between pieces of audio the proper length, but also makes the clip playing time drift further from what it should be. The next clip will start a little early and end twice as early as the first. The more clips of audio there are, the more this small difference adds up, and the further apart everything the actual pipeline time if from the audio that is playing.

A few millimetres is not a big deal, but when multiplied by the number of clips it becomes a very large and noticeable number.

Is there a workaround for this?

This behavior seems to be affected, sometimes for better, sometimes for worse, by having the USE_DECODEBIN2 environment variable set.

I've been having the problem that my movie only plays a few seconds, even if I set the duration to a large number. With USE_DECODEBIN2, my movie plays for the desired duration.

However, with USE_DECODEBIN2 set, the test case from Bug 397634 doesn't play anything at all -- it just hangs.

the workaround is to create your own pipelines that don't use queues and put that into a gnlsource.

FYI, there's a python based queue-less single-stream decodebin in pitivi that we use to workaround this issue. See pitivi/elements/singledecodebin.py

Just wanted to add a me too on this bug, its stopping Jokosher being useful to me, which is a real shame because things were going well.

Can the priority not be upped a bit? Surely loads of people are having this issue?

I'll sling a tenner on paypal as a bounty to anyone who sorts this out in the next week or two (provided it fixes the Jokosher bug that depends on it of course).

*** This bug has been marked as a duplicate of 575972 ***