Every JPG file is always renamed with a number which is -1 compared to the corresponding RAW file.
Thus far I’ve noticed it only with a Fujifilm X100V (the only camera I’m shooting both RAW and JPG).
I’m on version 0.9.22 (updated today), but I’m pretty sure I’ve noticed this also on previous one (I didn’t give too much importance then, I didn’t actually needed to rename, so I simply discarded the download and copied the files over).
On the left the file in the camera, on the right after RPD dowloaded them.
The first photos are n. 0910, but they are renamed into 0000 and 0001, instead of both into 0001. This then skews all of them. In this way I’m not able to use RPD. I’m simply copying the files without RPD for the moment.
This can be consistently replicated.
I use “Stored number 4 digit” as a sequence item in the renaming scheme.
Is this a known bug? Or should I report it?
Am I maybe missing something or doing something wrong? I’ve been using RPD for years now and this is the first time this thing happens.
Edit:
I’ve uninstalled the latest version 0.9.22, which I installed with the Python script, and installed instead RPD from Ubuntu Software (I have 18.04), where it’s at version 0.9.9, and that one works properly.
So, I’d say this is a bug which appeared somewhen after this 0.9.9. I’ll live with the Ubuntu repo version for now, but I’m available to help reporting and fixing the bug, if needed (I never looked into RPD, but I have Python expertise).
It’s probably related to the fix for bug #1842060: Wrong value saved for stored number, introduced in 0.9.19b3.
File a bug report and be certain to include all in your bug report all the log files, which are found in the log directory ~/.cache/rapid-photo-downloader/log. You can open the log file directory by clicking on the link in the “Report a Problem” dialog window. In this instance you must also include the configuration file found in the directory ~/.config/Rapid Photo Downloader/. You can put all the files to include in a zip or tar file to save time.
If you don’t mind me asking why are you using this sequence number instead of “Downloads Today”? I assume you have a good reason for doing so. Do you mind sharing what it is?
I’m running 0.9.18, I do use the stored number in file names, and am not experiencing this problem. That would seem to support the idea that the problem was introduced after 0.9.18.
Most of the times I have multiple set on the camera, and if I want to put them in dedicated folders for each, in which numbering is starting from 1.
For example, if I have on camera: “photos_from_hike” and “photos_from_party”, when I download them in their folder, is there another way to give them their own numbering?
By the way… I know in general I’m not using the flow exactly as inteded in RPD, I think (I remember a few discussion int the past…). For instance, my folders scheme is “YYYYMMDD_photos_from_holiday”; if the holiday lasted more that a day, then I call the folder “YYMMXX_…” where “XX” is a fixed string, not a variable. I prefer not having deep folder structures.
Edit: I forgot to mention that I’m aware I could achieve the same by overwriting the number in the “Downloads today” field. I think the reason I’m using sequence is more historical maybe… (I actually don’t really need RPD to remember the number across sessions).
Edit2: I’ve just tried with 0.9.22, while collecting data for the bug report, and I can confirm that the bug affects only the “Stored number”. Using the “Downloads today” counter works as expected, the JPG files are in sync with the RAW files.
Is there a way to retrieve v 0.9.18 (or previous versions so I could test)?
The one from Ubuntu (0.9.9) I think has a little issue, it seems, (at least in my case) that the stored number is not correctly initialized by the number that is typed in the field (it goes on no matter what you type there).
Edit: I confirm in 0.9.22, the “Stored number” can be correctly edited and the renaming is then correctly done (except for JPG files, of course).
Great, thanks.
I think for now I’ll use 0.9.22, using “Downloads today” number. I just have to remember to type a number which -1 compared to the first number I want the naming to start from. I think that’s the main reason why I prefer the "Stored " sequence.
I should have time, though, in the next days to test in which version occurred this issue first.
So, just to conclude this topic, in the latest version (0.24) this is fixed.
I guess it was already fixed in the previous 0.23, but I didn’t use it so I can’t confirm.
Thanks @damonlynch for your quick support and for fixing it. I really appreciate your good work.
