Shotwell and Android phone: "The camera is locked by another application"

When I connect my old goofy Android phone (a Sony F5122 aka “Xperia X”) to my computer using a USB cable, it gets mounted automatically. Nautilus can browse the device’s filesystem.

When I try to copy photos off the device using Shotwell, I get an error message: “The camera is locked down by another application. Shotwell can only access the camera when it is unlocked. Please close any other application using the camera and try again.”

So I click the “unmount” button on Nautilus, but Shotwell is still unable to read pictures from the device. Why? It doesn’t seem that anything else is holding a lock on the device.

I found a discussion elsewhere on this topic, and the solutions suggested there was the same as above, and it did not work. Is this a known problem? Is this a problem with Shotwell, Gnome, Android, my goofy phone, or something else altogether?

Which version is this and is this a flatpak or a distribution installation?

Does “unable to read from the device” mean that it shows no photos or are there any other errors?

I’m using Shotwell 0.30.11 from Debian 11. Shotwell shows no photos from the device. It shows just this error message.

When I unmount the device from Nautilus, Shotwell is still unable to read it. Instead the phone shows a “Use USB to…” dialog (choices: charge this device, transfer files, use device as MIDI). Once I chose “transfer files” from that list, the device will be shown as mounted in Nautilus, and Shotwell will display the same error message against. Nautilus always wins this race.

I found some really old (2010 vintage), possibly related issues in Shotwell’s GitLab project:

  • #1643: use GVFS rather than libgphoto2, allowing importing without unmounting
  • #1415: camera locked dialog is confusing
  • #1464: Getting an error message when plugging in my camera

(Omitting the link to #1464 because I’m hitting Discourse’s upper limit on links a new user can post.)

What I could glean is that Shotwell is still using libgphoto2, and not gvfs. Could that be the problem, or is it something about my phone?

Can you try if this works for you:

  • When the dialog shows in shotwell, unmount the device in Nautilus
  • Click ok on the dialog
  • Switch to a different Section in shotwell
  • Switch back to the camera

This seems to work for me in Debian 11. I don’t know why on Debian Shotwell does not offer to unmount the device itself.

1 Like

Thank you. I tried that, but Shotwell is still unable to read from the device. It showed a different message this time: “Unable to fetch previews from the camera: Timeout reading from or writing to the port (-10)”.

image

Hm. You could try if gphoto2 -T works. This may download quite a lot of pictures, so probably do that in a dedicated folder that will not mess with anything else

With gphoto2 -T, I get this error when the phone is not mounted:

$ gphoto2 -T
                                                                               
*** Error ***              
PTP Invalid Storage ID
*** Error (-1: 'Unspecified error') ***       

For debugging messages, please use the --debug option.
Debugging messages may help finding a solution to your problem.
If you intend to send any error or debug messages to the gphoto
developer mailing list <gphoto-devel@lists.sourceforge.net>, please run
gphoto2 as follows:

    env LANG=C gphoto2 --debug --debug-logfile=my-logfile.txt -T

Please make sure there is sufficient quoting around the arguments.

When the phone is mounted, I get a different error, which I guess must be expected:

$ gphoto2 -T
                                                                               
*** Error ***              
An error occurred in the io-library ('Could not claim the USB device'): Could not claim interface 0 (Device or resource busy). Make sure no other program (gvfs-gphoto2-volume-monitor) or kernel module (such as sdc2xx, stv680, spca50x) is using the device and you have read/write access to the device.
*** Error (-53: 'Could not claim the USB device') ***       

For debugging messages, please use the --debug option.
Debugging messages may help finding a solution to your problem.
If you intend to send any error or debug messages to the gphoto
developer mailing list <gphoto-devel@lists.sourceforge.net>, please run
gphoto2 as follows:

    env LANG=C gphoto2 --debug --debug-logfile=my-logfile.txt -T

Please make sure there is sufficient quoting around the arguments.

Sorry, my bad, I forgot that gphoto2 -T needs a folder.

Does gphoto2 -l --no-recurse work?

$ gphoto2 -l --no-recurse
There are 2 folders in folder '/'.                                             
 - store_00010001
 - store_271c0001

When I drop the --no-recurse argument, it printed a whole bunch of stuff correctly. But prior to this, I had installed gvfs-fuse. I don’t enough about gphoto2 to know if that made a difference. I will need to try this without gvfs-fuse.

I still could not transfer using gphoto2 -T. There’s the same error still, when the device is not mounted:

$ gphoto2 -T
                                                                               
*** Error ***              
An error occurred in the io-library ('Could not claim the USB device'): Could not claim interface 0 (Device or resource busy). Make sure no other program (gvfs-gphoto2-volume-monitor) or kernel module (such as sdc2xx, stv680, spca50x) is using the device and you have read/write access to the device.
*** Error (-53: 'Could not claim the USB device') ***       

For debugging messages, please use the --debug option.
Debugging messages may help finding a solution to your problem.
If you intend to send any error or debug messages to the gphoto
developer mailing list <gphoto-devel@lists.sourceforge.net>, please run
gphoto2 as follows:

    env LANG=C gphoto2 --debug --debug-logfile=my-logfile.txt -T

Please make sure there is sufficient quoting around the arguments.

But I could finally transfer using Shotwell though, using the method you previously suggested!

Perhaps either installing gvfs-fuse made a difference, or there’s a subtle bug going on here. I will try to do a bit more testing to figure things out. Regardless of the underlying problem, it doesn’t help that Shotwell has an unhelpful and frustrating UX, in this specific case.

Yes I agree, the UX is less than optimal. Part of it is that it does not discover the mout by itself, that would be much smoother and needs debugging why this is broken on Debian 11, yet again.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.