Python program Airnef stuck while downloading images

Question

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.

The thread

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 \

Source code

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

Update: Forum Post

Here is the link to the forum post on testcams.com

Update: Debugging

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.

Answer 1

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 2^nd file (IMG_0183.JPG), the existence of the 1^st 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