GNOME Bugzilla – Bug 668289
regression: playbin2: repeat mode only repeats twice in totem
Last modified: 2012-02-03 11:28:22 UTC
The repeat mode in Totem only repeats playback twice, after that it seems to get stuck, though it still shows "Playing" in the statusbar. This seems to happen regardless of the file format of the video. I'm using version 3.2.1
Confirming https://bugs.launchpad.net/ubuntu/+source/totem/+bug/918077
The Launchpad bug also mentions that this problem only occurs if you're trying to loop a single file. If you loop two or more files in a playlist it works as intended.
I could very well be wrong, but it looks like Totem doesn't get an EOS after the seek to beginning, so it only enters on_eos_event once. If that's the case I guess it's a bug in GStreamer? It could be worked around by pausing before the seek, but I doubt that's the correct way to fix this.
Downgrading GStreamer from 0.10.35.2 to 0.10.35 also solves this, so I guess it really is a GStreamer bug.
Let's mark it as blocker and move to -base for now then.
When you say "Downgrading GStreamer from 0.10.35.2 to 0.10.35", was this the gstreamer core, or the -base plugins, or both ? I'm having a lot of trouble trying to bisect here due to various API changes, and knowing this would help a lot.
It was both.
Thanks. I just got lucky and found the culprit by reverting what seemed like good candidates: commit 4a836cae9fa9240d7ed3c6e5a9d7ea9afa484c0a Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Mon Apr 18 14:26:33 2011 +0200 bin: Only post EOS messages after reaching the PLAYING state Fixes bug #647756.
Created attachment 206651 [details] [review] bin: reset the EOS detection machinery after sending an EOS message This will allow detecting further EOS, for instance after looping a stream without changing states.
This solves the issue of looping only once. I'm not certain it keeps the original issue fixed, as I cannot reproduce the original issue from instructions in 647756. I think it ought to be OK though, as explained in the comment in this patch.
Not 100% sure if this is correct but I can't think of a case where this breaks. Usually the EOS "state" is only left when you receive a new NEWSEGMENT event after EOS or if the element state changes but doing the first in GstBin is not a good idea... and then all elements inside the bin are supposed to do this correctly already so there should only be new stuff after EOS in GstBin if one of the elements inside the bin has successfully left the EOS "state". (yes, there's not really an EOS state :P )
I'm... not sure I understand that :) I first tried to reset the EOS flag when receiving a seek event, but that did not fix the issue (I did not understand why the timing of this was wrong). Maybe setting upon receiving a segment event would work too, if that's what you're saying ?
Talked with slomo, he's OK with the patch; pushed: commit ec7a7c318ac33fe76ad88fde7b9b64913ab23c57 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Thu Feb 2 17:18:22 2012 +0000 bin: reset the EOS detection machinery after sending an EOS message This will allow detecting further EOS, for instance after looping a stream without changing states. https://bugzilla.gnome.org/show_bug.cgi?id=668289