Wow somehow I didn’t notice/understand that the job code was already there in 0.4, will start using 
I’ve been playing with RPD 0.9.0a4 this week, and I am really impressed with the general layout and flow. So far, I’ve tried it with a Samsung Galaxy S5, a Canon point and shoot, a Nikon D7000, and a SD card removed from the Canon, and it has worked well for all of them (other than the known hassles you documented for the phone). The timeline with adjustable proximity setting is a super way to find the logical breaks between sessions. Once the job code is implemented, I think RPD will do exactly what I believe I need. It tries to do one thing well, rather than trying to do a mediocre job of a whole bunch of things.
I’d be interested to know how you plan to implement the job codes. The implementation probably matters more when importing a lot of historical work than it does once you’re settled in and just downloading a couple of sessions at a time. Personally, I think being able to do something like right-clicking on a grouping in the timeline to access a control to set the job code for that grouping would be a good way to go. That would allow you to label a large number of jobs, start the download, and just let it rip.
Two non-defect things I found less than ideal:
-
I found the thumbnail size to be barely large enough for me to identify what a session was. It would be nice to have a setting to customize the thumbnail size (not necessarily freely, just having a few choices would do).
-
I did not find a reliable way to select all the photos from a session, and only those photos. Clicking a session in the timeline caused only the photos from that session to appear as thumbnails, but doing common things like selecting the first of these and shift-selecting the last of these did not have the desired effect of selecting the entire group. I would either wind up with only those two photos selected, or the entire contents of the camera or card. This may be ignorance on my part, but I could not locate doc for selection and tried a lot of things and wound up individually selecting each thumbnail.
Overall, great package, and I’m looking forward to trying out the next alpha release.
1 Like
EXIF thumbnails are 160x120. That’s a real limitation in the sense that generating thumbnails larger than that makes generating thumbnails a lot slower, particularly but not limited to when downloading directly from cameras. Handling larger thumbnail sizes also makes the thumbnail generation code quite a bit more complex, which makes the code harder to write and harder to maintain, and thus delays the release. So it’s firmly in the “nice to have one day in the undetermined future” basket of goodies.
Works for me. Keep in mind the “Select All” checkboxes in the bottom right of the window.
If you can reproduce an exact set of steps to reproduce a bug, then please file a bug report. It’s possible there is a bug because the code driving the selection logic is surprisingly complex.
1 Like
I’ve filed a bug for the selection issue I ran into, and another one related to selections affected by the granularity of the timeline. While I was recreating the selection problem, I encountered a couple of other selection issues as well. Would you prefer me to add those other scenarios to the bug I already created, or create a separate bug for each one?
Have been using the tool for the last two days in order to improve my workflow which up until now included mainly:
cp/find + exiftool + darktable
This is my feedback for v0.9.0b5:
Rapid Downloader as Categorizing and Downloading:
Bug: Slashes in job names create directories
Bug: Above 1000 downloads does nothing / breaks up
Bug: Subseconds is broken, if tag is missing returns nothing (and not 00 as documented, though I see nothing as a better solution)
Req: Queue multiple downloads while freeing the GUI for more work.
Req: Remember applied job names after application restart (currently is lost and task needs to be redone)
Rapid Downloader as Renamer:
Req: Parallelizing Download and Renaming. Here I am not sure but I have the feeling next file does not start to download
until previous file is renamed.
Req: The same way one can create and manage Job Codes, one could manage tag perset formatings (ie: my own date format availible as one entry from the pull down menu)
Req: Extend the automatic _1 _2 automatic suffixing into its own tag, ie <samnanecounter (two digits)>. That we the user decides where it goes and how it is formatted
Req: Non existing tags should return nothing.
Req: Add Camera model to Videos
Req: Offer simpler configuration, where Videos and Pictures have the same destination and renaming strategy.
Req: tag grouping to use the first existing tag: ie () or ()
Req: Conditional text, ie: add dot only if subseconds defined: (.)
Req: Add many more tags. To avoid clutter there could be a pick up window to add user specific tags
After two days of testing I have decided to use RPD to download files this way:
< DESTINATION >/< YYYY.MM.DD > < Job Name >/< OriginalName >
This helps me to find, chose and download all what it needs to be downloaded and has not yet been downloaded into a themed and dated directory.
I continue with exiftool (hopefully RPD would implement stuff to achieve similar results(
Exiftool renames the downloaded files to:
Albums/< directory name as created by RPD >/< DATE as YYYY.MM.DD HH.mm.ss >.< ## > < MODEL >.< ext >
where
DATE is taken from the first match of:
- $DateTimeOriginal
- $CreateDate
- Uknown (This will tell me to inspect such file with exiftool to find another Tag containing date information)
<##> is taken from the first match of:
- $SubsecTimeOriginal
- $ShotNumberSincePowerUp two digits zero leading
- Exiftool generated index counter of identical file names, two digits leazing zero, fallback if no info found in metadata
MODEL is taken from the first match of
- $Model
- $DeviceModelName
- Uknown (This will tell me to inspect such file with exiftool to find another Tag containing model information)
Cheers, Ariel.
P.S. My Timeline looks different (bug?). I attach screenshot
Thanks for your feedback Ariel. Judging by the screenshot I guess you’re using it to rename files that you’ve already downloaded and possibly edited. Is that correct? I mention that because it appears possible the date time metadata in some (many?) of your files is mangled. I suggest that because the Timeline should be dislaying correct time values, but it’s not.
Please note if you’re intending to use the program as a general purpose file renaming tool for files you’ve already worked on, you should probably be using another tool. See the FAQ, which I updated today: Rapid Photo Downloader: Frequently Asked Questions (FAQ)
Some observations:
You cannot use a forward slash in your filenames, just like you can’t have a filename of only a dot or two dots. Filename - Wikipedia
File a bug report with the log files and a description of the problem. Do note this FAQ entry, however: Rapid Photo Downloader: Frequently Asked Questions (FAQ)
What do you by it’s “broken”? Are you saying your photos have subsecond metadata but the program is not extracting them? I’ve updated the documentation to remove the reference to ‘00’ being added , which is a holdover from the legacy version, and no longer valid.
Not a chance, sorry. On the to do list is save presets as a download profiles.
An interesting idea. But what is the use case for it? Why would you need it?
Nope. See this discussion of how it works.
You can already create and save your own file renaming and subfolder preferences, which makes adding them to the combo boxes in the subfolder generation / file renaming editors redundant.
The program provides a variety of sequence numbers to generate unique filenames. Use them if you like, or not, it’s up to you.
Sorry I don’t understand what you mean here.
It’s a nice idea, but getting the metadata from which tool, ExifTool or libmediainfo? Which is more reliable?
Not a chance, because the metadata between photos and videos is different, and because historically, users have specifically requested they be different, including for backup destinations.
That seems complicated to implement in a GUI, and I’m not about to rewrite the existing name editors given the huge amount of work it was to write them as they currently exist. But more generally, I’m not aware of any GUI program that provides such a feature. Do you (or anyone else) know of one?
It’s an interesting idea for a future version. But actually implementing it in a GUI so that the majority of users are not confused strikes me as rather tricky, so I’m not sure at this point if it would ever be implemented.
More generally, given your use of conditional tags, which are far easier to configure using a non-GUI tool, my impression is that Rapid Photo Downloader is not the correct tool for your needs.
By “tags” I assume you mean metadata. Which metadata, precisely?
Not really, I tried to document something I saw while downloading which looked similar while checking ms SD card again (that’s the screenshot; not trying to use the tool for further renaming, I used exiftool for that). And both look different from the above posts.
You forgot to include the previous line
“File system utilities and naming conventions on Windows prohibit…”
In unix we are more forgiving.
Your tool accepts “:” in the job name (also prohibited in that list) and expands properly.
It also accepts the “/”, but it does not expand and creates directories instead.
If accepting the / in the job name is a feature for creating sub-directories, document it as such.
If it was an unexpected behavior, reject it or let it expand as part of the directory or file name.
Currently is a confusing behavior.
I see this was a documentation bug that you just fixed, thanks
These are two altogether different things.
Currently I can select a bunch of pictures, tag them with different job names and press download (in my wifi case takes a long time)
While it is downloading I am able to continue and select another bunch of files. Here I need to wait. When the download is over I can apply a job name to the already selected pictures. It would have been great if I would have been able to apply job names and continue selecting and applying job names while downloading. And if I could queue these new selections for downloading and then go for lunch even better.
Similar to the above response. If I apply a Job name and for for whatever reason the download is not clicked, all that cataloging work is lost. It happen to me a few times. We can either fix the user or make and improved GUI
All the time presets you provide are redundant too for that all matters, users can build them on their own with the basic blocks. It’s all about convenience, but the same can be achieved without it.
The program provides some sequence numbers for series of pictures. Download series.
It also provides a rudimentary index number for duplicate names (ie: 3 pictures within the same second) I proposed to make this index number (lets call it dupindex) more versatile and consistent with the rest:
the same way you have < Video number (All digits) > or < Video number (two digits) >, you could place this variable into < dupindex (two digits) > and let the user place it and format it as pleased. In exiftool there is something identical and very useful with lots of adepts.
I like Exiftool, but I cannot tell you from where your implementation needs to take it. But I will expand on this below.
Yes and no. In exiftool I can use (full path) $exif:originaltime or $originaltime. The second will pick up ANY originaltime, even if it comes from alternative XMP or quicktime tags. If found, it is expanded, if empty, it returns an empty string.
In the iPhone era, I guess many people would also like to have all their pictures and short videos together and sorted chronologically, one directory, one naming convention, Of course we can say this is for more sophisticated users which will not mind to have identical configurations for pics and videos if they mind so.
FileBot is using it, it inherits from groovy.
I imagine you could add OR/AND/NOT and some sort of grouping to the GUI.
FIleBot is similar, with a GUI that in fact creates a text definition, which could also be entered and edited manually.
For the GUI, you could define some Conditional Text, which will expand only if next tag returns true.
Let me see my FileBot definition for movies:
{mTitle}{’ 3D’+s3d.upper()} ({y})
in this case, mTitle will expand only it it exists, ’ 3D H-SBS’ will expand only if s3d tag exists and (1998) assumes that a year will always be returned.
Of course I could list the metadata I particularly use like (let me check my script) for ANY type of file, Video or Photos:
DateTimeOriginal
CreateDate
FileModifyDate
SubSecTimeOriginal
ShotNumberSincePowerUp
Model
DeviceModelName
but I do not know, I add dynamically new tags as needed (I recently found that a camera had no SubSecTimeOriginal but it did have ShotNumberSincePowerUp, which provided an analogous outcome. Your tool could accept user added metadata definitions. Like giving me the chance to add DeviceModelName myself. This would be probably the most powerful addition from all of what I have mentioned so far.
Cheers, Ariel.
I’m not going to reply to each and every item because it takes too long. Some comments:
- I’m the one who answers emails from users who are trying to figure things out. I’m the one who writes the code. This project is over 10 years old, so I’ve been doing it for a while. The program is designed the way it is because I’m trying to meet the needs of a very wide range of users, from the most simple to the most sophisticated. When I say there is “no chance” of changing the fundamental design of the program so that it can be used a different way, I mean it. I will not write at length justifying and explaining those design decisions.
- / cannot be used as a filename character in Unix like systems. Reread the link.
- I cannot diagnose bugs without a proper bug report, including the program’s log files and an adequate description of how to reproduce the problem, including the source files if necessary. If you’ve found a bug, file a bug report.
2 Likes
-
Cool down. It’s your software, it’s free. You do whatever you want with it, You explicitly asked for feedback. My way of paying you is providing my feedback. As you put it “reply to each and every item because it takes too long”. You can see the length of my answer, I invested a good deal of time to provide feedback. Take what you want, trash the rest. You do not need to justify yourself explaining how supportive you are.
-
I think the program would be more user friendly if you rejected the / in the job name, or if you alerted that sub-directories will be created. Job names are created all the time, and if someone would put one there by distraction. will discover after the fact that files are not where intended but in a structure that will need to be undone and fix it. I am one fool who bore the consequences.
-
As I said before, bugs I was going to do it properly through the bug tracker. Comments about bugs are here are just “in case it is trivial and you did not see it”. To report the download problem for 1000+ files and others bugs properly requires a good deal of time. But I believe I just lost my will to spend more time on this.
Success.
Ariel, you misunderstood my message. I literally don’t have time to write an extensive reply to the type of feedback you’re giving and the requests you are making. I don’t know how to make it any clearer.
Although I’d never heard of FileBot before, much less used it, my impression based on its screenshots is that its renaming system is more akin to writing a regular expression than the kind of renaming tools available in Rapid Photo Downloader (or Lightroom or Photo Mechanic or other tools). Which is fine. Some users want that extra power and flexibility. That’s why I suggested ExifTool is the better tool for you. Generally speaking, ExifTool is the best tool for some jobs. Exiv2 is better in some other circumstances. Rapid Photo Downloader has its niche too.
Thanks for a wonderful tool. I’ve just started to use it regularly.
There seems to be an operational anomaly on startup.
When I start the program without a camera attached to the usb bus it works. When I then attach the camera it see the camera.
but
if the camera is attached before startup it fails to startup. I have filed a bug report in the launchpad system with log file and error. Bug #1695012 “initial startup fails when camera is attached” : Bugs : Rapid Photo Downloader
It’s interesting to see that a 15 year old camera is still going strong 
I need a little more info to ensure my fix is going to work – you can add it to the bug report.
Thanks for your work, yea the old camera is working fine but i have my eye on a used sony A6??? as the years go by the old D100 is getting heavier and heavier and my travel bags are getting smaller and smaller.
Ive updated the bug report.
@alpinekid I updated the bug report with a request for some more information. Are you getting email notifications about bug from launchpad? I ask because it seems suddenly I’m not, which is quite odd.
yea, I havent seen anything either. what do you need?
Al
I’ve been using this since you announced the big update and so far it’s everything I’ve been hoping!
Normally, I pop my SD in to my laptop and Rapid Photo Downloader would start automatically. Recently, and I can’t remember when, that hasn’t been happening. I went into “default application” and “removable media” and Rapid Photo Downloader no longer shows up as an option.
I’m on Ubuntu 17.04.
FWIW, I like it not starting automatically. But that’s just me.
I think there was an option to have it auto start when a card/device was connected. Not sure, though.
It’s a strange problem. I don’t know why it stopped working. I can replicate it on a 17.04 VM, but not on my primary desktop which is running 17.10. I’ve opened bug this bug report: Bug #1713898 “program no longer appears as a removable media def...” : Bugs : Rapid Photo Downloader
If someone would like to look into it that would be helpful. It doesn’t require any programming expertise – it’s just a system integration item that is handled by by .desktop files.
Hi!
Obviously, this is late feedback, but since the conversation is still opened here I figured I would add my grain of salt.
I recently switched from my home-grown import script (based on exiftool and fim) to rapid-photo-downloader and I am quite happy with the results. I tried the old version that was in debian stable (0.4) and this was already an improvement over my haphazard process. The newer version (0.9.7) is of course a lot better, although there are still some rough edges for me.
- 0.4 allowed me to “move” the photos out of the memory card instead of copying them. i’d like to have that feature back, but i understand it’s tricky business. full discussion in:
- my home-grown script would automatically add the photos into git-annex, which allows me to manage archival and backup of the photos. i was hoping i could write a simple plugin to do that, but there is no plugin interface and adding one seems like a really daunting prospect, as discussed here:
- i am having trouble automatically mounting memory cards when i plug them in. for RPD to recognize the card, I first need to start a file manager (i use Thunar for that) to mount the card. i would have hoped that RPD does that on its own, and i’m not sure why that’s not working. it could be because I use a weird desktop environment (xmonad), i’d need to test this in GNOME to see if it works there.
Otherwise I wanted to make sure you got a positive feedback here. It can be demanding to run a free software project – i know, i run several 
– so I wanted to say: thank you, and good job!