Issue with registry.x86_64.bin

[Simon Michnowicz]

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.

Are there any tools that we could use to generate this file to confirm that this is in fact the problem?

Thanks for any assistance given

regards

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Jan Alexander Steffens]

On Tue, May 2, 2017 at 9:44 AM Simon Michnowicz <[hidden email]> 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.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Jan Alexander Steffens]

On Tue, May 2, 2017 at 9:55 AM Jan Alexander Steffens <[hidden email]> wrote:

On Tue, May 2, 2017 at 9:44 AM Simon Michnowicz <[hidden email]> wrote:

I have traced this delay to a file, ~/.gstreamer-0.10/registry.x86_64.bin

If the file is missing, just running gst-inspect-1.0 should be enough to regenerate it.

 

Ah, correction: It should be gst-inspect-0.10. GStreamer 0.10, unfortunately, is EOL.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim Müller]

On Tue, 2017-05-02 at 17:38 +1000, Simon Michnowicz wrote:

Hi Simon,

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

This should take seconds at most really, and be barely noticable on a
server system. 40+ minutes is a bit crazy, you'll have to debug why
that is so slow and what it's doing all this time. You can delte the
file and then run GST_DEBUG=*:6 gst-inspect-0.10 coreelements for
example to see what's going on.

And as was already pointed out, GStreamer 0.10 is no longer supported
or maintained, you should use 1.x instead (though I suspect you have
not much choice if it's a commercial application).

Cheers
 -Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[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

On 2 May 2017 at 17:55, Jan Alexander Steffens <[hidden email]> wrote:

On Tue, May 2, 2017 at 9:44 AM Simon Michnowicz <[hidden email]> 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.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[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

On 2 May 2017 at 17:55, Jan Alexander Steffens <[hidden email]> wrote:

On Tue, May 2, 2017 at 9:44 AM Simon Michnowicz <[hidden email]> 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.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel