Issue with registry.x86_64.bin

[Simon Michnowicz]

Jan
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
registry.x86_64.bin./.cache/gstreamer-1.0/registry.x86_64.bin./.gstreamer-0.10/registry.x86_64.bin*

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

regards
Simon



*---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/20170502/45d4a48f/attachment.html>