Error when importing from Fuji X10
Submitted by an unknown user
Link to original bug (#718128)
Description
---- Reported by shotwell-maint@gnome.bugs 2011-12-18 09:01:00 -0800 ----
Original Redmine bug id: 4512
Original URL: http://redmine.yorba.org/issues/4512
Searchable id: yorba-bug-4512
Original author: Luis Arias
Original description:
In Shotwell 0.11.6 (Ubuntu 11.10), the camera is correctly seen as a PTP Camera. When importing, Shotwell freezes for a while then the following message appears in a popup:
Unable to lock camera: Unspecified error (-1)
This happens whether I unmount the camera before launching Shotwell or if the camera is unmounted from within Shotwell before attempting the import.
I imagine this is an error with libgphoto2, I tried gphoto2 --shell because I found that suggestion here
http://shotwell.3510.www.nabble.com/Shotwell-Samsung-Kies-on-Galaxy-S2-amp- Shotwell-td45010.html
but gphoto2 rapidly gives errors simply when cd'ing into the first directory that comes up with ls. Please let me know if there is any debug information I can try and generate and post here.
UPDATE: See also this ticket about Rhythmbox blocking cameras from mounting: https://bugs.launchpad.net/ubuntu/+source/libgphoto2/+bug/581087
Related issues:
- related to shotwell - 3556: Can't import from Nikon Coolpix L120 (Duplicate)
- related to shotwell - 3332: Shotwell has trouble communicating with Nikon D300s (Blocked)
- related to shotwell - 2494: [android] can't unmount HTC Desire smartphone for import (Open)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-16 14:44:00 -0700 ----
History
Comment 1
Updated by Luis Arias almost 2 years ago
- File shotwell.log added
I found another post which showed me how to get a shotwell log which I'm posting here. Unfortunately there is no output between the time I click on "Import" and the error is displayed. It happens after the last thumbnail is displayed and before I turn off the camera (between the following two lines in the log):
..
L 4031 2011-12-18 18:17:23 [DBG] GPhoto.vala:129: Adjusted length of thumbnail for: DSCF0100.JPG
L 4031 2011-12-18 18:18:14 [DBG] CameraTable.vala:369: udev event: remove on 3-1:1.0
..
Comment 2
Updated by Luis Arias almost 2 years ago
I have updated the launchpad report for this with the following information:
https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/910964
As an update to this, I disabled the gphoto2 gvfs backend by running
sudo chmod -x /usr/lib/gvfs/gvfs-gphoto2-volume-monitor
to isolate issues to shotwell / libgphoto2. What I get is that the issue persists and actually trying to run an import is not necessary, its enough to just click on the USB PTP Camera item and let shotwell display the photo previews to then have a PTP I/O Error be signaled by
gphoto2 --list-files
The camera is at this point in an unusable state.
Also here is a link to the libgphoto2 report and discussion:
[https://sourceforge.net/tracker/index.php?func=detail&aid=3467525&group_id=88 74&atid=308874](https://sourceforge.net/tracker/index.php?func=detail&aid=3467 525&group_id=8874&atid=308874)#
Comment 3
Updated by Luis Arias almost 2 years ago
It seems this is really a libgphoto2 issue:
[https://sourceforge.net/tracker/index.php?func=detail&aid=3468856&group_id=88 74&atid=108874](https://sourceforge.net/tracker/index.php?func=detail&aid=3468 856&group_id=8874&atid=108874)
Comment 4
Updated by Clinton Rogers almost 2 years ago
- Category set to 4
- Status changed from Open to Blocked
- Priority changed from Normal to High
- Keywords set to fuji, x10, gphoto, ptp, connection, error
Hi Luis,
Unfortunately, there seem to be several cameras that GPhoto has trouble communicating with in its current incarnation; if you have a look at the related bugs, you'll notice that some recent-model Nikons have a similar problem as well.
I'll be tentatively marking as 'blocked' on our side, with the understanding that we'll actively watch GPhoto's progress, and, if an upstream fix becomes available, we'll reopen and work on getting that into Shotwell.
Comment 5
Updated by Jim Nelson 11 months ago
- Target version set to 0.14.0
Comment 6
Updated by Jim Nelson 11 months ago
- Category set to camera
Comment 7
Updated by Jim Nelson 10 months ago
As reported on the Shotwell mailing list: http://lists.yorba.org/pipermail/shotwell/2013-January/004494.html
It looks like Rhythmbox and/or libmtp was interfering with accessing the device because it was detected as MTP rather than PTP. The user killed the Rhythmbox process and the camera began working with Shotwell.
For the original reporter (and anyone else with this issue), please try reproducing this problem again. Then look at the end of this file:
$ tail -30 ~/.xsession-errors
If you see a warning about MTP or libmtp and/or Rhythmbox, please let us know. Thanks!
Comment 8
Updated by Jim Nelson 10 months ago
- Description updated (diff)
This makes me even more suspicious of Rhythmbox being the culprit here: https://bugs.launchpad.net/ubuntu/+source/libgphoto2/+bug/581087
Comment 9
Updated by Luis Arias 10 months ago
- File shotwell.log added
Attaching a shotwell log file that's generated under the following conditions in 12.10.
-
Set in Details / Removable Media "Do nothing" for Photos. This causes gvfs- gphoto2-volume-monitor not to run when the camera is turned on.
-
Launch shotwell in a terminal using SHOTWELL_LOG=1 shotwell
-
Click on PTP Camera and then Import All
I'm pretty sure the bug is in Shotwell because under the same conditions gphoto2 --get-all-thumbnails never fails.
Comment 10
Updated by Luis Arias 10 months ago
Further update, it is sufficient under the above conditions to simply Click on PTP Camera then quit shotwell for the camera to be left in an invalid state. At that point doing
env LC_ALL=C gphoto2 --debug-logfile=logfile.log --debug --get-all-thumbnails
displays
-
Error ***
PTP I/O error -
Error ***
An error occurred in the io-library ('Unspecified error'): No error description available -
Error (-1: 'Unspecified error') ***
So apparently just executing ImportPage.refresh_camera() will do it. Digging into the codebase.
Comment 11
Updated by Luis Arias 10 months ago
Further update. If I comment out the call to auto_match_raw_jpeg() at line 1210 of ImportPage.vala after quitting shotwell gphoto2 --get-all-thumbnails work fine. So its something in this function.
Comment 12
Updated by Luis Arias 10 months ago
I don't see this function doing much with the camera itself (maybe I'm wrong) so I suspect it setups data (associating the RAW and JPEG) that trips something later on, probably load_previews_and_metadata(). I'll try some more debugging of this tomorrow.
Comment 13
Updated by Luis Arias 10 months ago
Ok narrowed the problem down to lines 1559-1661 in ImportPage.vala:
PhotoMetadata? associated_metadata = GPhoto.load_metadata(spin_idle_context.context,
camera, associated.get_fulldir(), associated.get_filename());
associated.update(preview, preview_md5, associated_metadata, null);
If the call to GPhoto.load_metadata is commented out and the call to associated.update() is replaced by
associated.update(preview, preview_md5, metadata, null);
gphoto2 behaves correctly when quitting shotwell right after this code is run. If the load_metadata() function is called here then the camera enters a mode where gphoto2 gives rise to the PTP I/O error message.
Please let me know if there are any other tests I should run. It seems to me at this point that the next step would be to write a libghoto2 C program that attempts to make the camera go in the error state by mixing and matching calls to get metadata and thumbnails of different files. Maybe if the calls were made in directory order like gphoto2 --get-all-thumbnails which processes JPG before RAF files contrary to shotwell which processes the RAF then JPG, the camera wouldn't hang ? I think this will be my next test.
Comment 14
Updated by Jim Nelson 10 months ago
- File 4512-test.diff added
This is some great detective work, Luis. It helps us a lot, as we don't see this here with any of our own cameras.
I don't know exactly why this is causing a problem, but there's a couple of things we can try to see if this helps. I'm attaching a patch that adds some debug code to things I think might be interesting to know about. Could you apply and run? One change is to use a different context when retrieving the associated file's metadata (ImportPage.vala:1563); I don't think this will actually solve the problem, but I'm curious if it changes anything.
If you could apply, run, and send your .log file, that would be a ton of help.
As far as the test you're proposing, yes, that could be the next step, sort of another way of trying to find the root of the problem.
Comment 15
Updated by Luis Arias 10 months ago
- File shotwell.log added
Thanks for your help! I applied the patch and rebuilt. The PTP Error problem still persists but here is the log from that test. Anything else I could try ?
Comment 16
Updated by Jim Nelson 10 months ago
- File 4512-test-2.diff added
There's a couple of things I see in your log:
- Shotwell is detecting 9 RAW+JPEG pairs (DSCF3124 to DSCF3132)
- It is loading the metadata from the RAW, the preview from the JPEG, and the metadata from the JPEG, in that order, without an error.
- It gets through all 9 of them without error
So I don't see a problem here, at least just in the log itself. Is it possible the error is occuring after the load_previews_and_metadata() method has exited?
There's only one place it's called, at ImportPage.vala:1217. After it exits the progress bar is reset and camera.exit() is called. I have to wonder if that's the culprit. The problem is, there's nothing in your log file to indicate that exit() is failing -- there's a warning message that should've been printed.
I'm attaching a revised patch that includes the old changes as well as a couple of new ones. I'm curious if some other error is causing this problem and is simply going undetected. If you could try it out and let us know, that would be great.
Comment 17
Updated by Luis Arias 10 months ago
- File shotwell.log added
Hi Jim,
Here's the log file. I don't see anything special. I'm playing with the code in load_previews_and_metadata to see if maybe this has something the fact that the metadata and preview calls are interweaved. So I'll try different loops with either getting the metadata or the previews and I'll post back.
Luis
Comment 18
Updated by Luis Arias 10 months ago
I replaced load_preview_and_metadata in ImportPage.vala by the following loop and that's enough to create the issue ! So it seems its loading the JPG metadata that causes this. Anything in GPhoto.load_metadata I should be suspicious of ?
foreach (ImportSource import_source in import_list) {
// Get JPEG pair, if available.
PhotoImportSource? associated = null;
if (import_source is PhotoImportSource &&
((PhotoImportSource) import_source).get_associated() != null) {
associated = ((PhotoImportSource) import_source).get_associated();
}
if (associated != null) {
try {
debug("Loading associated metadata for %s/%s", associated.get_fulldir(),
associated.get_filename());
PhotoMetadata? associated_metadata = GPhoto.load_metadata(spin_idle_context.context,
camera, associated.get_fulldir(), associated.get_filename());
} catch (Error err) {
warning("Unable to fetch metadata for %s/%s: %s", associated.get_fulldir(),
associated.get_filename(), err.message);
}
}
}
Comment 19
Updated by Jim Nelson 10 months ago
I don't know what could be causing this, although from the log you sent me, I still don't see any problem. It appears that Shotwell has loaded all the previews and metadata for all the files and has properly associated the RAW with the JPEG files. It does all these operations without detecting or reporting a problem.
What your last post and this log file tells me is that loading the EXIF data, exiting (closing) the camera without gphoto2 reporting the problem. Then, when you try to import, the init() call is failing. Loading the EXIF or closing the camera is putting it into such a state that it can't be opened again.
Another experiment: remove or comment out the call to camera.exit() at ImportPage.vala line 1229. Remove or comment out the call to camera.init() at ImportPage.vala line 1600. Then try again. This will leave the camera opened after loading the previews and EXIF data. I'm curious if this works.
Comment 20
Updated by Luis Arias 10 months ago
Bingo ! Commenting out both camera.exit() and camera.init() at those lines works perfectly ! I was able to view the previews, quit, use gphoto2, go back, import some photos, etc... and no issues ! I wonder what the effect of doing that on other cameras could be though ? :(
Luis
Comment 21
Updated by Jim Nelson 10 months ago
- Status changed from Blocked to Open
That code has been in there a long time, as ImportPage was one of the earliest bits of code in Shotwell. (You need to import photos in order to write a photo manager, that sort of thing.) This confirms my earliest guesses, which are either (a) closing and re-opening a camera puts a certain class of cameras into a bad state and we've simply not encountered them before or (b) closing and opening is putting this version of gphoto2 into a bad state.
One fix would be not to close the camera -- once Shotwell gets the lock, it holds it. We'd prefer not to do that because it means other applications are effectively shut out of using it; you have to unplug and re-plug it back in.
One thing you might try (if you're up for it) is downloading and installing older versions of libgphoto2 and see if that changes anything. It's possible this is a recent regression.
Comment 22
Updated by Jim Nelson 9 months ago
- Target version changed from 0.14.0 to 0.15.0
Whatever fix is required here, it's probably too risky for 0.14. We'll revisit for 0.15.
Comment 23
Updated by Jim Nelson 8 months ago
- Target version changed from 0.15.0 to 0.16.0
Comment 24
Updated by Jim Nelson 6 months ago
-
Target version deleted (
<strike>
_0.16.0_</strike>
)
--- Bug imported by chaz@yorba.org 2013-11-25 21:55 UTC ---
This bug was previously known as bug 4512 at http://redmine.yorba.org/show_bug.cgi?id=4512 Imported an attachment (id=262200) Imported an attachment (id=262201) Imported an attachment (id=262202) Imported an attachment (id=262203) Imported an attachment (id=262204) Imported an attachment (id=262205)
Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution
Resolution: RESOLVED OBSOLETE