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 490067 - eog does not sniff mime type
eog does not sniff mime type
Status: RESOLVED OBSOLETE
Product: eog
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: EOG Maintainers
EOG Maintainers
: 550163 553206 555452 561162 563264 588505 589407 618757 619133 643980 740587 749689 785976 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-10-25 08:43 UTC by Gabor Kelemen
Modified: 2021-02-13 18:32 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
Screenshot showing the inconsistent behavior (63.22 KB, image/png)
2007-10-25 08:44 UTC, Gabor Kelemen
  Details
preliminary patch doing the essential sniffing (4.89 KB, patch)
2008-11-17 17:05 UTC, Felix Riemann
none Details | Review

Description Gabor Kelemen 2007-10-25 08:43:11 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.
Comment 1 Gabor Kelemen 2007-10-25 08:44:49 UTC
Created attachment 97821 [details]
Screenshot showing the inconsistent behavior
Comment 2 Claudio Saavedra 2007-10-25 12:31:22 UTC
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.
Comment 3 Felix Riemann 2007-10-25 17:22:19 UTC
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).
Comment 4 Claudio Saavedra 2007-10-25 17:58:47 UTC
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.
Comment 5 Felix Riemann 2007-10-26 10:50:15 UTC
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.
Comment 6 Josselin Mouette 2008-01-09 14:09:41 UTC
Yes, TTBOMK GnomeVFS caches the MIME information.

Another bug about this issue: http://bugs.debian.org/459839
Comment 7 Claudio Saavedra 2008-01-09 14:38:39 UTC
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)
Comment 8 Felix Riemann 2008-01-10 22:56:21 UTC
(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.
Comment 9 Felix Riemann 2008-09-01 12:51:45 UTC
*** Bug 550163 has been marked as a duplicate of this bug. ***
Comment 10 Claudio Saavedra 2008-09-22 04:34:37 UTC
*** Bug 553206 has been marked as a duplicate of this bug. ***
Comment 11 Claudio Saavedra 2008-10-13 08:17:56 UTC
*** Bug 555452 has been marked as a duplicate of this bug. ***
Comment 12 Claudio Saavedra 2008-11-17 10:06:31 UTC
*** Bug 561162 has been marked as a duplicate of this bug. ***
Comment 13 Felix Riemann 2008-11-17 17:05:38 UTC
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.
Comment 14 Felix Riemann 2009-07-14 13:18:16 UTC
*** Bug 588505 has been marked as a duplicate of this bug. ***
Comment 15 Felix Riemann 2009-11-26 12:45:55 UTC
*** Bug 589407 has been marked as a duplicate of this bug. ***
Comment 16 Felix Riemann 2010-03-07 18:36:27 UTC
*** Bug 563264 has been marked as a duplicate of this bug. ***
Comment 17 Claudio Saavedra 2010-05-16 08:14:17 UTC
*** Bug 618757 has been marked as a duplicate of this bug. ***
Comment 18 Claudio Saavedra 2010-05-19 21:46:49 UTC
*** Bug 619133 has been marked as a duplicate of this bug. ***
Comment 19 Claudio Saavedra 2011-03-05 23:50:29 UTC
*** Bug 643980 has been marked as a duplicate of this bug. ***
Comment 20 Felix Riemann 2014-11-26 19:30:03 UTC
*** Bug 740587 has been marked as a duplicate of this bug. ***
Comment 21 Felix Riemann 2015-10-25 17:04:54 UTC
*** Bug 749689 has been marked as a duplicate of this bug. ***
Comment 22 Felix Riemann 2017-09-19 12:30:58 UTC
*** Bug 785976 has been marked as a duplicate of this bug. ***
Comment 23 Felix Riemann 2021-02-13 18:32:03 UTC
Obsoleted by Gitlab issue 25:
https://gitlab.gnome.org/GNOME/eog/-/issues/25