Bulb timer stops when FILEADDED on Nikon D800/D610

[jackshencn]

Describe the bug

I am running the following script for astrophotography in Bulb mode. The capture target is on the SD card as I do not want to waste time downloading during the capture. Nor my eMMC on single board computer has enough storage. This issue is reproducible on both D800 and D610.

for i in $(seq 1 30)
do
echo "Begin Exposure $i"
gphoto2 --set-config bulb=1 --wait-event=180s --set-config capturetarget=1
sleep 1
done

The first image captures fine. But during the second capture, the bulb will halt after a few seconds and completely waste a precious exposure until the current exposure time expires.

Here's the output

pi@NanoPC-T4:~$ ./bulb.sh
Begin Exposure 1
Waiting for 30 seconds for events from camera. Press Ctrl-C to abort.
UNKNOWN PTP Property 5003 changed
UNKNOWN PTP Property 5007 changed
UNKNOWN PTP Property 5008 changed
UNKNOWN PTP Property 500b changed
UNKNOWN PTP Property 500c changed
UNKNOWN PTP Property 500d changed
UNKNOWN PTP Property d1a6 changed
UNKNOWN PTP Property d103 changed
UNKNOWN PTP Property d1a4 changed
UNKNOWN PTP Property d1b4 changed
Begin Exposure 2
Waiting for 30 seconds for events from camera. Press Ctrl-C to abort.
UNKNOWN PTP Property d1a4 changed
UNKNOWN PTP Property d1b4 changed
FILEADDED DSC_6875.NEF /store_00020001/DCIM/134ND800
CAPTURECOMPLETE
UNKNOWN PTP Property d103 changed
UNKNOWN PTP Property d1a4 changed
UNKNOWN PTP Property d1b4 changed
UNKNOWN PTP Property d1f1 changed
FILEADDED DSC_6876.NEF /store_00020001/DCIM/134ND800
CAPTURECOMPLETE
UNKNOWN PTP Property d1b4 changed
UNKNOWN PTP Property d1f1 changed

Name the camera Nikon D800 and D610

libgphoto2 and gphoto2 version

pi@NanoPC-T4:~$ gphoto2 --version
gphoto2 2.5.15

Copyright (c) 2000-2017 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.15         gcc, popt(m), exif, cdk, aa, jpeg, readline
libgphoto2      2.5.16         all camlibs, gcc, ltdl, EXIF
libgphoto2_port 0.12.0         iolibs: disk ptpip serial usb1 usbdiskdirect usbscsi, gcc, ltdl, USB, serial without locking

To Reproduce Steps to reproduce the behavior:

If its a camera misbehavior, attach debug output using --debug --debug-logfile=debug.log (if considered useful).

[jackshencn]

I compiled the latest release version and it's showing the same bug.

pi@NanoPC-T4:~$ gphoto2 --version
gphoto2 2.5.28

Copyright (c) 2000-2021 Marcus Meissner 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.28         gcc, popt(m), exif, no cdk, no aa, jpeg, no readline
libgphoto2      2.5.30         standard camlibs (SKIPPING docupen lumix), gcc, no ltdl, EXIF
libgphoto2_port 0.12.1         iolibs: disk ptpip serial usb1 usbdiskdirect usbscsi, gcc, no ltdl, EXIF, USB, serial without locking

pi@NanoPC-T4:~$ ./bulb.sh
Begin Exposure 1
Waiting for 30 seconds for events from camera. Press Ctrl-C to abort.
UNKNOWN PTP Property d103 changed, "maximumshots" to "15.000000"
UNKNOWN PTP Property d1a4 changed, "liveviewprohibit" to "Live View prohibit conditions: Processing of shooting operation"
UNKNOWN PTP Property d1b4 changed, "continousshootingcount" to "15.000000"
Begin Exposure 2
Waiting for 30 seconds for events from camera. Press Ctrl-C to abort.
UNKNOWN PTP Property d1a4 changed, "liveviewprohibit" to "Live View prohibit conditions: Processing of shooting operation"
UNKNOWN PTP Property d1b4 changed, "continousshootingcount" to "14.000000"
FILEADDED DSC_6888.NEF /store_00020001/DCIM/134ND800
CAPTURECOMPLETE
UNKNOWN PTP Property d103 changed, "maximumshots" to "13.000000"
UNKNOWN PTP Property d1a4 changed, "liveviewprohibit" to "Liveview should not be prohibited"
UNKNOWN PTP Property d1b4 changed, "continousshootingcount" to "13.000000"

[msmeissn]

One thing that stands out is that you need to set --set-config bulb=0 after the wait.
The camera will close this shutter when gphoto2 exits, but the lack of correct bulb capture termination might be the issue here.

That might not help fully though. Is the second exposure interrupted as the image is ready?

does it help if you download the image in the commandline, like e.g. gphoto2 --set-config bulb=1 --wait-event=180s --set-config bulb=0 --wait-event=CAPTURECOMPLETE

libgphoto2 basically just reports events during wait-event, we are not sending other control commands to the camera that would stop the bulb capture.

[jackshencn]

I tried --set-config bulb=0 alone doesn't help much. The next exposure still gets interrupted by a FILEADDED event. Adding --wait-event=CAPTURECOMPLETE does help but the delay between exposure is now undeterministic. Only a complete SD card file write will trigger the next.

What I really want is some async IO buffering within the camera just like normal burst shooting. Shouldn't these camera have 1GB RAM for 10 frames continous burst? Can we just issue bulb trigger and let camera write the file during the next exposure. As long the buffer has empty space left this shouldn't block bulb triggering or at least not interrupting it?

This was the hurdle trying to use tether shooting during my last 2017 solar eclipse. I need a deterministic set of triggering at specific interval at the solar eclipse totality. But either USB download or card write were such a mess and I eventually given up on PTP. I ended up using Canon Magic Lantern with built in LUA scripting to get an async IO working. But Canon DSLR back then has its own Image quality issue given its sensor technology. I'd like to explore this more for 2024 eclipse.

[msmeissn]

I need to do testing here, but lacked the time so far. I read a bit in the SDK, but it is not exact on multiple bulb captures in a row.