GNOME Bugzilla – Bug 332460
Error handling needs to provide information on pipeline used
Last modified: 2011-05-26 09:11:54 UTC
Please describe the problem: One problem we had in 0.8 which I am sure we will have in 0.10 to is that as there are multiple plugins providing the same functionality we end up spending a lot of time doing QA on the wrong plugins and wasting a lot of time. We need some kind of functionality which keeps track of what plugins our autopluggers use and includes that in some form in the error dialogs presented the users so that this information get included with bug reports. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
agreed, maybe a simple helper function that dumps the contents of a bin would work fine.
Sounds useful, but at least totem is unlikely to include this in its error dialog (see bug #167230)
Applications can now call GST_DEBUG_BIN_TO_DOT_FILE() when they encounter an error. This will dump the pipeline state to a file when a certain environment variable is set. An application *could* just set that to g_temp_dir() if no other directory is specified, and it would probably be possible to make bug-buddy pick up that file somehow via the app's .desktop file (but I'm just guessing here). Does this qualify? :)
Christian, Tim: Any idea how we proceed with this bug? Can we close it because it is already implemented?
Not really. It'd be nice if there was a text-only way to dump some information about the pipeline/eleements used.
I could probably make a variant that dumps the pipeline in a tree like manner. Something like this? GstPipeline:beeps +- GstAudioTestSrc:src0 +- GstVolume:gain `- GstAutoAudioSink:sink0 +- GstAudioConvert:conv `- GstAlsaSink:realsink What details are needed (versions, package origins, modified gobject properties)? Should we have another set of macros GST_DEBUG_BIN_TO_TXT_FILE(), GST_DEBUG_BIN_TO_TXT_FILE_WITH_TS() and the releated envvar GST_DEBUG_DUMP_TXT_DIR? The implementation could definitely go to gstdebugutils.{c,h}. Also for the output, it can be more verbose (it could also support GstDebugGraphDetails): GstPipeline:beeps (paused) +- GstAudioTestSrc:src0 (paused) | wave=3 volume=0.4 | src=audio/x-raw-int +- GstVolume:gain | ... ...
Any news on this?
We haven't agreed on what we like to do. One problem is the textual description of the pipeline. Dot supports many formats [1], but I miss ascii-art. SO I googled and found an interesting perl module Graph::Easy. I'll give that a try soon and upload a result. [1] http://www.graphviz.org/doc/info/output.html [2] http://bloodgate.com/perl/graph/manual/overview.html
Created attachment 143116 [details] test output from Graph::Easy I had to tweak the dot file a bit, but even then its not producing the correct output right now. I will attach a conversion script too.
Created attachment 143117 [details] convert a dot to ascii art using Graph::Easy I am filing bugs about the issues right now.
Links for the Graph::Easy package https://rt.cpan.org/Public/Bug/Display.html?id=49675 http://rt.cpan.org/Public/Bug/Display.html?id=49676
If I read the bug correctly then this issue is valid and worth to fix thing. Also, I don't see information from the reporter missing. I am thus reopening.
I think that with the dotfile stuff this bug is basically sorted, ok it is not a human readable textfile dump, but personally I like the pngs better. So while this might be a future nice to have (human readable text dump), I think currently this is just a bug cluttering up bugzilla. Closing as fixed.