GNOME Bugzilla – Bug 490067
eog does not sniff mime type
Last modified: 2021-02-13 18:32:03 UTC
I had a png image, which was renamed to .jpg. Tried to open in eog, which indicated there is an error and the image cannot be opened. But after turning on the collection view, the image's thumbnail appeared there correctly.
Created attachment 97821 [details] Screenshot showing the inconsistent behavior
My bet is that gdkpixbuf tries to load the image using the jpeg loader and fails in doing so, while the collection + libgnome (for thumbnailing) do an exhaustive file type check to realize that the image is actually a png file and therefore it's thumbnailable.
Yes, EOG tries to take the jpeg loader which won't work. We should possibly enable sniffing when determining the mime type (GNOME_VFS_FILE_INFO_FORCE_SLOW_MIME_TYPE). It'll hopefully doesn't slow everything down too much (getting the data for the tooltips could become a problem).
IIRC, we already do slow mime type check to decide which pictures to show in the collection view, so I don't think it can slow things more.
Yes, but we don't do it when determining which pixbuf loader to take (default settings there; properties dialog as well I think). I don't know if gnome-vfs does some caching, so I think we should move all the mime type detection calls into one function. The first part of EOG which needs the mime type would then detect it (using the slow tests) and save it in the EogImage object and it would only be rescanned if the file is changed. This should also reduce the file system work as IIRC we currently rescan it every time the tooltips are shown.
Yes, TTBOMK GnomeVFS caches the MIME information. Another bug about this issue: http://bugs.debian.org/459839
I like your approach Felix (don't know why I didn't comment earlier). The only thing that worries me is what would it happen if the MIME database changes, but maybe that's a very corner case and we shouldn't worry too much about it. So, what about adding: 1) Private gchar *mimetype, initially NULL. 2) const gchar *eog_image_get_mime_type (EogImage *image), which when firstly called, does a slow mime type check on the given image, and caches the result in the private gchar *mimetype, and in succesive calls uses it. and using it everywhere where we currently get the mimetype by hand. (If the approach is this simple, then I'd vouch for doing a gnome-love task of this)
(In reply to comment #7) > I like your approach Felix (don't know why I didn't comment earlier). The only > thing that worries me is what would it happen if the MIME database changes, but > maybe that's a very corner case and we shouldn't worry too much about it. I don't know for sure in what way (and how far) that could affect us. But, the major types we support are AFAIK IANA-registered and are hardcoded into the pixbuf loaders, so loading should still work even if the cache changes. > > So, what about adding: > > 1) Private gchar *mimetype, initially NULL. > 2) const gchar *eog_image_get_mime_type (EogImage *image), which when firstly > called, does a slow mime type check on the given image, and caches the result > in the private gchar *mimetype, and in succesive calls uses it. > > and using it everywhere where we currently get the mimetype by hand. > Yes, that's basically the idea behind it. I intended to wrap it in a GOnce as I'm a little unsure about thread-safety otherwise (the tooltips could interfere I think) (opinions?). This should work as long as we reset the metadata once the image changes either be reloading the metadata or by recreating the EogImage object (which is I think what we currently do). Josselin, GnomeVFS seems to only load (and use) the system mime cache, which AFAIK doesn't hold informations on a per-file basis. What I meant was if I check a file's mimetype consecutively it would only sniff once and use the cached data for the other calls.
*** Bug 550163 has been marked as a duplicate of this bug. ***
*** Bug 553206 has been marked as a duplicate of this bug. ***
*** Bug 555452 has been marked as a duplicate of this bug. ***
*** Bug 561162 has been marked as a duplicate of this bug. ***
Created attachment 122866 [details] [review] preliminary patch doing the essential sniffing This is a prelininary patch which is doing some sniffing during the loading process. It's using the gathered information during image loading only right now. The rest of the application makes no use of it yet.
*** Bug 588505 has been marked as a duplicate of this bug. ***
*** Bug 589407 has been marked as a duplicate of this bug. ***
*** Bug 563264 has been marked as a duplicate of this bug. ***
*** Bug 618757 has been marked as a duplicate of this bug. ***
*** Bug 619133 has been marked as a duplicate of this bug. ***
*** Bug 643980 has been marked as a duplicate of this bug. ***
*** Bug 740587 has been marked as a duplicate of this bug. ***
*** Bug 749689 has been marked as a duplicate of this bug. ***
*** Bug 785976 has been marked as a duplicate of this bug. ***
Obsoleted by Gitlab issue 25: https://gitlab.gnome.org/GNOME/eog/-/issues/25