#135 Long Capture Image Time

[Casey Deyle]

I am experiencing capture times of ~30 secs. Below are the version info, summary, lines of the debug in question, and attached is the full debug of the capture. The summary command is executed in less than a second and so is most of the code in the capture with the actual picture taking around 5-6 secs to capture. I should note that I also tried with an older version of both libgphoto and gphoto2 with the same results (using the generic PTP camlib). If anyone can provide any ideas to where I should start looking or possible solutions to fix this, it would be greatly appreciated.

gphoto2 2.5.10 gcc, popt(m), exif, no cdk, aa, jpeg, no readline
libgphoto2 2.5.10 all camlibs, gcc, ltdl, EXIF
libgphoto2_port 0.12.0 gcc, ltdl, USB, serial without locking

Camera summary:
Manufacturer: Nikon Corporation
Model: S3700
Version: COOLPIX S3700 V1.0
Vendor Extension ID: 0xa (1.0)
Vendor Extension Description: microsoft.com/deviceservices: 1.0;

Capture Formats: JPEG
Display Formats: Undefined Type, Association/Directory, Defined Type, JPEG, DPOF, MS AVI, Apple Quicktime, MS Wave

Device Capabilities:
File Download, File Deletion, File Upload
Generic Image Capture, No Open Capture, No vendor specific capture
Nikon Wifi support

Storage Devices Summary:
store_00010001:
StorageDescription: S3700
VolumeLabel: None
Storage Type: Removable RAM (memory card)
Filesystemtype: Digital Camera Layout (DCIM)
Access Capability: Read-Write
Maximum Capability: 32383172608 (30883 MB)
Free Space (Bytes): 32344244224 (30845 MB)
Free Space (Images): 2936

Device Property Summary:
Property 0xd407:(read only) (type=0x6) 1
Property 0xd406:(readwrite) (type=0xffff) ''
Property 0xd002:(readwrite) (type=0x6) Enumeration [1,2,3,4,5,6,7] value: 7
Date & Time(0x5011):(readwrite) (type=0xffff) '20160405T092851'
Flash Mode(0x500c):(readwrite) (type=0x4) Enumeration [1,2,3,4] value: Automatic flash (1)
Focus Mode(0x500a):(readwrite) (type=0x4) Enumeration [2,3] value: Automatic (2)
Focal Length(0x5008):(read only) (type=0x6) Enumeration [3500,4600,5300,6100,7300,8600,10500] value: 35 mm (3500)
Battery Level(0x5001):(read only) (type=0x2) Enumeration [2,5,25,50,65,80,100] value: 100% (100)
Property 0xd303:(read only) (type=0x2) 1

Lines in question, notice the 9-10 secs of delay:

6.844260 gp_port_check_int (3): Reading 24 = 0x18 bytes from interrupt endpoint...
15.897116 gp_port_check_int (3): Read 16 = 0x10 out of 24 bytes from interrupt endpoint: (hexdump of 16 bytes)
0000 10 00 00 00 04 00 02 40-05 00 00 00 08 00 00 00 .......@........
.
.
.
15.913126 gp_port_check_int (3): Reading 24 = 0x18 bytes from interrupt endpoint...
28.184993 gp_port_check_int (3): Read 16 = 0x10 out of 24 bytes from interrupt endpoint: (hexdump of 16 bytes)
0000 10 00 00 00 04 00 0d 40-05 00 00 00 05 00 00 00 .......@........

[Casey Deyle]

"gphoto2 --trigger-capture" works in 5-6 secs, however the "--capture-image" still takes 30.

I have narrowed it down to the following line of code in gphoto2-port.c:
retval = port->pc->ops->check_int (port, data, size, port->timeout);

Any ideas why this takes so long?

[Marcus Meissner]

the event delivery happens with correct events, but after 13 seconds each. This looks weird.

you built against libusb0 (and not the newer libusb1), but this is probably not the reason.

you can try as workaround:
{"Nikon:Coolpix S3700", 0x04b0, 0x035c, PTP_CAP},

    {"Nikon:Coolpix S3700",           0x04b0, 0x035c, PTP_CAP|PTP_NIKON_BROKEN_CAP},

[Casey Deyle]

I upgraded to libusb1, no difference. The "gphoto2 --trigger-capture" executes in ~6 secs, perhaps I can just use that as a workaround as well. How/where would I implement the workaround you gave?

[Marcus Meissner]

can you try the workaround too? in libgphoto2 edit the line in camlibs/ptp2/library.c

[Casey Deyle]

Sorry I was confused, I got it now. I replaced that line with your workaround, and it worked!

Takes about a full second longer than "trigger_caputre" (looks like it is wait for a USB read for 1 sec somewhere in "capture_image"). but I should be able to code my application around this and at least I can set the pathname of the image before it is taken using the "capture_image". If the 1 sec speed difference becomes an issue I can just use "trigger_capture" and rename files after they have been created.

Thanks for you help, I have attached the new debug output if you are interested,

-Casey