Python program Airnef stuck while downloading images

MacOS

Question or issue on macOS:

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 @[email protected] --transferorder newestfirst --outputdir "/Users/besi/Desktop"

I connect the camera and I’m shown some information about my connection:

Now airnef tells me:

I take a picture and it downloads it as expected:

Airnef then shows some more information about this image:

I take some more pictures but they’re not downloaded and the software is stuck at the prompt:

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  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.

How to solve this problem?

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 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):

  • Specify –rtd_mtppollingmethod_newobjdetection numobjs
  • Remove –transferorder newestfirst

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

  • Code: –transferorder should be ignored when in Realtime mode
  • Doc: Specify that –transferorder newestfirst is not compatible with Realtime mode

Hope this helps!