9

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.

Besi
  • 22,579
  • 24
  • 131
  • 223
  • Dumb question: are there any other **realtime** photos on the camera? Or it just waits for one to be taken? – CristiFati Sep 25 '18 at 11:34
  • Also, are the times on computer and camera synchronized? – CristiFati Sep 25 '18 at 11:51
  • @CristiFati: It‘s always like this. I start the session. All is good and conneced. I take a picture. It‘s downloaded onto my Desktop. I take several more pictures but they‘re not downloaded. The times are in sync. For testing I did take pictures of http://time.is in my browser. – Besi Sep 25 '18 at 20:11
  • What if you take pics one by one (wait between them)? Also after the 1st pic is taken, the times stay in sync (no different timezones, etc)? *open* is an executable? (based on paths I assume you're on *OSX*). `--downloadexec` would be normally at the end (how does it know when the args for the executable are over, and the next one should be processed?, or enclosed in quotes?). Did you try dropping it (or others) to see if anything changes? Is the 1st file open after download? Note: I've never worked with *airnef*, sorry for (maybe) giving you false hope. – CristiFati Sep 25 '18 at 20:28
  • @CristiFati: The parameters I‘m using seem fine because the first image is downloaded and opened. Yes `open ` is a command on macOS. It is equivalent to a double click in the Finder (Explorer). So the images are simply opened once they‘re downloaded. – Besi Sep 26 '18 at 22:25
  • 1
    Apparently, when trying to download the 2nd picture, it sees the 1st one, and then ignores everything. Not sure whether it's a bug, or smth related to your camera, you could play with some parameters: `--downloadhistory ignore` (it might download each file multiple times), or `--rtd_mtppollingmethod_newobjdetection numobjs`, or as a workaround figure a way to delete a file on the camera once it's downloaded. – CristiFati Sep 28 '18 at 12:20
  • @CristiFati: The `numobjs` parameter in conjunction with `--transferorder oldestfirst` did the trick. You may add an answer which I will happily accept. – Besi Sep 28 '18 at 13:39
  • So this is the lucky combo? Neither of the 2 args doesn't do the trick alone? Smth seems "fishy" :). – CristiFati Sep 28 '18 at 14:10
  • @CristiFati: Actually the default for `transferorder` is `oldestfirst`. So while it's true the `rtd_mtppollingmethod_newobjdetection` flag does fix the problem, but once `newestfirst` is enabled then this no longer works. That means it is indeed the lucky combo. It's likely that this is a bug, which I did point out in the [testcams forum](http://testcams.com/blog/forums/topic/only-first-image-downloaded-from-canon-camera/#post-9725) – Besi Sep 28 '18 at 15:09
  • I followed the forum (I looked at the message exchange and noticed the current behavior). Also, I've noticed that *oldestfirst* is the default for realtime: https://github.com/besi/airnef/blob/master/airnefcmd.py#L3403. So, if `--transferorder` is not specified at all, it should work as well. The reason of me asking is I'm trying to narrow down the problem as much as possible, and unfortunately I don't have a camera (I have an ancient Canon S5 IS which definitely isn't supported) to test it myself with. – CristiFati Sep 28 '18 at 15:34
  • @CristiFati: "So, if --transferorder is not specified at all, it should work as well": This is correct. With the debug enabled and the `transferorder` set to `newestfirst` I did see the new images being listed in the output but they were not transferred (See my updated question). – Besi Sep 28 '18 at 15:58
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/180958/discussion-between-besi-and-cristifati). – Besi Sep 28 '18 at 19:27

1 Answers1

2

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

  • 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
CristiFati
  • 38,250
  • 9
  • 50
  • 87