search

gphoto / libgphoto2

The libgphoto2 camera access and control library.
GNU Lesser General Public License v2.1
1.02k stars 322 forks source link

Ricoh Theta Z1: downloading the very first image is very slow if camera internal storage has many files #563

Open alik55 opened 3 years ago

alik55 commented 3 years ago

Describe the bug

Ricoh Theta Z1 used in PTP mode over USB3. Using the camera to capture/download/delete file. Do not care about other files already present on camera storage. Downloading the very first image takes a long time if there are many files present on camera internal storage - about 15sec per each 500 files. If a program using libgphoto captures many files, all files after the first one get downloaded fast, as expected. The first download is fast only if the internal camera storage is empty.

It seems libgphoto parses the camera filesystem and gets info on every object found there to cache the whole tree. This is not needed for my application. Ideally GP_EVENT_FILE_ADDED event should provide a file handle and the file can be downloaded and deleted using that handle via MTP protocol, so there is no need for knowledge about other files.

Can libgphoto be configured not to list all existing files and get their info?

Name the camera Camera name as shown by gphoto2 --auto-detect or USB IDs

libgphoto2 and gphoto2 version latest master

To Reproduce Steps to reproduce the behavior:

When reproducing with the commandline tool, attach debugout using --debug --debug-logfile=debug.log if considered useful.

alik55 commented 3 years ago

After more digging.

On very first image download (actually inside gp_camera_wait_for_event when waiting on first GP_EVENT_FILE_ADDED) libgphoto calls ptp_getobjecthandles in camlibs/ptp.c which enables libgphoto cache all info on all images. The slowdown is about 3.2-3.5sec per each 150 images.

I recompiled libgphoto to have ptp_getobjecthandles return OK early and without querying camera to list all objects. That did remove the slowdown compelely.

As far as I understand, the MTP protocol that Theta uses should return new image handle on image add event and that handle can be used to fetch the image and delete it from camera and will avoid slowdown, unless I am missing something. If libgphoto could support that workflow without the hack above, that would be ideal.

msmeissn commented 3 years ago

I try to handle the filesystem access in an on-demand fashion already, which you probably saw.

This on demand is per directory, so it should fetch only directories needed.

Currently this "just return added objects" is only available by hacking the driver. Hmm. I could consider some option setting perhaps.