GNOME Bugzilla – Bug 90885
set_state(READY) wont work on my machine
Last modified: 2009-08-15 18:40:50 UTC
i have run my program on 3 machines: an IPAQ (familiar-0.5.3), an Atlon1000 (Mandrake 8.1) and an Athlon XP+1700 with SuSE 7.2. it runs correctly on the first two, however, on the last one it wont work. (it hangs in gst_element_set_state when setting READY state the second time - the first time setting READY makes no problems) im using the gst_play-class of steveb and all my code does until hanging is: gst_init (&argc, &argv); play = gst_play_new (GST_PLAY_PIPE_VIDEO); gst_play_set_state (play, GST_STATE_READY); gst_play_set_state (play, GST_STATE_READY); <-- here it hangs here the tail of the gst-mask=-1 output: DEBUG( 1859: 0)cothread_stackquery:552: Got new cothread stack from 0x40c00000 to 0x40dfffff (size 2097152) DEBUG( 1859: 0)gst_basic_scheduler_get_preferred_stack:958: getting preferred stack size as 0x40c00000 and 2097152 (process:1859): GStreamer-WARNING **: pthread_attr_setstack failed DEBUG( 1859: 0)gst_element_set_state:1867: [work_thread] have failed change_state return DEBUG( 1859: 0)gst_bin_change_state:540: child 'work_thread' failed to go to state 2(READY) DEBUG( 1859: 0)gst_element_set_state:1829: [work_thread] setting state from NULL to NULL INFO ( 1859: 0)gst_bin_change_state:567: [main_pipeline] done changing bin's state from NULL to READY, now in NULL DEBUG( 1859: 0)gst_element_set_state:1880: [main_pipeline] element claimed state-change success, but state didn't change NULL, NONE_PENDING <-> READY DEBUG( 1859: 0)gst_element_set_state:1829: [main_pipeline] setting state from NULL to READY INFO ( 1859: 0)gst_bin_change_state:521: [main_pipeline] changing childrens' state from NULL to READY DEBUG( 1859: 0)gst_element_set_state:1829: [work_thread] setting state from NULL to READY INFO ( 1859: 0)gst_thread_change_state:258: [work_thread] sync(0): changing state from NULL to READYDEBUG( 1859: 0)gst_thread_change_state:272: [work_thread] sync(0): creating thread "work_thread"
out of curiosity, why do you set it to PLAYING twice in a row ? My hunch is that we have a race condition there; you're trying to set it to PLAYING, and the core signals the thread to go to PLAY, but it's not done by the time the second _set starts. It's something that should be fixed in any case, but please try with only one set to PLAY and let us know how that changes things.
nothing heard. closing.