Open cod3monk opened 7 years ago
Hmm, you are calling the commandline tool, which opens and closes the tcp/ip connection if it exits.
You could use python gphoto bindings, (look for piggyphoto https://github.com/alexdu/piggyphoto )
or you can open a "gphoto2 --shell" instance, keep it open and pipe in commands. but I suspect you also need to send regular commands into this pipe to keep the camera open.
Yes, we are currently using the commandline tool. It could indeed be the case that not the connection itself is resetting the timeout, but any command on the control channel.
I will test the different options and report back.
I did some tests with gphoto2 --shell
. You were right about the commands to keep the connection open. But I could not test my other problems, since it always crashes if I use the get
command.
$ gphoto --version
gphoto2 2.5.14 /usr/bin/clang, popt(m), exif, no cdk, no aa, jpeg, readline
libgphoto2 2.5.14 all camlibs, /usr/bin/clang, ltdl, EXIF
libgphoto2_port 0.12.0 /usr/bin/clang, ltdl, USB, serial without locking
I did not get around to test the python bindings.
When using gphoto2 with Nikon D5300 via builtin Wifi, as described in https://github.com/fau-fablab/labcamera (and fau-fablab/labcamera#1) we have the following problem: The camera automatically disconnects any clients within 30s that do not have an open control channel. This is fine as long as transfers (of file listings and files) take less, since each new request for a file reopens the control channel and seems to reset the timer. It is also fine if we wait for events to happen, since this also seems to keep the control channel open.
It would be beneficial to have a switch in gphoto2 to allow the control channel to remain open until all transfers are complete.
Our current workaround is to delete old files of the SD card, to ensure that file listings don't take longer than 30s and ignore video files, which might be too large to be transferred within 30s.