Issue with registry.x86_64.bin

Simon Michnowicz simon.michnowicz at
Tue May 2 08:39:31 UTC 2017

thanks for the info.
The* gst-inspect-1.0 *returned immediately,  but when I ran the program
*gst-inspect-10* it took >1 minute to finish.
Do you know what the difference between these programs are?

One placed  a file in ~/.cache.
Another in ~/.gstreamer.

*find . -name

The two files are different. Is this to be expected?


*---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

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

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

> On Tue, May 2, 2017 at 9:44 AM Simon Michnowicz <
> simon.michnowicz at> 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: <>

More information about the gstreamer-devel mailing list