gthumb doesn't work with gphoto (was please disable gphoto2 backend for Jaunty)

Bug #351122 reported by Martin-Éric Racine on 2009-03-29
42
This bug affects 4 people
Affects Status Importance Assigned to Milestone
gThumb
Confirmed
Unknown
gthumb (Ubuntu)
Undecided
Martin Pitt
Intrepid
Undecided
Unassigned
Jaunty
Undecided
Unassigned

Bug Description

The gphoto2 backend hampers operation with gthumb, because the backend locks the camera device which then makes it impossible for gThumb to lock it when fetching pictures. I'd thus prefer if there was an option to completely disable the backend, because it stubbornly insists upon mounting the camera to desktop, which is what prevents gThumb from accessing it later on.

This has been broken since Intrepid, which is when the gphoto2 backend was introduced. I only learned of what is causing this by sheer accident, after talking to the gphoto2 upstream author, Hubert Figuiere who, for the record, also disagrees with the approach of entrusting GVFS with this.

Btw, telling Nautilus to lauch GThumb for camera devices doesn't fix anything, because the device is still locked by GVFS at that point. Telling Nautilus Don't Do Anything for cameras doesn't work either, because GVFS stubbornly insists upon mounting the camera to desktop.

I'll point out that this bug is a serious productivity killer, because it constantly forces me to go on the desktop, manually unmount the camera device and then launch gThmub separately, every time I need to fetch pictures from the camera. If I only had to do this occasionally, I might consider this an okay workaround, but I need to fetch pictures from my camera a number of times per day, so this bug really is a serious issue for me.

$ gphoto2 --auto-detect
Malli Portti
----------------------------------------------------------
Canon Digital IXUS 60 (PTP mode) usb:
Canon Digital IXUS 60 (PTP mode) usb:001,008

Chris Coulson (chrisccoulson) wrote :

Rather than disable gphoto, which works for the vast majority of users and applications, gthumb should be fixed to work properly if there is a problem. reassigning to gthumb

affects: gvfs (Ubuntu) → gthumb (Ubuntu)
summary: - please disable gphoto2 backend for Jaunty
+ gthumb doesn't work with gphoto (was please disable gphoto2 backend for
+ Jaunty)
Martin-Éric Racine (q-funk) wrote :

That's incorrect. gthumb works just fine with libgphoto2, as long as GVFS doesn't interfere by mounting the camera to desktop.

I'd also like to see such a "majority of user" confirm that there is no regression since the introduction of GVFS, before anyone goes and makes a generalization about everything working just fine for everyone else.

Chris Coulson (chrisccoulson) wrote :

F-spot works fine with this. gthumb should do what f-spot does and communicate using the gphoto:/// gvfs URI as opposed to trying to directly talk to the camera like it does now. This is how f-spot does it.

And how are you actually recreating this problem? The gthumb-import desktop file which Nautilus uses to launch gthumb when a camera is connected, contains a fix that has been in since Intrepid to actually unmount the gvfs mount before opening gthumb. This is what Nautilus executes when launching gthumb in response to you connecting your camera:

sh -c 'gvfs-mount -u "%U"; exec gthumb --import-photos'

This was implemented as the "fix" for bug 287689 in Intrepid, so if this is not working then this is most certainly a gthumb bug.

Martin-Éric Racine (q-funk) wrote :

That command line from /usr/share/applications/gthumb-import.desktop might work, but it would first have to make gthumb Recommends or even Depends upon gvfs-bin, in the first place, for this to remotely have a chance to work.

Even then, installing this missing dependency doesn't produce the desired result. At best, it makes that command line recipe stop failing to find 'gvfs-mount'.

Tips as to where to fetch logs that might show what went wrong are welcome.

Chris Coulson (chrisccoulson) wrote :

It seems that the real issue here is that gthumb has not yet been ported to GIO (see http://bugzilla.gnome.org/show_bug.cgi?id=525482)

Martin-Éric Racine (q-funk) wrote :

Find the debdiff attached for Jaunty. Intrepid needs a similar change in its debian/control.

Andrew (at-macmillan) wrote :

I'm having the same behaviour in a fully updated Jaunty here as well. No matter what I select in Nautilus's Media settings, I must manually unmount the Digital Camera icon on my desktop before gthumb --import will be able to see the camera.

According to the /usr/share/applications/gthumb-import.desktop file, I see it includes this line:

Exec=sh -c 'gvfs-mount -u "%U"; exec gthumb --import-photos'

However, this does not work. For one thing, the %U parameter only expands to ~/.gvfs, which is not enough information for the gvfs-mount command to properly unmount the card so no unmount occurs.

To fix it, I changed that line to the following:

Exec=sh -c 'gvfs-mount -u ~/.gvfs/gphoto2*; exec gthumb --import-photos'

This gives the gvfs-mount all the information it needs to properly unmount the card before calling gthumb.

This works on my system. With the nautilus media settings to "Open gThumb Image Viewer", the gthumb import dialog box pops up when I plug in the camera and I can import the photos like expected. Perhaps somebody else can test this or see a better way to fix the issue.

Martin Pitt (pitti) wrote :

The main issue was fixed in intrepid in this SRU:

gthumb (3:2.10.10-0ubuntu1.1) intrepid-proposed; urgency=low

  * Add 04-nautilus-import.patch: Provide a gthumb-import.desktop which works
    with nautilus and gphoto cameras. (LP: #287689)
  * 09-autoconf.patch: Refresh, previous patch touches data/Makefile.am.

 -- Martin Pitt < <email address hidden>> Tue, 11 Nov 2008 16:02:26 +0100

We won't do another SRU for the depenency change. It does not meet the SRU criteria, and gvfs-bin is installed by default.

Changed in gthumb (Ubuntu Intrepid):
status: New → Won't Fix
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gthumb - 3:2.10.10-0ubuntu4

---------------
gthumb (3:2.10.10-0ubuntu4) jaunty; urgency=high

  * Added Recommends: gvfs-bin for Nautilus integration (LP: #351122).

 -- Martin-Eric Racine <email address hidden> Mon, 30 Mar 2009 12:33:01 +0300

Changed in gthumb:
status: New → Fix Released
Martin-Éric Racine (q-funk) wrote :

Thanks for adding the Recommends for Jaunty.

However, the the GVFS unmounting desktop file also needs upgrading as suggested by the other contributor to this thread as, in its current form, it doesn't work, while his indeed does.

Martin Pitt (pitti) wrote :

Reopening, this was reported to not work any more in Jaunty ("%U" not expanded any more)

Changed in gthumb (Ubuntu Jaunty):
assignee: nobody → pitti
status: Fix Released → In Progress
mjc (mjc-avtechpulse) wrote :

Why doesn't %U expand to something more specific than ~/.gvfs?

- Mike

Andrew (at-macmillan) wrote :

> Why doesn't %U expand to something more specific than ~/.gvfs?

Sorry, I made a slight mistake, %U actually seems to expand to: ~/.gvfs/gphoto2

I know this because if you change that Exec line to:
Exec=sh -c 'xmessage %U'

you will get a pop-up upon camera insertion telling you to what %U expands. (~/.gvfs/gphoto2).

To show that such a directory path is not sufficient, if you plug in the camera and let it mount automatically and then run this command manually:
sh -c 'gvfs-mount -u ~/.gvfs/gnome2'

you will get this error message: "Error finding enclosing mount: Containing mount does not exist"

For reference, at this running on my computer, "ls ~/.gvfs/gnome2" shows the following:
gphoto2 mount on usb%3A001,007

So that's why I made the above suggestion to use the following command in the .desktop file to unmount the camera in order to make sure the full path of the camera is specified:
Exec=sh -c 'gvfs-mount -u ~/.gvfs/gphoto2*; exec gthumb --import-photos'

Also, as another/additional problem, the reason I removed the double quotes is because if you change that line to this:
Exec=sh -c 'xmessage "%U"'

you will not get any popup what-so-ever because the double quotes seem to prevent that line from executing.

So my conclusions were:
1. The %U is not expanding to provide enough information to unmount the camera.
2. The double quotes seem to cause a problem.

Disclaimer: I am not an expert. There may well be a better way to fix this issue. But hope this helps explain my logic behind the above suggestion.

Martin Pitt (pitti) on 2009-04-02
Changed in gthumb (Ubuntu Jaunty):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gthumb - 3:2.10.11-0ubuntu1

---------------
gthumb (3:2.10.11-0ubuntu1) jaunty; urgency=low

  * New upstream bug fix release:
    - #572342: Better IFD offset checking.
    - #570473: gthumb write to freed memory.
    - #568894: use gtk_widget_get_action (foo), instead of
      g_object_get_data (foo, "gtk-action").
    - #565708: Fixed default launch-with-gimp hotkey to launch gimp in
      the background.
    - #563956: Fixed XML comment reading.
    - #560055: filter problems
    - #560352: Added a new gthumb-import.desktop.in file to handle
      gvfs-mounted cameras more elegantly. The camera is first unmounted,
      and the libgphoto import routines are then run.
    - #557640: Set pagesize adjustment to zero for spinbuttons, to avoid
      annoying warnings.
    - #554149: Terminate "Converting comment system...done" with
      newline.
    - #555549: The "g" key now launches the "gimp" command, instead of
      the deprecated "gimp-remote" command.
    - Fix crasher bug in exif tag reading, caused by malformed tiff
      headers.
    - Give the photo-import desktop file different name parameters, so
      that users can distinguish it from the normal desktop file.
  * Drop patches accepted upstream:
    - 04-nautilus-import.patch
    - 10-spinbutton_adjustment.patch
  * Refresh patches for new upstream version.
  * Add bzr-builddeb configuration (merge mode).
  * debian/control: Set Vcs-Bzr.
  * Add 04-fix-gvfs-umount.patch: Fix up gphoto-import.desktop to work with
    current gvfs. Thanks to Andrew MacMillan for the suggestion! (LP: #351122)

 -- Martin Pitt <email address hidden> Thu, 02 Apr 2009 20:19:47 +0200

Changed in gthumb (Ubuntu Jaunty):
status: Fix Committed → Fix Released
Changed in gthumb:
status: Unknown → Confirmed
Paolo Benvenuto (donpaolo) wrote :

Doesn't work for me, I have ghtumb 3:2.10.11-0ubuntu1 installed and at connecting the camera, the gthumb import dialog tells me the device is locked, i.e. is the SD storage is mounted.

I think gthumb could act as f-spot, i.e. unmounting the storage before trying to import the photos, and then mounting it again when finishing importing the photos.

Changed in gthumb (Ubuntu Jaunty):
status: Fix Released → New
Martin Pitt (pitti) wrote :

Paolo, this bug is about libgphoto handled cameras, not mass storage. Can you please ensure that you have a PtP camera? Please supply "gvfs-mount -l" output after plugging it in. Thanks!

Thomas Ohms (tohms) wrote :

Waiting for an answer from Paolo.

Changed in gthumb (Ubuntu Jaunty):
status: New → Incomplete
Paolo Benvenuto (donpaolo) wrote :

After connecting and switching on the camera:

$ lsusb
Bus 001 Device 011: ID 04a9:3126 Canon, Inc.
Bus 001 Device 002: ID 18a5:0214
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

$ gvfs-mount -l
Drive(0): Unità CD-RW/DVD±RW
  Type: GProxyDrive (GProxyVolumeMonitorHal)
Drive(1): Unità USB
  Type: GProxyDrive (GProxyVolumeMonitorHal)
  Volume(0): EsternoFAT
    Type: GProxyVolume (GProxyVolumeMonitorHal)
    Mount(0): EsternoFAT -> file:///media/EsternoFAT
      Type: GProxyMount (GProxyVolumeMonitorHal)
  Volume(1): EsternoEXT3
    Type: GProxyVolume (GProxyVolumeMonitorHal)
    Mount(0): EsternoEXT3 -> file:///media/EsternoEXT3
      Type: GProxyMount (GProxyVolumeMonitorHal)
Volume(0): Canon, Inc. Canon Digital Camera
  Type: GProxyVolume (GProxyVolumeMonitorGPhoto2)
  Mount(0): Canon, Inc. Canon Digital Camera -> gphoto2://[usb:001,011]/
    Type: GProxyShadowMount (GProxyVolumeMonitorGPhoto2)
Mount(0): Canon, Inc. Canon Digital Camera -> gphoto2://[usb:001,011]/
  Type: GDaemonMount

and drivemount_applet2 shows 2 mounted cameras icons.

$ mount
/dev/sda1 on / type ext3 (rw,relatime,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,nosuid,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
lrm on /lib/modules/2.6.28-11-server/volatile type tmpfs (rw,mode=755)
/dev/sda6 on /home type ext3 (rw,relatime)
/dev/sda7 on /home/media type ext3 (rw,relatime)
securityfs on /sys/kernel/security type securityfs (rw)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
/dev/sdb1 on /media/EsternoFAT type vfat (rw,nosuid,nodev,uhelper=hal,shortname=mixed,uid=1000,utf8,umask=077,flush)
/dev/sdb2 on /media/EsternoEXT3 type ext3 (rw,nosuid,nodev,uhelper=hal)
gvfs-fuse-daemon on /home/paolo/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=paolo)
/home/paolo/.Private on /home/paolo/Private type ecryptfs (ecryptfs_sig=xzzzzzzzzzzzzzz,ecryptfs_fnek_sig=xxxxxxxxxxxxxxxxxxxx,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)

Unmounting the camera from the applet, one of the 2 camera icons in the applet disappair; mounting again the camera from the same applet makes the applet crash. Relaunching the applet shows 2 camera icons again.

Changed in gthumb (Ubuntu Jaunty):
status: Incomplete → New
Paolo Benvenuto (donpaolo) wrote :

$ gphoto2 --auto-detect
Modello Porta
----------------------------------------------------------
Canon PowerShot A530 (PTP mode) usb:
Canon PowerShot A530 (PTP mode) usb:001,012

Mark Alan (malan) wrote :

Same problem here.

But, I am able to import the pictures if:
  a) connect the camera
  b) run from the command line:
            gthumb --import-photos
      or,
            gnome-volume-manager-gthumb

$ cat /etc/issue
Ubuntu 9.04 \n \l

$ uname -a
Linux mail.example.com 2.6.28-13-generic #44-Ubuntu SMP Tue Jun 2 07:57:31 UTC 2009 i686 GNU/Linux

$ lsusb
Bus 001 Device 020: ID 04a9:311c Canon, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

$ gvfs-mount -l
Drive(0): CD-RW/DVD±RW Drive
  Type: GProxyDrive (GProxyVolumeMonitorHal)
Drive(1): Mass Storage Drive
  Type: GProxyDrive (GProxyVolumeMonitorHal)
  Volume(0): win_xp
    Type: GProxyVolume (GProxyVolumeMonitorHal)

$ mount
...
gvfs-fuse-daemon on /home/example/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=mark)
gvfs-fuse-daemon on /root/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev)

stephane (dragon-orange) wrote :

for Andrew's modification of /usr/share/applications/gthumb-import.desktop file to work on french Jaunty,
i added a second stroke just before "gphoto2" :

Exec=sh -c 'gvfs-mount -u ~/.gvfs/*gphoto2*; exec gthumb --import-photos'

because in ~/.gvfs , my camera folder's name looks like "Montage de gphoto2 sur usb:xxx,xxx"
so i guess it must be likely the same with several others languages distributions...

thanks for the new gthumb-import.desktop!

Hello,
Same problem :
- my Canon A710 appears twice in Nautilus after being powered on
- gthumb can't access to it ("camera is being used")
I must unmount the camera in Nautilus then manually run gthumb to be able to import my photos.
For me, it was OK on Hardy and previous versions and this problem appeared with Jaunty.

Jaunty up to date on a fresh install and ghtumb 3:2.10.11-0ubuntu1

gvfs-mount -l
Drive(0): Lecteur de stockage de masse
  <~ 10 lines : main hard drive>
Drive(1): Lecteur CD-RW/DVD±RW
  Type: GProxyDrive (GProxyVolumeMonitorHal)
Volume(0): Canon, Inc. PowerShot A710 IS <== my camera
  Type: GProxyVolume (GProxyVolumeMonitorGPhoto2)
  Mount(0): Canon, Inc. PowerShot A710 IS -> gphoto2://[usb:001,006]/
    Type: GProxyShadowMount (GProxyVolumeMonitorGPhoto2)
Mount(1): Canon, Inc. PowerShot A710 IS -> gphoto2://[usb:001,006]/
  Type: GDaemonMount

I changed setting inNautilus to run gthumb -import : no change
I also tried to modify gthumb-import.desktop with what Stephane wrote in previous post (same mounting point, of course, on a french Jaunty): no change.
The problem seems to be the automatic mount before gthumb is launched.

Any tip to work around this problem ?

Thanks in advance, regards

Denis

Martin G Miller (mgmiller) wrote :

I have a Canon SD 550 which Ubuntu recognizes by its European name, Digital Ixus 750 (PTP mode). I did experience this bug for a while, but it has been working correctly for some time now in Jaunty.

The problem is a regression in 32 bit Karmic alpha 6. I have to unmount the camera from the desktop before importing the pictures with gthumb or I get the "device locked..." dialog. It does work correctly if I try to use Fspot as the import tool, but I don't use that app to manage my pictures.

I am currently downloading the Karmic 32 bit desktop beta and will try that to see if the regression has been resolved.

Also in Italian the mount point is something like

~/.gvfs/Mount gphoto2 su usb%3A001,004

So I had to change /usr/share/applications/gthumb-import.desktop to

Exec=sh -c 'gvfs-mount -u ~/.gvfs/*gphoto2*; exec gthumb --import-photos'

(double *gphoto*) as Stephane did for the French language.
Please apply this fix for all languages...

Martin G Miller (mgmiller) wrote :

The regression is still present in both an updated 32 bit karic and clean installs of both 32 bit and 64 bit karmic. After autorunning, the gthumb import tool fails and needs to be closed. Running it again will work. My current work around is creating the file ~/bin/get-photos its contents are:
#! /bin/bash
gvfs-mount -s gphoto2
gthumb --import-photos
gthumb --import-photos

This is called from the nautilus media preferences. It will start gthumb import tool which will fail and then you click the close button and it immediately runs again successfully.

Interestingly, if I put the SD card from the camera in a card reader, it identifies it as the correct model of Canon camera and the gthumb import tool works correctly the first time. It's only when the camera is connected by USB cable that the problem manifests.

Richard Kleeman (kleeman) wrote :

This problem is also an issue for digikam as well and has been for several releaeses
including the present one Karmic

In order to get my Sony DSC-H2 working with digikam I must unmount it from
the desktop so that PTP works in Digikam,

I have a basic and possibly naive question:

Why are cameras that use PTP being mounted at all when many photo apps need
the device unmounted to function?

Surely this is a gvfs issue if none of the usual apps can handle these devices in mounted state.......

mjc (mjc-avtechpulse) wrote :

FYI, this all started because the newish gvfs-gphoto backend claims the device, which stomps all over apps that used the old libgphoto APIs. That wasn't really nice, but such is progress.

gThumb has been ported to use the new gvfs-gphoto backend, but it has not been released yet. Keen users can check out the "ext" branch of gthumb. See http://live.gnome.org/gthumb for details.

gthumb maintainers are not actively maintaining the 2.10.x series at the moment.

This problem will go away with gthumb 2.11.0 and later.

- Mike

Richard Kleeman (kleeman) wrote :

That's fine and I hope digikam (an excellent application otherwise) also takes care of this issue but color me confused:

Why would you mount a PTP camera at all? Surely the backend should distinguish between cameras with
usb mass storage access and those with ptp access and act appropriately i.e. only mount the camera in the first case...

Am I missing something?

Please excuse the pushy tone but I just wasted 2 hours researching this problem and it has existed for at least a year now in Ubuntu.

dmoore (damien-moore) wrote :

"Why would you mount a PTP camera at all?"

why should a user care about the difference between a PTP and Mass Storage camera? they just want to plug in their camera and retrieve their photos.

The advantage of mounting is that multiple apps can share access to the device. I don't know why the devs of the leading apps are taking so long to upgrade their scripts. Getting the apps to work with gvfs-gphoto is not hard and as far as I can tell there is little to no performance impact.

"Surely the backend should distinguish between cameras with
usb mass storage access and those with ptp access"

It actually takes more work to mount the ptp camera, but it is work that gvfs-gphoto takes care of. This should be making it easier for would be application writers. (I know, I'm one of them: https://launchpad.net/phraymd)

Richard Kleeman (kleeman) wrote :

I take your points. I would make two points in response:

1) My camera takes a very long time to mount for some reason. If I don't mount it and allow
digikam to access using ptp it still takes a while but not as long. Why the long delay?
Is it the fact that the usb connection is slow or something else. The contrast with a usb stick is striking.
I plug that in and the file system is virtually instantaneously mounted and available.

2) Isn't it rather strange that so many apps are having problems with a ptp mount? Are these
cameras so rare that the upstream devs are just ignoring this problem or are these projects
not very active?

dmoore (damien-moore) wrote :

"1) My camera takes a very long time to mount for some reason."

this is actually a bit of a puzzle and may in fact be a bug. you will get a busy cursor for a signficant period of time, but I've found that applications can usually see the mounted volume long before the busy cursor disappears.

"Is it the fact that the usb connection is slow or something else. The contrast with a usb stick is striking."

Every PTP device I've owned has been slow. There are tricks to speed up browsing access: when reading from the PTP device, the importer should not try to read image metadata and use the gphoto-gvfs supplied methods to read internal thumbs (which uses the relevant gphoto calls). The importer should only read the metadata after copying files off the device.

My (still buggy) application phraymd will give you a sense of the potential performance of gvfs-gphoto:
1. install from the ppa here: https://launchpad.net/~damien-moore/+archive/ppa
2. start phraymd from the applications menu. you will be prompted to choose an image collection directory. just choose a folder with a few photos in it to avoid a lengthy indexing process. hereafter this becomes your collection. you can move images in here and they will be show up in phraymd.
3. now plug in your PTP camera. phraymd should detect it and the sidebar should open an import page (note that you may still see the busy cursor for a bit even though the device is properly mounted).
4. The "Import from" combo box should allow you to choose you camera.
5. Use the default options (Load metadata unchecked, Use internal thumbnails checked) and choose browse now.
6. The browser view will now populate with images on the camera. The sidebar will show import options
7. You can select some images by clicking in the browser and "import" them otherwise just cancel to return to your collection view. The importer is still a bit buggy -- your mileage may vary as to how well this works (I'm in the process of refactoring this code)

"2) Isn't it rather strange that so many apps are having problems with a ptp mount? Are these
cameras so rare that the upstream devs are just ignoring this problem or are these projects
not very active?"

I don't know. I've definitely seen bugs that were simply packaging SNAFUs that broke support for some cameras

I think that part of the problem is that media handling is still a bit of a moving target. The import script that worked fine in one version of Ubuntu (or other gnome distros for that matter) might not work well in the next due to changes in gvfs/gphoto/nautilus/some other dependency.

Martin Pitt (pitti) wrote :

This should be fixed in 9.10, and won't realistically be changed for Jaunty (9.04).

Changed in gthumb (Ubuntu Jaunty):
assignee: Martin Pitt (pitti) → nobody
status: New → Won't Fix
Richard Kleeman (kleeman) wrote :

spillz,
Thanks for the comments and pointers. I will try out your app.

Richard Kleeman (kleeman) wrote :

Spillz,
I tried your app and followed your directions. Unfortunately it ultimately did not work. Here is what happened:

1) I plugged in the camera and Ubuntu asked which application I wanted to open. Yours was listed and I chose it.
2) The camera was listed in the left panel and I selected it to import from.
3) I clicked the browse button and the app communicated with the camera (I saw the camera communication light go on).
4) This state lasted for about 3-5 minutes with no thumbnails appearing. After that period, the right panel displaying the Picture directory blanked out. The communication light on the camera went out and no thumbnails appeared.

I should add that I am still able to access photos as follows:

1) When Ubuntu asks which app to open it also offers "unmount". I selected that.
2) Open digikam and select import from the appropriate camera.
3) Wait 3-5 minutes while the app communicates with the camera
4) All the thumbnails appear in reverse chronological order.

The Camera is a Sony Cybershot DSC-H2.

>3) Wait 3-5 minutes while the app communicates with the camera

yikes! does this always happen? assuming this isn't a camera issue, this has
to be a gphoto bug (maybe specific to ubuntu packaging -- have you tried
other distros?)

I'm not sure why phraymd didn't work at all. Any console output?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.