Rapid Photo Downloader 0.9.12 is released

The most important aspects of this release are Python 3.7 compatibility and support for the Canon CR3 file format. See the release notes if your version of ExifTool needs to be upgraded to be able to read CR3 files.

Full change log:

- Added support for Canon CR3 format. Requires ExifTool 10.87 or newer.
See the release notes for details on upgrading ExifTool. Note: program
performance with CR3 files is notably slower than other photo file formats.
Other photo file formats are read using the high performance library exiv2
to read metadata and extract thumbnails. Unfortunately exiv2 does not yet
support the CR3 format. Exiv2 0.28 will support the CR3 format.

- Fixed bug #1790351: Video date time metadata not parsed correctly when
‘DST’ appears in time zone component.

- Added support for FFF and IIQ raw formats.

- The MOS and MRW formats are now handled by ExifTool, not exiv2.

- Better handle Exif date time values that unwisely deviate from the Exif
Version 2.3 specification, e.g. Hasselblad files.

- Fixed bug #1790278: File renaming and subfolder generation editor breaks
with Python 3.7.

- Updated installation script to use “loose” instead of “strict” Python
version checking.

- Fixed bug in installation script where a system installed Rapid Photo
Downloader package was not being uninstalled.

- Fixed bug #1791131: Report fatal camera access problem without crashing

- Improved install.py script to install libmediainfo0 on openSUSE where the
package exists.


thanks for the release! I’m also happy to announce there is now a new maintainer of the Debian package who uploaded the new version 5 days ago, and it trickled down into testing without problem. i did find a release critical bug, but it’s probably a packaging issue on our side.

1 Like

This may help:


and the thread here:


Perhaps some Debian patches to PyQt5 are the cause of the problem?

This says that

from PyQt5 import QtCore
import sip

… is safe, and i can confirm that doing just import sip in RPD works correctly:


So I wonder if it’s really a packaging problem on our side…

But it’s true there might be a module missing in pyqt5 in Debian. It is customary, however, to avoid shipping duplicate copies of code in Debian, so this might actually be deliberate.

I recall that Debian patches pip, so if Debian is patching PyQt5 in an unexpected way it wouldn’t surprise me.

I tested the code against PyQt5 < 5.11 and >= 5.11 and it works. Hence my suspicion that something else is happening in Debian that breaks that test.

While it is possible to simply import sip, as it says in the PyQt5 docs it will not work if the order of the import statements is reversed (i.e. import sip must come after importing something else from PyQt5). I strongly prefer explicit to implicit, so that’s why I put in the explicit test.

If that is breaking due to something happening in Debian then I may need to revisit it. Practicality beats purity.

@anarcat I’m not sure what was changed in the most recent Debian package, but I see the status message “Use python3-sip module, not the bundled copy of PyQt5.”

PyQt5 >= 5.11 uses its own private copy of sip because it must, according to the PyQt 5 developer. See https://pypi.org/project/PyQt5-sip/

The code in Rapid Photo Downloader 0.9.12 works on the latest versions of Arch and openSUSE without problems. As far as I know they do not need to patch anything in PyQt 5 or Rapid Photo Downloader.

If Debian is forcing PyQt5 >= 5.11 to use the the copy of sip that is not specific to PyQt, then I anticipate that will break PyQt5 in unexpected ways.

Sigh. So the maintainer just picked my patch as is and used it…

I’ll notify the maintainer.

It looks like the python3-pyqt5 in Debian is patched to use the external sip library.

In the Debian Changelog at this link we see the following entries:

  • Use the public version of sip module, per Policy § 4.13.
  • Bump sip build-dependencies to 4.19.11, following configure.py.
  • Update public_sip.diff, revert some more upstream changes.

This seems to be the source of the problem.

1 Like

Thank you for investigating @Kirtai . Dmitry is a smart and experienced maintainer. He is active on the PyQt mailing list, submitting patches too. I don’t know why these Debian specific changes to the PyQt5 Debian package were made. Perhaps he is trying to avoid breaking existing packages in the Debian archive that expect the old PyQt5 / sip import behavior. I don’t know – I’m just speculating.

It seems likely that the “Use the public version of sip module, per Policy § 4.13.” in the changelog was referring to Debian Policy 4.13 which says to remove bundled copies of code that an application uses for convenience and replace them with proper dependencies when making a package.

Letting him know that this isn’t one of those cases would hopefully be enough.