[gstreamer-bugs] [Bug 604094] registry: do not remove features when removing a cached plugin that no longer is present

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=604094
  GStreamer | gstreamer (core) | git

--- Comment #3 from Håvard Graff (hgr) <havard.graff at tandberg.com> 2010-07-17 20:00:57 UTC ---
I must admit that I dont quite remember all the details around this patch, as
it was a few hours of intense debugging in a part of gstreamer I had never
ventured into before (and not since either!). :)

However, the patch still stands AFAIAC. If I remember correctly, the first
thing that happends is that all plugins are loaded from the registry, then it
searches for all plugins on the system, and then any that are in the registry,
but not on the system, is to be removed, and as part of the removal is calling
gst_registry_remove_features_for_plugin_unlocked, but the thing is that if the
plugin did only exist in the registry, and not on the system, it would be
impossible for it to have had registered its features, since this happens
through the element. (and the element is not there!)

We discovered this because we renamed a plugin, so that our registry had the
old name, but the feature (the gstreamer element) was still the same, so that
something like this would happen:

1) old.plugin with feature A is found in registry
2) new.plugin with feature A is found on the system, old.plugin is not
3) new.plugin feature A is registered
4) old.plugin is removed from the registry, and part of this process is
removing feature A
5) Our app ended up not finding feature A (not registered)

The patch basically says that removing a feature for a removed plugin like this
does not make any sense at all, because it cant have been registered if the
plugin did not exist!

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.