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 696579 - registry update should set older timestamp on registry
registry update should set older timestamp on registry
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal minor
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-03-25 18:54 UTC by David Schleef
Modified: 2018-05-06 10:56 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David Schleef 2013-03-25 18:54:49 UTC
The race:

 - package manager starts updating plugin files
 - some app starts up, which starts updating registry
 - package manager updates a few more plugins
 - registry gets written, with current timestamp

There's a window of opportunity for some plugins to be installed, but not included in the new registry.

I suggest setting the timestamp of the file to the time when the registry information gathering started.
Comment 1 Sebastian Dröge (slomo) 2013-04-23 07:32:54 UTC
From looking at the code it seems that the timestamp of the registry file does not matter at all. For each plugin the mtime is stored, and during scanning of plugins only this stored mtime is compared to the actual mtime on the file system. And the latest mtime is used for storing in priv_gst_registry_binary_write_cache().

Would you suggest storing the time of the registry creation, and then just check plugin_mtime <= registry_mtime when scanning all plugins?
Comment 2 Tim-Philipp Müller 2013-12-07 00:38:15 UTC
Not sure I understand where the problem is. The timestamp of the registry itself doesn't matter, only the mtimes from the stat() call on the plugins are saved.

Dave?
Comment 3 João Matos 2014-12-04 15:56:37 UTC
I believe I was affected by this bug.

I was trying to get support for H.264 video on Iceweasel (Firefox rebrand), on a Debian GNU/Linux system, but it failed to work with every combination of installed GStreamer packages I attempted.

Then I tried starting Iceweasel with a fake HOME and it worked.
I used strace to find exactly what files Iceweasel was looking at from my home, and I found it opened $HOME/.cache/gstreamer-1.0/registry.x86_64.bin

Removing that file caused it to be generated anew and solved the problem.

I'm keeping a copy of both the problematic registry file and the one that was generated to substitute its removal, and I can provide them if they're of any interest, provided confirmation that they don't contain identifying information or secrets.
Comment 4 Vivia Nikolaidou 2018-05-06 10:56:18 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment.

João, what you're describing is a different issue. Please open a new bug for it.

Thanks!