After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 662889 - Identical gst-install-plugin-helper is queued multiple times
Identical gst-install-plugin-helper is queued multiple times
Status: RESOLVED NOTGNOME
Product: GStreamer
Classification: Platform
Component: gst-plugins
0.10.34
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-10-27 19:39 UTC by mpaklin
Modified: 2011-12-05 07:52 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description mpaklin 2011-10-27 19:39:39 UTC
I have Fedora Core 15 setup where some infrequently used plugins are missing. In particular audio/x-private-ts-lpcm decoder is not installed.

I have a stress test running in the browser. The test pulls multimedia stream over the network and has VLC plugin to play it. I don't know how, but GStreamer gets involved (I though VLC is not based on GStreamer).

GStreamer tries to find the plugin for a particular audio format and can't. So it ends up correctly informing the user that the plugin is missing and should be installed. All is well.

The problem is that the next time the same file is played, another instance of gst-install-plugin-helper gets queued. As soon as the user dismisses the "A program requires an additional plugin to decode this file" popup message, the next one comes right in.

After my stress test runs for a few hours, the system gets bogged down with gst-install-plugin-helper processes queued to display the same message.

The right solution should be to check if there is a pending messages to be displayed and not queue another instance of gst-install-plugin-helper to do the same thing.

Thanks!
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2011-11-28 08:29:34 UTC
First VLC is not based on gstreamer. If you get that message some gstreamer player is getting invoked (possibly the totem gstreamer browser plugin). Please also note that gstreamer does not contain UI parts. It would be the task of the UI to avoid multiple of such dialogs, but in your case I think the various instances of the player plugin don't even know about each other.

1.) check what software gets launch in your tests.
2.) play such a stream once in e.g. totem and install the missing plugin

Please reopen if you think this is a gstreamer bug and give more details.
Comment 2 Tim-Philipp Müller 2011-12-01 23:02:28 UTC
For what it's worth, totem maintains a blacklists of installer details, so if it has called the plugin installer for an installer detail once, it won't do that again (unless restarted). It's ultimately a policy-decision that needs to be taken in the levels higher than the missing plugin install mechanism in GStreamer (i.e. either in the application or the distro-provided installer).
Comment 3 mpaklin 2011-12-05 07:50:28 UTC
(In reply to comment #1)
> First VLC is not based on gstreamer. If you get that message some gstreamer
> player is getting invoked (possibly the totem gstreamer browser plugin). Please
> also note that gstreamer does not contain UI parts. It would be the task of the
> UI to avoid multiple of such dialogs, but in your case I think the various
> instances of the player plugin don't even know about each other.
> 
> 1.) check what software gets launch in your tests.
> 2.) play such a stream once in e.g. totem and install the missing plugin
> 
> Please reopen if you think this is a gstreamer bug and give more details.

Yes, I know that VLC is not based on gst. The app (stress test, actually) uses VLC browser plugin for media playback.
I have no idea how gst gets in the picture (VLC can't play a particular format and attempts to use OS default player?), but it does somehow get involved.

Given the fact that gst does not handle the UI aspect of this problem, I agree with you that this issue is not gst problem. I will try to open another bug against Fedora distro (assuming that I can repro it on FC16, which I just installed).

Thanks!
Comment 4 mpaklin 2011-12-05 07:52:45 UTC
(In reply to comment #2)
> For what it's worth, totem maintains a blacklists of installer details, so if
> it has called the plugin installer for an installer detail once, it won't do
> that again (unless restarted). It's ultimately a policy-decision that needs to
> be taken in the levels higher than the missing plugin install mechanism in
> GStreamer (i.e. either in the application or the distro-provided installer).

Agreed.
I will take it up with Fedora to see if this can be handled better.

I cannot do it from the app as the app is browser based and has no access to that level of details.

Thanks!