Issue with registry.x86_64.bin

[Simon Michnowicz]

Dear Tim,
thank you for your suggestion of using
GST_DEBUG=*:6 gst-inspect-0.10
It turns out that enabling debug in this way make the gst-inspect-0.10
program work as we expect and return almost immediately.  (compared with
running gst-inspect-0.10 without it ).

I am not sure why this is happening. As we are running in an Openstack
(QEMU) environment it could be that the plugins are accessing an interface
that has a bug (i.e. we do not have audio hardware on the server but there
are plugins for audio).
Maybe debug mode does not delay on unresponsive interfaces?

It turns out that passing this environment variable to our commercial
program works too, i.e.
GST_DEBUG=*:6 vglrun CommercialPRogram
no longer delays on the first time we run

regards


*---Simon Michnowicz *
Senior Application Specialist,  High-Performance Computing

*Research Support Services - eSolutions*
*Monash eResearch Centre*
Monash University
15 Innovation Walk, Building 75, Clayton Campus
Wellington Road, VIC 3800
Australia

T:  +61 3 9902 0794
M: +61 3 0418 302 046
E: simon.michnowicz at monash.edu
monash.edu

On 2 May 2017 at 17:55, Jan Alexander Steffens <jan.steffens at gmail.com>
wrote:

> On Tue, May 2, 2017 at 9:44 AM Simon Michnowicz <
> simon.michnowicz at monash.edu> wrote:
>
>> Dear Gstreamer List,
>>
>> I am trying to debug a commercial application that uses Gstreamer. We are
>> running on a Centos 7 cluster with a variety of graphics cards (i.e. K80)
>> in an Openstack virtual environment.
>>
>>  When the program runs for the first time on a machine, a considerable
>> time delay occurs (40+ minutes) before the program initializes, although
>> subsequent runs start immediately.
>>
>> I have traced this delay to a file, ~/.gstreamer-0.10/registry.x86_64.bin
>> If you delete the file, we can trigger the very long delay when running
>> the program.
>>
>> I am not a Gsteamer developer, so would be very grateful if anybody could
>> advise me on how this file is created. We are very interested into why it
>> is taking so long to create. This could be a programming issue with the
>> commercial application, but it could also point to some very strange
>> interactions between Gstreamer and the virtual environment.
>>
>
> When GStreamer initializes, it loads metadata from all plugins.
> Internally, it forks a gst-plugin-scanner process to actually load the
> plugins (this shields the application process from crashes caused by bad
> plugins and/or libraries). The result of this is cached in the registry
> file.
>
> I would attempt to use fatrace (which observes filesystem accesses,
> system-wide) to watch the plugin scanner load plugins, in order to discover
> which plugin is causing a delay here.
>
>
>> Are there any tools that we could use to generate this file to confirm
>> that this is in fact the problem?
>>
>
> If the file is missing, just running gst-inspect-1.0 should be enough to
> regenerate it.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170505/2474a012/attachment.html>