GNOME Bugzilla – Bug 613876
2.11 does not show thumbnails on importing any more
Last modified: 2010-04-26 16:43:39 UTC
I have a libgphoto2 supported camera (no UMS). With 2.10 (or F-Spot, etc.) I get thumbnails for photos just fine, and libgphoto2 supports them well. But with 2.11 I do not get them any more in the import dialog. That makes it impossible to pick the photos you are interested in.
a similar problem was fixed some time ago, what version are you using?
We have 2.11.2.1 right now.
Does Nautilus show the thumbnails if you browse to the camera mount? What camera do you have? Are you plugging it in directly? Does it work if you use a card reader instead? What version of gvfs-gphoto2 do you have? It works here with my cameras... - Mike
(In reply to comment #3) > Does Nautilus show the thumbnails if you browse to the camera mount? I do. However, I think it's cheating there, it downloads the full pictures and thumbnails itself. libgphoto2 supports the thumbnails as they are stored on the camera, but the gvfs gphoto backend does not currently have a way to expose them to gvfs/gio/nautilus. gthumb 2.10 used libgphoto2 directly, and thus had access to the entire feature set including thumbnails. > What camera do you have? Canon PowerShot SX-200. > Are you plugging it in directly? Yes, through its USB port. It speaks PTP, but not UMS. > Does it work if you use a card reader instead? Ah, after some thinking I remembered that my Sony e-book reader has an SD card reader :) I plugged in the ebook and the camera card, and get a normal UMS mount. I do see thumbnails in gthumb, but again they are very slow. UMS does not expose the camera-internal thumbnails either apparently, so it has to create the thumbs from the full pictures, I figure? > What version of gvfs-gphoto2 do you have? gvfs 1.5.5. > It works here with my cameras... Do you use UMS only? Or PTP? Thanks!
Martin, I use both Fuji PTP cameras and UMS card readers (for my older Canon), and they both seem to work. Yes, UMS thumbnails are slow because we can't use gphoto to access them any more. It's a trade-off for using gvfs-gphoto2. The gvfs-gphoto2 backend is supposed to extract the thumbnails for apps (gThumb) to use, via G_FILE_ATTRIBUTE_PREVIEW_ICON. Your thumbnails should be provided that way. Further investigation is needed. Try mounting your camera, and then see if gvfs-info indicates the presence of a preview::icon in the file. For example: [mjc@xena 101_FUJI]$ gvfs-info gphoto2://[usb:001,007]/DCIM/101_FUJI/DSCF1910.JPG display name: DSCF1910.JPG name: DSCF1910.JPG type: regular size: 1489531 attributes: standard::type: 1 standard::is-hidden: FALSE standard::name: DSCF1910.JPG standard::display-name: DSCF1910.JPG standard::icon: image-jpeg, gnome-mime-image-jpeg, image-x-generic standard::content-type: image/jpeg standard::fast-content-type: image/jpeg standard::size: 1489531 id::filesystem: gphoto2:host=%5Busb%3A001%2C007%5D access::can-read: TRUE access::can-write: TRUE access::can-execute: FALSE access::can-delete: TRUE access::can-trash: FALSE access::can-rename: TRUE time::modified: 1269523380 time::modified-usec: 0 preview::icon: GVfsIcon:0x15da440 ^^^ thumbnail present here - Mike
(In reply to comment #5) > The gvfs-gphoto2 backend is supposed to extract the thumbnails for apps > (gThumb) to use, via G_FILE_ATTRIBUTE_PREVIEW_ICON. Your thumbnails should be > provided that way. Ah, interesting. > Further investigation is needed. Try mounting your camera, and then see if > gvfs-info indicates the presence of a preview::icon in the file. Indeed I have that, too: $ gvfs-info $ gvfs-info gphoto2://[usb:001,022]/DCIM/100CANON/IMG_0001.JPG display name: IMG_0001.JPG name: IMG_0001.JPG type: regular size: 2015526 attributes: standard::type: 1 standard::is-hidden: FALSE standard::name: IMG_0001.JPG standard::display-name: IMG_0001.JPG standard::icon: image-jpeg, gnome-mime-image-jpeg, image-x-generic standard::content-type: image/jpeg standard::fast-content-type: image/jpeg standard::size: 2015526 id::filesystem: gphoto2:host=%5Busb%3A001%2C022%5D access::can-read: TRUE access::can-write: TRUE access::can-execute: FALSE access::can-delete: TRUE access::can-trash: FALSE access::can-rename: TRUE time::modified: 1267262089 time::modified-usec: 0 thumbnail::path: /home/martin/.thumbnails/normal/ecaf95f1dccecde734823f58fc697365.png preview::icon: GVfsIcon:0x1925f20 That also explains why nautilus actually displays the thumbnails without a noticeable delay, while they take ages when I mount it as UMS through the ebook card reader. I should perhaps note that when I select the camera in gthumb in the side bar, thumbnails appear instantly. Is that cached, or also read from gvfs' thumbnails? It just doesn't seem to work in the import dialog.
Oh, I made an interesting discovery, I think. Case 1: * Plug in camera * Select gthumb in the volume handling dialog * No thumbnails in gthumb import dialog Case 2: * Plug in camera * Do nothing in volume handling dialog * Open gthumb, File->Import From -> Removable Device -> My camera * No thumbnails in gthumb import dialog Case 3: * Plug in camera * Select "browse" in volume handling dialog * Go into DCIM in nautilus, see all the pictures; all thumbnails appear within a second (some 40 pics) * Open gthumb, File->Import From -> Removable Device -> My camera * Thumbnails in import dialog appear! Case 4: * Plug in camera * Do nothing in volume handling dialog * Open gthumb, select camera in side bar, browse to DCIM/ * No thumbnails appear in the gthumb viewer So it seems that thumbnails in the import dialog work once nautilus has shown them once.
Well, that shows that gnome-desktop-thumbnail is reading the thumbnail cache fine, but is having trouble generating a new thumbnail if none exists. It should read the preview icon here: http://git.gnome.org/browse/gnome-desktop/tree/libgnome-desktop/gnome-desktop-thumbnail.c#n153 ... which should be provided by the gvfs-gphoto2 backend: http://git.gnome.org/browse/gvfs/tree/daemon/gvfsbackendgphoto2.c#n1249 Dunno what's wrong... - Mike
I think we have to read the G_FILE_ATTRIBUTE_PREVIEW_ICON attribute and use that icon as preview image.
Wait a minute... Are we using an internal (obsolete) copy of gnome-desktop-thumbnail.c? The internal copy doesn't access the preview icon. The one at http://git.gnome.org/browse/gnome-desktop/tree/libgnome-desktop/gnome-desktop-thumbnail.c#n153 does. - Mike
You are right, it should be updated. Please update and test it, I think this should fix the bug.
Updated? Shouldn't the internal copy be removed entirely, and be replaced with gnome-desktop-2.0? - Mike
I would like to avoid the gnome-desktop dependency for just one file.
OK, I have copied and committed the latest version of gnome-desktop-thumbnail.c (keeping the gthumb-specific gnome_desktop_thumbnail_factory_generate_thumbnail_async and gnome_desktop_thumbnail_factory_load_from_tempfile functions). Martin, could you test the latest git version to see if it fixes your missing thumbnail issue? Paolo, is there really a case where gThumb 2.11 would be operating without the gnome-desktop-2.0 library? I really dislike internal library copies... - Mike
Paolo, Could you check one thing in my last commit: - g_free (priv); - factory->priv = NULL; I'm not sure that should have been removed. - Mike
(In reply to comment #15) > Paolo, > > Could you check one thing in my last commit: > > - g_free (priv); > - factory->priv = NULL; > > I'm not sure that should have been removed. > It's correct, there is no need to free the priv pointer when g_type_class_add_private is used to specify the private data.
I built trunk. I now get the camera appearing on hotplug, and gthumb crashing when I disconnect it (as a confirmation for myself that I am really running the git head one instead of the system one), but I still do not see thumbnails :( Is there some debugging mode I could use? Thanks a lot for your efforts!
(In reply to comment #14) > > Paolo, is there really a case where gThumb 2.11 would be operating without the > gnome-desktop-2.0 library? I really dislike internal library copies... > I'm going to personalize the code to allow the exiv2 extension to read the thumbnail from the exif metadata, to speed-up thumbnail generation for jpeg and tiff images.
Hmm. Did you un-install the packaged gthumb before installing the git version? If libraries end up in the wrong spots they can conflict and cause crashes. Can you run gthumb from gdb ("gdb gthumb", then "run", get a backtrace ("thread apply all bt"), and file a bug report for the crash? "debugging mode" mostly consists of sticking in some printf functions :-) I'll look at it more closely when time permits. I can't reproduce the no-thumbnail issue, though, but I will look and see if gphoto is providing the thumbnails from my camera (or something else). - Mike
> I'm going to personalize the code to allow the exiv2 extension to read the > thumbnail from the exif metadata, to speed-up thumbnail generation for jpeg and > tiff images. Oh, cool! Keep in mind that some sanity checks will be needed to handle orientation issues and out-of-date thumbnails. (gThumb 2.10.x didn't update embedded thumbnails properly, as you know...) Checking the aspect ratio of the thumbnail might be a good idea (to find out-of-date thumbnails in rotated or cropped images). - Mike
Paolo, I've been poking around in the thumbnailing code, although I don't understand it all yet. However, I don't think gThumb ever reads the system thumbnails (in ~/.thumbnails). It seems to run an image loader every time. Is this intentional? In other words, the new gnome-desktop-thumbnail.c is not used to read thumbnails. Thumbnails are being saved, however. - Mike
Never mind my last comment. It's more complicated than that... - Mike
(In reply to comment #17) > I built trunk. I now get the camera appearing on hotplug, and gthumb crashing > when I disconnect it (as a confirmation for myself that I am really running the > git head one instead of the system one), but I still do not see thumbnails :( > > Is there some debugging mode I could use? > please try again current master, and if it crashes again a stacktrace is very useful, thanks.
(In reply to comment #22) > Never mind my last comment. It's more complicated than that... > > - Mike Actually I think your comment was correct. I've changed the code to give priority to gnome_desktop_thumbnail_factory_generate_thumbnail and if it fails the image_loader will be used as fall back, see the thumb_loader() function in gth-thumb-loader.c
Yes, the thumbnails are much faster now! Great! Does it work for you now Martin? - Mike
I tried it again, and indeed it worked on the first try, but not any more on the second and third :-( Thanks, Martin
(In reply to comment #23) > please try again current master, and if it crashes again a stacktrace is very > useful, thanks. I filed the crash on switching off the camera as bug 614219 (it's unrelated to the thumbnail problem).
BTW, in both the crash and this thumbnail problem I noticed that there are two gvfs mounts, one is a "shadowed" one (whatever that means): $ gvfs-mount -li Volume(0): Canon Digital Camera Type: GProxyVolume (GProxyVolumeMonitorGPhoto2) ids: unix-device: '/dev/bus/usb/001/011' activation_root=gphoto2://[usb:001,011]/ themed icons: [camera-photo] can_mount=1 can_eject=0 should_automount=1 Mount(0): Canon Digital Camera -> gphoto2://[usb:001,011]/ Type: GProxyShadowMount (GProxyVolumeMonitorGPhoto2) default_location=gphoto2://[usb:001,011]/ themed icons: [camera-photo] x_content_types: x-content/image-dcf can_unmount=1 can_eject=0 is_shadowed=0 Mount(0): Canon Digital Camera -> gphoto2://[usb:001,011]/ Type: GDaemonMount default_location=gphoto2://[usb:001,011]/ themed icons: [camera-photo] [camera] x_content_types: x-content/image-dcf can_unmount=1 can_eject=0 is_shadowed=1 Is that normal?
(In reply to comment #26) > I tried it again, and indeed it worked on the first try, but not any more on > the second and third :-( > please explain precisely what you refer to when you say "it worked": thumbnail creation, file import, etc.
(In reply to comment #29) > please explain precisely what you refer to when you say "it worked": thumbnail > creation, file import, etc. Sorry. I mean the thumnails in the import dialog were shown once (but not on subsequent tries). File import etc. has always worked well.
Martin, Were you importing the same photos each time, or different photos? - Mike
Same photos. I haven't touched the pics on the camera for days, to provide a stable and consistent test case.
Current master gives priority to the preview::icon property now, this hopefully should fix this bug as well.
Confirming, works great now. Thanks a lot! Closing, since I was the original reporter.