GNOME Bugzilla – Bug 597410
ext branch: command-line photo import doesn't work
Last modified: 2010-01-07 16:30:16 UTC
If I plug in my USB PTP camera, gthumb auto-launches the importer (after my latest commit), but it doesn't find any images. If I launch gThumb from the command line like this: gthumb --import-photos ~/.gvfs/gphoto2\ mount\ on\ usb%3A001\,003/ no images are found. (This is what the auto-imported should be calling.) If I use File->Import, it works OK. I suspect the current code doesn't recognize the ~/.gvfs mount point. The command-line import and the auto-importer work fine with flash cards mounted under /media (that is, not using the gvfs-gphoto backend). - Mike
*** Bug 594881 has been marked as a duplicate of this bug. ***
After putting some debugging printfs in, I get this: [mjc@xena gthumb]$ gthumb -i ~/.gvfs/gphoto2\ mount\ on\ usb%3A001\,002/ source is not null update_source_list start mount: Fuji Photo Film Co., Ltd USB PTP Camera volume is null In other words, the gphoto mount is not associated with a volume, which causes update_source_list to fail. I don't really understand why update_source_list checks for a volume, but that is the root of the problem. - Mike
Created attachment 145172 [details] quick and dirty debugging printfs
If I access (successfully) my camera using file->import, I get this debugging output, for comparison: [mjc@xena gthumb]$ gthumb source is null update_source_list start mount: Fuji Photo Film Co., Ltd USB PTP Camera volume: Fuji Photo Film Co., Ltd USB PTP Camera can mount root gphoto2://[usb:001,003]/ vs source gphoto2://[usb:001,003]/ mount: Fuji Photo Film Co., Ltd USB PTP Camera is shadowed
Using gthumb -i 'gphoto2://[usb:001,003]/' does not work either.
Maybe it's because there are two mounts (one shadowing the other) and the code is choosing the shadowed one? You need to ignore shadowed mounts, see http://library.gnome.org/devel/gio/unstable/GMount.html#g-mount-is-shadowed (the reason for shadowed mounts is to handle cameras with multiple storage heads - e.g. a single gphoto2 device with roots store00010001 and store00010002.) Anyway, here's what it looks like for me: Volume(0): iPhone Type: GProxyVolume (GProxyVolumeMonitorGPhoto2) ids: unix-device: '/dev/bus/usb/002/002' activation_root=gphoto2://[usb:002,002]/ themed icons: [camera-photo] can_mount=1 can_eject=0 should_automount=1 Mount(0): iPhone -> gphoto2://[usb:002,002]/ Type: GProxyShadowMount (GProxyVolumeMonitorGPhoto2) themed icons: [camera-photo] x_content_types: x-content/image-dcf can_unmount=1 can_eject=0 is_shadowed=0 Mount(1): iPhone -> gphoto2://[usb:002,002]/ Type: GDaemonMount themed icons: [camera-photo] [camera] x_content_types: x-content/image-dcf can_unmount=1 can_eject=0 is_shadowed=1
The real problem is that the code is checking for a non-null volume (and using g_volume_get_name). In David's output above, the non-shadow mount is not a child of a volume. I'm not up to speed on the subtleties of mounts and volumes, so I'll let someone else fix this. But that is the root of the problem. - Mike
No, ignore my last comment, the is_shadowed=0 mount does have a volume. Never mind...
The code must not assume g_mount_get_volume() or g_mount_get_drive() returns non-NULL. Sure this is true for (non-shadowed) gphoto2 GMount objects but for e.g. afc (for iPhone and iPod devices) GMount objects it may not be. And we may add other GVfs backends in the future. So the code needs to handle both situations. I'm not sure whether you guys use the x-content-type stuff yet. But you probably should. The idea is that a GMount is tagged with a x-content-type that describes the content of the mount similar to how files have a MIME types. For example, if there are pictures on the mount (e.g. a DCIM/ folder structure), then the GMount will have the x-content/image-dcf type. See http://cgit.freedesktop.org/xdg/shared-mime-info/tree/freedesktop.org.xml.in?id=Release-0-70#n5116 for x-content types. Another types of interest may be x-content/image-picturecd. Use this method http://library.gnome.org/devel/gio/unstable/GMount.html#g-mount-guess-content-type to get the content type. For example, in the import dialog, this enables you do create an UI with the content types you care about in the combo box, e.g. Import Photos From: [<ICON> Canon SD980 |V] <ICON> iPhone <ICON> EOS_DIGITAL Select folder... where the combo box has two items for mounts with the x-content type x-content/image-dcf, namely Canon SD980 (driven by the gphoto2 backend), iPhone (driven by the AFC backend) and EOS_DIGITAL (CF card; a normal mount at /media/EOS_DIGITAL). There's also a "Select Folder" option as a fallback option for the odd cases where the pictures are not stored in DCIM/ format. So, in short here are the guidelines you should be using 1. Always ignore shadowed GMount objects 2. You cannot assume that a GVolume or GDrive exists for a GMount 3. Include mounts with x-content/image-dcf in the import dialog 4. Always include a fallback option for when content guessing does not work. If you do this, then your application should be future-proof and Just Work(tm) when new GVfs backends are added. Hope this helps.
maybe just calling the import dialog in an idle callback fixes the problem, I've committed a patch to do this, Michael can you check please?
Thanks Paolo! The auto-launch importer works now. For some reason thumbnails are not generated for my camera's images, but that's a different bug. - Mike