After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 649550 - [playbin2] hang on song change
[playbin2] hang on song change
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.32
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-05-06 10:24 UTC by Christoph Reiter (lazka)
Modified: 2012-12-02 12:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
hang stacktrace (27.70 KB, text/plain)
2011-05-06 11:58 UTC, Christoph Reiter (lazka)
Details
libasound segfault (9.57 KB, text/plain)
2011-05-06 11:58 UTC, Christoph Reiter (lazka)
Details
stacktrace 2 (19.54 KB, application/octet-stream)
2011-10-16 07:19 UTC, Christoph Reiter (lazka)
Details

Description Christoph Reiter (lazka) 2011-05-06 10:24:00 UTC
This happens after about 20-40 fast song changes (reproducible)

playbin2.set_state(gst.STATE_NULL)
playbin2.set_property('uri', uri)
playbin2.set_state(gst.STATE_PLAYING)

The failing part seems to be at

"gst_pad_remove_data_probe (pad=0x4970380, handler_id=3274) at gstutils.c:3350
no_more_pads_cb (decodebin=<value optimized out>, group=0x4ba5958) at gstplaybin2.c:2800"

Calling playbin2.get_state() before STATE_NULL seems to prevent the hang.
Comment 1 Tim-Philipp Müller 2011-05-06 10:49:31 UTC
With any kind of file (mp3/ogg/avi/mp4/mkv) ?

What audio/video sinks are being used in your case?

Could you make a small test program that we can run that reproduces the issue?

Have you tried the pre-releases, if they fix this?
Comment 2 Christoph Reiter (lazka) 2011-05-06 11:58:12 UTC
2) Hang tested with mp3/flac/wma

1) Pipeline: playbin2 -> gostpad -> queue -> volume -> alsasink

3+4) After moving code around to simplify things, it stopped to trigger.. moving back to the original code now also doesn't trigger it anymore... 

There also was a segfault one time in snd_pcm_hw_refine...
(Debian doesn't have debug symbols for libasound)
Comment 3 Christoph Reiter (lazka) 2011-05-06 11:58:35 UTC
Created attachment 187348 [details]
hang stacktrace
Comment 4 Christoph Reiter (lazka) 2011-05-06 11:58:57 UTC
Created attachment 187349 [details]
libasound segfault
Comment 5 Stefan Sauer (gstreamer, gtkdoc dev) 2011-05-06 15:16:00 UTC
(In reply to comment #2)
> 2) Hang tested with mp3/flac/wma
> 
> 1) Pipeline: playbin2 -> gostpad -> queue -> volume -> alsasink

Hmm, that looks wrong. Playbin is a top-level pipeline. What do you want to do actually?

> 
> 3+4) After moving code around to simplify things, it stopped to trigger..
> moving back to the original code now also doesn't trigger it anymore... 
> 
> There also was a segfault one time in snd_pcm_hw_refine...
> (Debian doesn't have debug symbols for libasound)
Comment 6 Christoph Reiter (lazka) 2011-05-06 16:53:25 UTC
As far as I know it's for getting us more time in about-to-finish (500 ms) so gapless works and the extra volume element is for setting volume without the 500 ms delay.
Comment 7 Stefan Sauer (gstreamer, gtkdoc dev) 2011-05-09 08:16:07 UTC
(In reply to comment #6)
> As far as I know it's for getting us more time in about-to-finish (500 ms) so
> gapless works and the extra volume element is for setting volume without the
> 500 ms delay.

What about creating a bin containing: queue -> volume -> alsasink and setting that as the audio-sink in playbin2?

Otherwise which element in playbin2 are you proxying with the ghostpad? Are you adding queue -> volume -> alsasink to playbin2 or to playsink? Any link to the code where this is done?
Comment 8 Christoph Reiter (lazka) 2011-05-09 09:50:21 UTC
Oh, sorry, that's exactly what we do... forgot the bin.

playbin2 -> bin[ gostpad <- queue -> volume -> alsasink ]
Comment 9 Christoph Reiter (lazka) 2011-10-16 07:19:14 UTC
Created attachment 199104 [details]
stacktrace 2

Here is another one with 0.10.35
Comment 10 Tim-Philipp Müller 2012-11-30 23:43:42 UTC
I used to see this warning ("... has no handler with id ...") quite regularly in totem, but haven't seen it for ages now with 0.11/1.0, so I'm tempted to close this as OBSOLETE.

Any chance you could re-test with 1.0.x ? (Sorry, I know it's been a while)
Comment 11 Christoph Reiter (lazka) 2012-12-01 08:33:15 UTC
Yeah, go ahead.

We've removed the queue some time ago and I haven't had any reports or freezes myself since then.
Comment 12 Tim-Philipp Müller 2012-12-02 12:58:55 UTC
Hrm ok. It should work with or without queue of course. Still, let's close this for now. If it's still an issue with 1.x, someone will file a new bug :)