Rapid Photo Downloader 0.9.0b4 is released

Software Rapid Photo Downloader
1

Download it at the usual location.

Apologies to openSUSE Leap 42.2 and other python 3.4 users: for you it will be necessary to visit the aforementioned download page, because the built-in updater in versions before 0.9.0b4 crashes when attempting the automatic upgrade.

On a more positive note, I’ve added quite a bit of content to the online documentation in the last few days.

Changes in this release:

  • Added Help buttons to Program Preferences and File Renaming and Download
    Subfolder Generator editors that open the online documentation.

  • Added command line option to dump to the terminal basic information about
    attached cameras, which is useful for diagnosing potential problems with
    libgphoto2 and python-gphoto2.

  • Added dialog to inform user if the scan process had an unexpected fatal
    problem.

  • Added link to Changelog in dialog window notifying a new release is
    available.

  • Fixed bug on systems using Python 3.4 (such as openSUSE Leap 42.2) when
    creating a temporary directory during program upgrade.

  • Fixed bug where exception would occur when auto exit after download was
    activated.

  • Re-scan download sources after relevant program preference changes.

3 Likes
2

@damonlynch: as a long-time user I only just upgraded from the 0.4 series to the latest 0.9 (I’m on ArchLinux) and while setting up my file location- and renaming-preferences I came across something curious. I’ve always used a scheme whereby files are renamed with Jobcode as well as actual ISO value (makes it easy for me to group-process files with NR software) and then stored in a folder-structure which reflects both the year as well as the camera model used.

My presets in the configuration file are these:

preset_photo_rename\1\name=Standard
preset_photo_rename\1\pref_list=Filename, Name, Original Case, Text, -, , Job code, , , Text, -ISO, , Metadata, ISO,
preset_photo_subfolder\1\name=Standard-folder
preset_photo_subfolder\1\pref_list=Date time, Image date, YYYY, Text, -, , Metadata, Hyphenated short camera model, UPPERCASE, /, , , Date time, Image date, YY, Date time, Image date, MM, Date time, Image date, DD, Text, -, , Job code, ,

Example of the final on-disk structure:
> /FOTO/DCIM/2017-K-70/170429-Alkmaar/DMG00180-Alkmaar-ISO100.JPG for shots off my Pentax K-70
> /FOTO/DCIM/2017-GR/170223-Edinburgh2/R0008139-Edinburgh2-ISO3200.DNG for shots off the Ricoh GR

Of course I got it wrong a few times when setting this up so it would continue what I did in version 0.4 and I noticed I could not manage to re-import files off the SD card as the [Download] button remained greyed-out. Hovering over any individual file showed that the file had already been imported.

It is only by accident that I found when I did a select-all and then unselected one single image that the Download button became accessible once more. So re-importing all 30 files of an SD-card was impossible due to the files having been imported before. But reimporting first 29 files off the card and then the one remaining works!

Quite quirky and, now that I have my setup complete, it probably will not bite me again but I still thought a note on this behaviour would be useful.

3

@Mike_Bing you can read the explanation for the behavior you are seeing here: http://damonlynch.net/rapid/documentation/#previouslydownloadedfiles

As you have noticed, version 0.9 has changed in this respect compared to version 0.4. The ability not to download previously downloaded files was one of the most popular feature requests, along with the ability to download directly from a camera.

4

Thanks Damon and I got that. This behavior is highly appreciated. Having said that, my issue is that “If you want to download them again, you can check them for download by placing a checkmark beside them.” seems not to work if you select and checkmark all files simultanously (but all files minus one does). That’s the quirk I saw.

I hope this makes more sense as an explanation now.

5
  1. You toggle the checkmark by clicking in checkmark portion of a single thumbnail.
  2. However, if more than one file is selected, they’ll all take the mark of the file that was clicked in (step 1), regardless of their existing mark.

If you’re seeing something different, I’ll need the steps outlined so I can replicate the problem myself.

6

I can’t repeat the behavior so you can disregard. Must have been something entirely unrelated. My apologies for disturbing you!

7

No, not at all. I’ve never commissioned a usability study on the program, so receiving feedback that allows me to understand where users are facing difficulties is extremely helpful.

I want to include a “Did you know…” dialog box each time the program starts up, that will introduce features. Perhaps I’ll include that for the 0.9.0 final release, although that means it will be delayed. On the other hand I’ve already written plenty of documentation, which I think few users read :grinning: I can reuse that content for the “Did you know…” dialog.