GNOME Bugzilla – Bug 702856
[playbin] song changes broken
Last modified: 2018-01-23 15:32:20 UTC
Created attachment 247512 [details] backtrace Various problems with song changes with at least ogg/flac/mp3 files and 1.0.7 In all cases after a song change, the next song starts to play and after 1-2 seconds audio is gone. Sometimes the position still increments, other times that's stuck as well.... Example warn output at the time audio stops (the last two are from bringing the pipeline down): 0:09:59.839102273 20308 0x7f8150060b20 WARN pulse pulsesink.c:641:gst_pulsering_stream_underflow_cb:<autoaudiosink2-actual-sink-pulse> Got underflow 0:10:00.750535549 20308 0x7f81580432d0 WARN audiobasesink gstaudiobasesink.c:1579:gst_audio_base_sink_get_alignment:<autoaudiosink2-actual-sink-pulse> Unexpected discontinuity in audio timestamps of +0:03:21.120861678, resyncing 0:10:00.751424025 20308 0x7f8150060b20 WARN pulse pulsesink.c:653:gst_pulsering_stream_overflow_cb:<autoaudiosink2-actual-sink-pulse> Got overflow ^C0:10:17.634040128 20308 0x7f81400014a0 WARN baseparse gstbaseparse.c:2177:gst_base_parse_push_frame:<mpegaudioparse5> error: No caps set 0:10:17.634090879 20308 0x7f81400014a0 WARN baseparse gstbaseparse.c:3038:gst_base_parse_loop:<mpegaudioparse5> error: streaming stopped, reason error A sample backtrace from a "no sound, but time increasing" state attached.
Another side effect is endless song-change cycles.. where a song change is triggered every second no matter how long the song is.
Marking as blocker for now - even if it's not a regression it's pretty bad.
<lazka> slomo, Quod Libet. Not sure. <lazka> I'm working on a test case <lazka> I think we need to much time in the about-to-finish callback sometimes and playbin doesn't like it <slomo> lazka: ah, might be related to one of the other about-to-finish bugs then <__tim> hrm, never noticed any of that with totem <slomo> __tim: totem is not using about-to-finish... and taking to long in that callback can indeed cause underruns, but should catch up quite fast <__tim> right <slomo> i'm having no problems with about-to-finish in banshee in 1.0 since the beginning btw, it's not completely broken at least ;) <__tim> what does 'too long' mean? When is it triggered? 1 second before? 3? <slomo> __tim: when EOS arrives behind uridecodebin so what's left is the downstream queues in playbin/playsink before the sink and the sink ringbuffer <slomo> so... very late :) <__tim> I see! <slomo> ideally it would do that X seconds before the EOS already, and already pre-roll the next pipeline <lazka> I can only reliable reproduce with "pitch" appended to the playbin.. but I got bug reports with the same symptoms where that isn't the case <lazka> so maybe those reports are bogus and pitch is broken <slomo> scaletempo generally works better than pitch <lazka> (so the blocker is maybe too much..)
Created attachment 247518 [details] test-case using pitch
Isn't this the same as bug #701997 ?
(In reply to comment #5) > Isn't this the same as bug #701997 ?
(In reply to comment #5) > Isn't this the same as bug #701997 ? No, this here is with 1.0.7. Does it still happen with latest git master? And also when using scaletempo instead of pitch (as pitch has broken segment handling IIRC).
Just managed to get a traceback (GStreamer 1.2.4.0) with the following pipeline: playbin -> volume -> autoaudiosink(pulsesink) * Playing * Stream change * No sound, no position change * gdb... * Immediatly after I detached with gdb it started playing
Created attachment 279953 [details] hang using only playbin!volume!pulsesink I forgot to add the attachment... And the whole pipeline while I'm at it: http://bpaste.net/show/0ykzGbArGKBdbvkH34Xz/
Created attachment 290276 [details] backtrace-2 And another one. This time with GStreamer 1.4.3.0. About half a second after the song started. Changing state to paused and playing didn't change anything, only seeking.
Created attachment 290277 [details] backtrace-3 And another one in the same session.
Sorry no one ever looked at this again, but not really sure what to do about this. Not a great deal of info to go on, so going to close this. Hopefully it's been fixed since ? If not, please re-open with stacktrace, pipeline graph (dot file) and GST_DEBUG log from a current version of GStreamer. Ideally reproduced with gst-play-1.0 --gapless.
I think using pitch still leads to problems, but without it I haven't seen any similar problems recently (also no bug related reports). I'll open a new bug with more info if it happens again. Thanks!
You should probably use scaletempo instead these days, unless there's a use case not covered by it.