Request suggestions for debugging failed state change on nested bins.

Nathanael D. Noblet nathanael at gnat.ca
Fri Jan 4 09:35:16 PST 2013


On 01/04/2013 10:18 AM, Stirling Westrup wrote:
> I have a fairly complex setup for my application, and it can involve
> elements nested inside bins inside other bins inside my pipeline.
>
> Sometime when I make a small change, one of the elements fails to make
> a state change, and my entire pipeline times out on the change.
>
> In these cases I'd love some way to iterate through the pipeline's
> elements and list which ones have not changed state. In the case of
> bins that haven't changed, I'd like to iterate through them
> recursively so that I can get a list of which lowermost elements
> failed to transition. I think this would help me pin down errors more
> quickly.
>
> The thing is, I'm not sure how to go about doing this. If a pipeline
> times out while changing state, are the states of the component
> elements up to date, or not? Bins seem to keep an internal list of
> which elements have yet to finish an async state change, but that is
> private info that I am loathe to try to access, even in a debug
> routine.
>
> Any and all suggestions about how to go about this are welcome.

I can't immediately answer you - however in situations like this I've 
used the DEBUG_DUMP_DOT whatever environment variable to see all the 
elements and what their states were at various points in the call chain. 
I would often find the one element that didn't complete the change there 
through looking at the images created from that data file.

The other thing I would wonder if somehow you could track the elements 
in a map/table or something and record it using the bus signal for state 
change. That at least means that you can have a central location where 
you kept the elements states. Probably wouldn't be too complicated to 
build either.

Just my 2 cents.


-- 
Nathanael d. Noblet
t 403.875.4613


More information about the gstreamer-devel mailing list