Possible bad interaction with GStreamer registry
Closed this issue · 5 comments
To avoid scanning every module/plugin on startup, GStreamer has a binary registry caching that information. It will update that registry when modules change, the directory mtime changes, or when some directory given by the plugin changes, for example in:
https://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/gst/gio/gstgio.c#n246
The gio plugin will be reprobed when GIO_MODULE_DIR or GIO_GVFS_MOUNTS_DIR change.
The first problem might be that comparing dates won't necessarily work properly:
-rwxr-xr-x 2 hadess hadess 16660760 Jan 1 1970 libgstlibav.so
The second problem is that, for gvfs to work properly, we need to have access to the gvfs daemon via D-Bus. If you first ran an application that requires GStreamer without gvfs daemon being accessible, GStreamer would save that only "file" is accessible in its registry. Adding access to the gvfs daemon won't trigger a rescan.
Got a similar issue: I use gvfs-set-attribute to change the SparkleShare folder icon but it's not working. Sounds like it could be that there's no access to gvfs-daemon as well.
Got a similar issue: I use gvfs-set-attribute to change the SparkleShare folder icon but it's not
working. Sounds like it could be that there's no access to gvfs-daemon as well.
No, totem has access to gvfs:
https://github.com/alexlarsson/gnome-apps-nightly/blob/master/org.gnome.Totem.json#L32
The gstreamer people said the registry also checks sizes as well as dates, so its probably good enough. And the registry is per-app so cross-app issues will not cause registry issues.
The cases which are problematic are:
- Runtime or app is updated and plugins changed, but no sizes changed (unlikely)
- The same app is started twice with different access to gvfs (either because of permissions or because gvfs was installed/uninstalled on the host)
- A new gvfs mount daemon is installed on the host (will not change GVFS_MOUNTS_DIR in the runtime)
I'm not sure how to best handle this though. You can read the current access to gvfs by looking at /run/user/1000/xdg-app-info, but who would do that? gstreamer?
The problem happens, in this specific case, when the capabilities of the plugin change indirectly because of new permissions being attributed. Maybe xdg-app could have a file somewhere which would expose when the last permission changes were made, and have GStreamer watch that.
This would also solve the problem for other types of caches when permission changes should have the cache refreshed.
This issue was moved to flatpak/flatpak#9