After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 742295 - cannot import photos from iOS 8.1.2
cannot import photos from iOS 8.1.2
Status: RESOLVED OBSOLETE
Product: shotwell
Classification: Other
Component: camera
0.20.x
Other Linux
: Normal normal
: ---
Assigned To: Shotwell Maintainers
Shotwell Maintainers
: 742330 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-01-04 03:38 UTC by lmsurprenant
Modified: 2021-05-19 14:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Transcript of session with gphoto2 --debug --shell and iPhone 6 with iOS 8.1.2 (26.59 KB, text/plain)
2015-01-06 04:03 UTC, John Kerenyi
  Details
Shotwell debug log (108.85 KB, text/plain)
2015-01-15 03:23 UTC, John Kerenyi
  Details
Dirty patch keeping ImportPage's "camera" object alive. (4.55 KB, patch)
2015-08-30 09:50 UTC, Obsidian
none Details | Review
Dirty patch keeping ImportPage's "camera" object alive. (4.83 KB, patch)
2017-06-11 08:39 UTC, Jens Georg
none Details | Review
Dirty patch keeping ImportPage's "camera" object alive. (6.36 KB, patch)
2018-03-02 19:12 UTC, Jens Georg
none Details | Review

Description lmsurprenant 2015-01-04 03:38:28 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?
Comment 2 John Kerenyi 2015-01-04 18:38:11 UTC
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.
Comment 3 Jim Nelson 2015-01-05 20:55:41 UTC
*** Bug 742330 has been marked as a duplicate of this bug. ***
Comment 4 Jim Nelson 2015-01-05 21:06:57 UTC
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.
Comment 5 John Kerenyi 2015-01-06 04:03:18 UTC
Created attachment 293898 [details]
Transcript of session with gphoto2 --debug --shell and iPhone 6 with iOS 8.1.2

Entered gphoto2 shell and exited.
Comment 6 John Kerenyi 2015-01-06 04:05:00 UTC
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.
Comment 7 Jim Nelson 2015-01-06 21:10:51 UTC
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.
Comment 8 John Kerenyi 2015-01-07 03:52:51 UTC
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>
Comment 9 John Kerenyi 2015-01-07 05:43:14 UTC
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.)
Comment 10 zoom 2015-01-07 12:46:19 UTC
gphoto2: {/home/zoom} /> ls store_00010001/ 

*** Erreur ***
PTP I/O error
*** Erreur (-107 : « Directory not found ») ***
Comment 11 zoom 2015-01-07 12:47:27 UTC
gphoto2: {/home/zoom} /> cd store_00010001/ 

*** Erreur ***
PTP I/O error
*** Erreur (-107 : « Directory not found ») ***
gphoto2: {/home/zoom} />
Comment 12 Jim Nelson 2015-01-12 23:05:53 UTC
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?
Comment 13 zoom 2015-01-14 11:32:53 UTC
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.
Comment 14 John Kerenyi 2015-01-15 03:23:29 UTC
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).
Comment 15 Jim Nelson 2015-02-04 02:09:17 UTC
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?
Comment 16 zoom 2015-02-04 09:54:16 UTC
Yes, with Nautilus I can extract pictures without any problem
Comment 17 John Kerenyi 2015-02-04 13:56:21 UTC
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.
Comment 18 cnehren+gnome-bugzilla 2015-04-22 00:54:06 UTC
What is needed to take this out of NEEDINFO?
Comment 19 Sfl 2015-06-24 12:44:41 UTC
(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.
Comment 20 James Montgomery 2015-07-27 04:41:50 UTC
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
Comment 21 Obsidian 2015-08-20 16:16:24 UTC
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.
Comment 22 Obsidian 2015-08-30 09:50:31 UTC
Created attachment 310302 [details] [review]
Dirty patch keeping ImportPage's "camera" object alive.
Comment 23 Obsidian 2015-08-30 09:52:21 UTC
(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. :-)
Comment 24 Jens Georg 2017-06-11 08:39:11 UTC
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
Comment 25 Jens Georg 2017-06-11 08:40:04 UTC
Hack on top of hack to actually close camera on shutdown. Does not happen in original patch because the ImportPage is never destroyed.
Comment 26 Jens Georg 2018-03-02 19:12:13 UTC
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
Comment 27 GNOME Infrastructure Team 2021-05-19 14:38:15 UTC
-- 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.