Request suggestions for debugging failed state change on nested bins.

[Stirling Westrup]

I went and 'just coded' something today to see if it worked at all. It
turns out that the elements do seem to have up-to-date current states
and just recursing through bins using gst_bin_iterate_elements allowed
me to write a quick-and-dirty program to dump the state of my entire
pipeline, as a tree.


On Fri, Jan 4, 2013 at 12:35 PM, Nathanael D. Noblet <nathanael at gnat.ca> wrote:
> 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
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



-- 
Stirling Westrup
Programmer, Entrepreneur.
https://www.linkedin.com/e/fpf/77228
http://www.linkedin.com/in/swestrup
http://technaut.livejournal.com
http://sourceforge.net/users/stirlingwestrup