GNOME Bugzilla – Bug 742295
cannot import photos from iOS 8.1.2
Last modified: 2021-05-19 14:38:15 UTC
It used to import my iPhone 5s pictures with no trouble, but recently I can't seem to make it work. Whenever I try to import it says "failed to import due to a camera error". Steps to Reproduce: 1) plug in iphone with iOS 8.1.x 2) select a picture and try to import it Actual Results: What the application did after performing the above steps. It doesn't import the photo, just says: "1 file failed to import due to a camera error: IMG_0251.JPG" Build Date & Platform: Date and platform of the build in which you first encountered the bug. 0.20.2 on Ubuntu Desktop (14.04 and 14.10) Additional Information: When I saved the error to a log file, here was the interesting output: error message: [-107] Error retrieving file object for /store_00010001/DCIM/980JHETM/IMG_0251.JPG: Unknown error Is it maybe a bug with this new version iOS?
I did some searching and the only relevant information I could find was another report of the same issue: https://plus.google.com/app/basic/stream/z12jslijuyeqtr4j504cdtprvkrqu1mpga0?cbp=zttkbp5z73hm&sview=27&cid=5&soc-app=115&soc-platform=1&spath=/app/basic/%2Bxiangruan/posts&sparm=cbp%3D1j6ocbd7e7tf8%26sview%3D27%26cid%3D5%26soc-app%3D115%26soc-platform%3D1%26spath%3D/app/basic/%252Bxiangruan/posts%26sparm%3Dcbp%253D113wnrlbpvfwk%2526sview%253D27%2526cid%253D5%2526soc-app%253D115%2526soc-platform%253D1%2526spath%253D/app/basic/%25252Bxiangruan/posts%2526sparm%253Dcbp%25253D1vio1r6cluo7e%252526sview%25253D58%252526cid%25253D5%252526soc-app%25253D115%252526soc-platform%25253D1%252526spath%25253D/app/basic/communities/111202776093075745991/stream/bbed8c9d-660c-4430-97ed-cb28c1acfeed
This bug affects me too. Error message log has identical error messages. Google searches turned up nothing relevant for me either. I'm using Shotwell from the Ubuntu 14.04 repository and iOS 8.1.2. I can browse to the pictures and view/open/copy them using the file manager, but they won't import in Shotwell.
*** Bug 742330 has been marked as a duplicate of this bug. ***
It's quite possible this is an issue with gphoto2, the library Shotwell uses to access photos on cameras and mobile devices. I don't own an iOS 8.1 device, so I can't reproduce this. Whomever is having trouble, it would be helpful if you could do the following: * Install the gphoto2 command-line program. * Attach the iPhone to the computer. (It's easiest if no other camera/phone is connected.) * From the console run "gphoto2 --shell" * gphoto2 should detect the iPhone. At this point you're in a command shell. * cd into the iPhone's photo directory. * Use the get-thumbnail command to download a thumbnail. * Use show-exif to view EXIF data for a photo. * Use the get command to download an image. If one or more of these steps fails, knowing that would help diagnose the problem.
Created attachment 293898 [details] Transcript of session with gphoto2 --debug --shell and iPhone 6 with iOS 8.1.2 Entered gphoto2 shell and exited.
Here is a transcript of my session with the iPhone and gphoto2: ------------------- john@kramer:~$ gphoto2 --version gphoto2 2.5.3 Copyright (c) 2000-2014 Lutz Mueller and others gphoto2 comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of gphoto2 under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING. This version of gphoto2 is using the following software versions and options: gphoto2 2.5.3 gcc, popt(m), exif, cdk, aa, jpeg, readline libgphoto2 2.5.3.1 all camlibs, gcc, ltdl, EXIF libgphoto2_port 0.10.0 gcc, ltdl, no USB, serial without locking john@kramer:~$ gphoto2 --shell gphoto2: {/home/john} /> ls store_00010001/ gphoto2: {/home/john} /> ls store_00010001/ *** Error (-107: 'Directory not found') *** gphoto2: {/home/john} /> cd store_00010001/ *** Error (-107: 'Directory not found') *** gphoto2: {/home/john} /> ls store_00010001/ gphoto2: {/home/john} /> cd store_00010001/ *** Error (-107: 'Directory not found') *** gphoto2: {/home/john} /> ls store_00010001/ ------------------- I hope this is useful. I couldn't really do anything in the directory tree that I found therein. I notice there is a --debug option for gphoto2. It generates a lot of output. I went ahead and added it to this ticket as an attachment.
This most certainly looks like a gphoto2 issue of some kind. If you can't change to the subdirectories, that's a problem. gphoto2 2.5.6 is the latest release. Is there any chance you could build and install that? http://sourceforge.net/projects/gphoto/files/ You'll need to build and install gphoto2 and libgphoto2 if you want to use the command-line program again.
I compiled gphoto2 and libgphoto2, latest version (2.5.6). Please see transcript of session below. As you can see, the requested commands work fine with the version compiled from source. (But Shotwell doesn't work yet--may be a path problem though. If I can figure that out I will place another comment on this ticket.) john@kramer:~$ uname -a Linux kramer 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux john@kramer:~$ which gphoto2 /usr/local/bin/gphoto2 john@kramer:~$ gphoto2 --version gphoto2 2.5.6 Copyright (c) 2000-2014 Lutz Mueller and others gphoto2 comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of gphoto2 under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING. This version of gphoto2 is using the following software versions and options: gphoto2 2.5.6 gcc, popt(m), exif, no cdk, no aa, no jpeg, no readline libgphoto2 2.5.6 all camlibs, gcc, ltdl, no EXIF libgphoto2_port 0.12.0 gcc, ltdl, USB, serial without locking john@kramer:~$ gphoto2 --shell gphoto2: {/home/john} /> ls store_00010001/ gphoto2: {/home/john} /> cd store_00010001 Remote directory now '/store_00010001'. gphoto2: {/home/john} /store_00010001> ls DCIM/ gphoto2: {/home/john} /store_00010001> cd DCIM Remote directory now '/store_00010001/DCIM'. gphoto2: {/home/john} /store_00010001/DCIM> ls 799ZBPRT/ 802SXCVF/ 858PBGGD/ 904PIGYK/ 915QMYBE/ 948MTSTA/ 972JZXNU/ 973KITSY/ 996JQNZI/ gphoto2: {/home/john} /store_00010001/DCIM> cd 799ZBPRT Remote directory now '/store_00010001/DCIM/799ZBPRT'. gphoto2: {/home/john} /store_00010001/DCIM/799ZBPRT> ls IMG_1077.JPG gphoto2: {/home/john} /store_00010001/DCIM/799ZBPRT> get-thumbnail IMG_1077.JPG Saving file as thumb_IMG_1077.jpg gphoto2: {/home/john} /store_00010001/DCIM/799ZBPRT> show-exif IMG_1077.JPG EXIF tags: --------------------+----------------------------------------------------------- Tag |Value --------------------+----------------------------------------------------------- XResolution |72 YResolution |72 ResolutionUnit |Inch YCbCrPositioning |Centered Compression |JPEG compression XResolution |72 YResolution |72 ResolutionUnit |Inch ExifVersion |Exif Version 2.21 ComponentsConfigurat|Y Cb Cr - FlashPixVersion |FlashPix Version 1.0 ColorSpace |sRGB PixelXDimension |2592 PixelYDimension |1461 SceneCaptureType |Standard --------------------+----------------------------------------------------------- EXIF data contains a thumbnail (8947 bytes). gphoto2: {/home/john} /store_00010001/DCIM/799ZBPRT> get IMG_1077.JPG Saving file as IMG_1077.JPG gphoto2: {/home/john} /store_00010001/DCIM/799ZBPRT>
I didn't get Shotwell working this evening. I'm updating the ticket to reflect that in reviewing my work, I noted that I had not compiled libgphoto2 with EXIF support (this can be seen in the output I showed above). I recompiled and confirmed EXIF support is in libgphoto2, but Shotwell still presents the same issue. It's probably a configuration issue, but I am out of ideas for getting it to work with the locally compiled version of libgphoto2. (I'm pretty good at the terminal, but not at configuring GUI programs.)
gphoto2: {/home/zoom} /> ls store_00010001/ *** Erreur *** PTP I/O error *** Erreur (-107 : « Directory not found ») ***
gphoto2: {/home/zoom} /> cd store_00010001/ *** Erreur *** PTP I/O error *** Erreur (-107 : « Directory not found ») *** gphoto2: {/home/zoom} />
zoom, what version of gphoto2 are you using? Have you tried with the latest version? John, this is promising. Can you run Shotwell with debugging on and attempt to import photos? $ SHOTWELL_LOG=1 shotwell > shotwell.log Then attach the shotwell.log file here?
Jim: zoom@zoom-X75A1:~$ gphoto2 -v gphoto2 2.5.4 gphoto2 2.5.4 gcc, popt(m), exif, cdk, aa, jpeg, readline libgphoto2 2.5.4 all camlibs, gcc, ltdl, EXIF libgphoto2_port 0.10.0 gcc, ltdl, no USB, serial without locking thanks for your help.
Created attachment 294568 [details] Shotwell debug log I ran Shotwell with the environment variable SHOTWELL_LOG set to 1, then found the log file in ~/.cache/shotwell/shotwell.log. Note there are two sessions represented due to not knowing where to find the log output after the first run. So the last four lines are from starting Shotwell and exiting. This was run on the same system as I compiled libgphoto2 from source, but I don't know if Shotwell is using the locally compiled library (and the log doesn't seem to confirm it either).
I see this line repeated throughout the log for each file: L 3423 2015-01-14 19:14:33 [WRN] BatchImport.vala:1833: Unable to read metadata for /home/john/Pictures/2014/12/28/IMG_2039_17.JPG (unsupported format): continuing to attempt import That's the problem. Unsupported format means the file didn't look like a JPEG file to Shotwell. Why that is, I'm unsure of. If you manually pull the photo off the device with Nautilus, can you import it into Shotwell?
Yes, with Nautilus I can extract pictures without any problem
I confirmed the problem still occurs as originally reported. I then copied three pictures off the same iPhone into a temporary folder on my computer. I asked Shotwell to import the photos from that folder. All three imported successfully, no errors.
What is needed to take this out of NEEDINFO?
(In reply to Jim Nelson from comment #4) > It's quite possible this is an issue with gphoto2, the library Shotwell uses > to access photos on cameras and mobile devices. > > I don't own an iOS 8.1 device, so I can't reproduce this. Whomever is > having trouble, it would be helpful if you could do the following: > > * Install the gphoto2 command-line program. > * Attach the iPhone to the computer. (It's easiest if no other camera/phone > is connected.) > * From the console run "gphoto2 --shell" > * gphoto2 should detect the iPhone. At this point you're in a command shell. > * cd into the iPhone's photo directory. > * Use the get-thumbnail command to download a thumbnail. > * Use show-exif to view EXIF data for a photo. > * Use the get command to download an image. > > If one or more of these steps fails, knowing that would help diagnose the > problem. Same problem on IOS 8.3. Did the above and it all works on command line. Thumbs also come up fine in shotwell. One thing I noticed is if I'm not really careful with specifying the directory without a trailing '/' using the shell I get the -107 error. Looking at sources this stands for GP_ERROR_DIRECTORY_NOT_FOUND. Looked a little further, this makes sense, the error log contains entries as the one below and 859LNNJV doesn't show up using the shell so maybe there's a glitch causing gphoto/libgphoto to use inappropriate paths (which admittedly is odd as I'm not sure how such a specific directory would just be "guessed", must be meta data, no?) IMG_0001.JPG error message: [-107] Error retrieving file object for /store_00010001/DCIM/859LNNJV/IMG_0001.JPG: Unknown error Would be glad to help troubleshoot but as it is I'm not sure how to set this up to compile from source (has been a while since I've dabbled in C). Let me know if there's anything else I can do to help.
Breakthrough?! Version Info ------------- iOS 8.4 Shotwell 0.22.0 gphoto2 2.5.8 gcc, popt(m), exif, cdk, aa, jpeg, readline libgphoto2 2.5.8 all camlibs, gcc, ltdl, EXIF libgphoto2_port 0.12.0 gcc, ltdl, no USB, serial without locking Error Info ----------- BatchImport.vala:1391: Import error IMG_0062.JPG: [-107] Error retrieving file object for /store_00010001/DCIM/836ODKKD/IMG_0062.JPG: Unknown error (Camera error) Background Info --------------- Believe to have found the 'reason' for these errors. When mounted the DCIM/100APPLE folder contains the actual photos stored on the phone - everything else is actually iCloud/Photostream. The DCIM sub-folders accessed by gphoto2 are 100% random. Every access/connection made the folder names are regenerated/randomized therefore the initial thumbnail path names are invalid when the user goes to import. This change with iOS8 has something to do with the new PhotoStream/iCloud implementation. I am not sure the approach to make this work with Shotwell. I'm thinking there would be a need to keep the 'connection'/access object used to generate thumbnails 'alive' for the duration of the users Shotwell session in order to preserve random paths when the user chooses to import. On the phone, the iCloud/PhotoStream photos appear to require network access. When the phone is in 'airplane' mode the iCloud/PhotoStream photos lack fidelity when selected and zoomed. When using gphoto the DCIM random folders represent individual images that are available at full resolution (on phone or downloaded from iCloud/PhotoStream). I have 64 photos actually stored on my iPhone as indicated by file count in DCIM/100APPLE when mounted. gphoto2 --shell reflects this with 64 random folders in DCIM. Accessing an iCloud/PhotoStream photo on my phone while connected to a network seems to cache the viewed image as evideneced by accessing gphoto2 --shell and seeing +1 (65) DCIM folders yet the local DCIM/100APPLE still only contains 64 photos. Should these findings be reported to gphoto bug as well? Cheers, James Montgomery
James, I've JUST have made the exact same discoveries and posted them on the RedHat bugzilla, which has an open ticket regarding the same issue : https://bugzilla.redhat.com/show_bug.cgi?id=1178256#c2 Error -107 is issued by the GPhoto library and corresponds to GP_ERROR_DIRECTORY_NOT_FOUND, and is returned by gp_camera_file_get() in this particular context. I also made the same assumption about the lifetime of the connection : as long this connection remains open, the subdirectory names are not reinitialized. I don't believe it's a GPhoto problem, which works fine when downloading all the files in one shot and when using the gphoto2's shell. I think Shotwell should maintain its own connection in a way or another. However, it could be fine to raise up the priority/severity of this entry, as it totally prevents the user from dumping pictures from his iPhone, which his often the only camera the user still uses, and because this case has been pending for almost a year, now. Tried with : ------------ shotwell 0.22.0 iOS 8.4.1 iPhone 5 Fedora 22 custom kernel 4.2.0-rc6+ Copy of the comment posted on the RedHat's bugzilla --------------------------------------------------- Thanks a lot for reporting that it works with gphoto2 because I would have given up otherwise. After some investigations, the problem seems to occur in the file "src/camera/GPhoto.vala" at line 272 : res = camera.get_file(folder, filename, GPhoto.CameraFileType.NORMAL, camera_file, context); if (res != Result.OK) throw new GPhotoError.LIBRARY("[%d] Error retrieving file object for %s/%s: %s", (int) res, folder, filename, res.as_string()); There's three of them in the file, but altering the message string shows that it always happens at the first one. This file is resolved as "src/camera/GPhoto.c" at line 1984 : #line 270 "/home/dom/Build/shotwell-0.22.0/src/camera/GPhoto.vala" _tmp12_ = gp_camera_file_get (_tmp7_, _tmp8_, _tmp9_, GP_FILE_TYPE_NORMAL, _tmp10_, _tmp11_); Error -107 is actually a libgphoto2's one and corresponds to GP_ERROR_DIRECTORY_NOT_FOUND, as stated here : http://libgphoto2.sourcearchive.com/documentation/2.4.0/gphoto2-camera_8c_262b1bc840d62b12605e3acc543f714d.html#262b1bc840d62b12605e3acc543f714d I first wondered if the problem could come from the way the path was written and therefore tried to manually extract a single given file with gphoto2, then received the same -107 code, while it used to work perfectly fine when automatically downloading the whole file set. And as I was checking that my path was correct, I finally end up on this (look at the final subdirectory's name) : $ gphoto2 --port=usb: -L | grep -B1 0603 There are 2 files in folder '/store_00010001/DCIM/911KWHTS'. #713 IMG_0603.JPG rd 1284 KB 2448x3264 image/jpeg $ gphoto2 --port=usb: -L | grep -B1 0603 There are 2 files in folder '/store_00010001/DCIM/813VOSDD'. #1 IMG_0603.JPG rd 1284 KB 2448x3264 image/jpeg $ gphoto2 --port=usb: -L | grep -B1 0603 There are 2 files in folder '/store_00010001/DCIM/891WYNZY'. #792 IMG_0603.JPG rd 1284 KB 2448x3264 image/jpeg $ gphoto2 --port=usb: -L | grep -B1 0603 There are 2 files in folder '/store_00010001/DCIM/833ZLJVU'. #211 IMG_0603.JPG rd 1284 KB 2448x3264 image/jpeg Which means that iOS seems to store all files in a bunch of subdirectories, and the names of these subdirectories are auto-regenerated for each new connection. As long as the application keeps its connection open, there's no problem, but if gathers all the names first, then try to fetch them later, it is unable to find them back.
Created attachment 310302 [details] [review] Dirty patch keeping ImportPage's "camera" object alive.
(In reply to Obsidian from comment #22) > Created attachment 310302 [details] [review] [review] > Dirty patch keeping ImportPage's "camera" object alive. Once again, I've posted first in the wrong bugzilla. Sorry about this. The patch is attached one comment above. Ok, here's a quick patch that will do for the moment. It's a TERRIBLE hack which will need you to quit the application to release the camera, but at least it allowed me to import my 900 snapshots that were pending for almost a year. Basically, it keeps alive the "camera" object of the ImportPage class. It now calls init() only if the object is null, hence not previously initialized first, and hides every call to exit(), pretending the thing is still done. This neutralize the CameraRefresh routines. However, it now properly calls exit() in the ImportPage class's destructor. This patch may be applied on version 0.22.0. It works on commit 6bd668604537f9d11bb7d4874e2fd5f77ed63db0 from the shotwell's github repository. I compiled it from there with every debug options just for iOS, and keep installed the standard version from my distribution packages when dealing with other cameras. Once again, this is rather DIRTY and should be used only as a temporary workaround. Hope it helps anyway. :-)
Created attachment 353560 [details] [review] Dirty patch keeping ImportPage's "camera" object alive. FIXME: need commit message. (Please also double check the author and subject.) https://bugzilla.gnome.org/show_bug.cgi?id=742295 https://bugzilla.gnome.org/show_bug.cgi?id=781802
Hack on top of hack to actually close camera on shutdown. Does not happen in original patch because the ImportPage is never destroyed.
Created attachment 369200 [details] [review] Dirty patch keeping ImportPage's "camera" object alive. FIXME: need commit message. (Please also double check the author and subject.) https://bugzilla.gnome.org/show_bug.cgi?id=742295 https://bugzilla.gnome.org/show_bug.cgi?id=781802
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/shotwell/-/issues/4578.