I am using Airnef to download pictures from my Canon DSLR camera through python.
I can download one picture without problems so the whole setup seems to work. However, as soon as I want to download another image the software hangs. The code to me looks quite complex.
Two months ago I did post a thread on TestCams.com. Since I haven't gotten a response, I post this as a python-related question here.
I start airnef from the command line.
python airnefcmd.py --ipaddress 192.168.188.84 --action getfiles --realtimedownload only --downloadexec open @pf@ --transferorder newestfirst --outputdir "/Users/besi/Desktop"
I connect the camera and I’m shown some information about my connection:
Connection established to 192.168.188.84:15740
Camera Model “Canon EOS 200D”, S/N “XXXXXXXXX”
Now airnef tells me:
Waiting for realtime photos from camera to download.
Press to exit |
I take a picture and it downloads it as expected:
Downloading “IMG_0084.JPG”: 96%
Airnef then shows some more information about this image:
/Users/besi/Desktop/IMG_0084.JPG [size = 4,602,357] in 1.94 seconds (2.26 MB/s)
I take some more pictures but they’re not downloaded and the software is stuck at the prompt:
Waiting for realtime photos from camera to download. Press to exit \
The source code is available at the Airnef Website. I created a github repository for tackling this issue: https://github.com/besi/airnef
The place where the code is stuck is at airnefcmd.py:3203
Here is the link to the forum post on testcams.com
The first image called IMG_0182 was downloaded successfully.
In the debug output I can see a new picture being taken, but the download is skipped because the prior image was already downloaded:
See airnef.log:433:
filename = DCIM\100CANON\IMG_0183.JPG
captureDateSt = 20180926T071759
modificationDateStr= 20180926T071758
A new image called IMG_0183.JPG was found.
Skipping IMG_0182.JPG - already downloaded this session
The old downloaded image seems to block the further processing of the current image.
Skipping 100CANON - object is not file - MTP_OBJFORMAT_Assocation (0x3001)
Skipping DCIM - object is not file - MTP_OBJFORMAT_Assocation (0x3001)
Waiting for realtime photos from camera to download. Press <ctrl-c> to exit -execMtpOp: MTP_OP_GetObjectHandles - CmdReq payload:
Now we end up again in the loop waiting for more pictures. When a new picture is taken, the same procedure happens again.
I don't have a compatible camera, so I'm basing my answer solely on the logs (in Debug mode) posted on the forum.
Also it was a trial and error suggestion in one of the comments, so it's not the "scientific" approach (where the cause is being identified, and then fixed).
A team (@Besi and I) effort was required in order to come up with this answer (and the credit should be split accordingly).
According to logs, there is a difference between how the 2 files are handled:
... filename = DCIM\100CANON\IMG_0182.JPG captureDateSt = 20180926T071747 modificationDateStr= 20180926T071748 Download history file “/Users/besi/Library/Application Support/airnef/appdata/Canon EOS 200D-SN59074c1578e347a3bf1f6f85e8dec624-downloadhist” loaded – 53 entries >> MTP_OP_GetObject Downloading “IMG_0182.JPG”: 0%IMG_0182.JPG – downloading next piece, offset=0x0, count=0x100000 ... filename = DCIM\100CANON\IMG_0183.JPG captureDateSt = 20180926T071759 modificationDateStr= 20180926T071758 Skipping IMG_0182.JPG – already downloaded this session Skipping 100CANON – object is not file – MTP_OBJFORMAT_Assocation (0x3001) Skipping DCIM – object is not file – MTP_OBJFORMAT_Assocation (0x3001) Waiting for realtime photos from camera to download. Press <ctrl-c> to exit -execMtpOp: MTP_OP_GetObjectHandles – CmdReq payload: ...
As seen when handling the 2nd file (IMG_0183.JPG), the existence of the 1st one (IMG_0182.JPG), triggers everything to be abandoned.
Browsing [TestCams]: airnef - Wireless download from your Nikon Camera!, one of the command line argument (actually, there were more that I suggested) caught my eye:
--rtd_mtppollingmethod_newobjdetection, and I suggested specifying numobjs (and thus, overriding the default). Apparently, this was the (main) problem.
The other part was the presence of --transferorder newestfirst. By default, in Realtime Download mode, it's set to oldestfirst (see below). Removing it (or redundantly specifying --transferorder oldestfirst) did the trick.
Conclusion
In order to fix the problem, 2 things were necessary (in terms of cmdline args for airnefcmd.py):
According to [GitHub]: besi/airnef - (master) airnef/airnefcmd.py#3403:
g.args['transferorder'] = 'oldestfirst' # so that downloadMtpFileObjects() will properly enumerate through multiple realtime images as we add them
I consider this a bug on airnef's side (regarding --transferorder). It's located in either