Python программа Airnef застряла при загрузке изображений
Я использую Airnef для загрузки изображений с камеры Canon DSLR через python.
Я могу загрузить одну картинку без проблем, поэтому кажется, что вся установка работает. Однако, как только я хочу скачать другой образ, программа зависает. Код для меня выглядит довольно сложным.
Два месяца назад я опубликовал тему на TestCams.com. Поскольку я не получил ответа, я публикую его как вопрос, связанный с питоном.
Нить
Я запускаю airnef из командной строки.
python airnefcmd.py --ipaddress 192.168.188.84 --action getfiles --realtimedownload only --downloadexec open @pf@ --transferorder newestfirst --outputdir "/Users/besi/Desktop"
Я подключаю камеру, и мне показывают некоторую информацию о моем подключении:
Соединение установлено с 192.168.188.84:15740
Модель камеры "Canon EOS 200D", S/N "XXXXXXXXX"
Теперь airnef говорит мне:
В ожидании загрузки фотографий с камеры в реальном времени.
Нажмите для выхода |
Я делаю снимок, и он загружает его, как и ожидалось:
Загрузка "IMG_0084.JPG": 96%
Airnef затем показывает еще немного информации об этом изображении:
/Users/besi/Desktop/IMG_0084.JPG [размер = 4 602 357] за 1,94 секунды (2,26 МБ / с)
Я делаю еще несколько снимков, но они не загружаются, и программное обеспечение застревает в приглашении:
В ожидании загрузки фотографий с камеры в реальном времени. Нажмите, чтобы выйти \
Исходный код
Исходный код доступен на веб-сайте Airnef. Я создал Github-репозиторий для решения этой проблемы: https://github.com/besi/airnef
Место, где застрял код, находится на airnefcmd.py:3203
Обновление: сообщение на форуме
Вот ссылка на пост форума на testcams.com
Обновление: отладка
Первое изображение IMG_0182 было успешно загружено.
В выводе отладки я вижу, что делается новый снимок, но загрузка пропускается, так как предыдущий образ уже был загружен:
Смотрите airnef.log: 433:
filename = DCIM\100CANON\IMG_0183.JPG
captureDateSt = 20180926T071759
modificationDateStr= 20180926T071758
Новое изображение под названием IMG_0183.JPG
был найден.
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:
Теперь мы снова попадаем в цикл, ожидая больше фотографий. Когда делается новый снимок, такая же процедура повторяется снова.
1 ответ
У меня нет совместимой камеры, поэтому я основываю свой ответ исключительно на журналах (в режиме отладки), размещенных на форуме.
Также это было предложение проб и ошибок в одном из комментариев, так что это не "научный" подход (где причина идентифицируется, а затем исправляется).
Чтобы придумать этот ответ, потребовалась команда (@Besi и я) (и кредит должен быть соответствующим образом разделен).
Согласно журналам, есть разница между обработкой двух файлов:
... 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 ... ilename = 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: ...
Как видно при обработке 2- го файла (IMG_0183.JPG), наличие 1- го (IMG_0182.JPG) вызывает все, что должно быть прекращено.
Просмотр [TestCams]: airnef - Беспроводная загрузка с камеры Nikon! один из аргументов командной строки (на самом деле, было больше, что я предложил) привлек мое внимание: --rtd_mtppollingmethod_newobjdetection, и я предложил указать numobjs (и, таким образом, переопределить значение по умолчанию). Видимо это была (главная) проблема.
Другой частью этого было присутствие --transferorder newestfirst
, По умолчанию в режиме загрузки в реальном времени он установлен на самое старое (см. Ниже). Удаление его (или избыточное указание --transferorder oldestfirst
) сделал свое дело.
Заключение
Чтобы решить проблему, потребовалось 2 вещи (в терминах аргументов cmdline для airnefcmd.py):
- Уточнить
--rtd_mtppollingmethod_newobjdetection numobjs
- Удалить
--transferorder newestfirst
Согласно [GitHub]: besi/airnef - (основной) airnef / airnefcmd.py: 3403:
g.args['transferorder'] = 'oldestfirst' # so that downloadMtpFileObjects() will properly enumerate through multiple realtime images as we add them
Я считаю это ошибкой со стороны airnef (в отношении --transferorder). Он расположен в любом
- Код: --transferorder должен игнорироваться в режиме реального времени
- Док: Укажите, что
--transferorder newestfirst
не совместим с режимом реального времени