Date/time tag based on first image in job

[Jan Larres]

Currently, the date and time tags in the destination and renaming presets are based either on the metadata of each individual image, or some external data like today's date. However, it would be really useful if there were another option: taking the date and time from the first (oldest) image of a specific job.

For example, say you take a trip over New Year's, and the pictures you take on that trip should all have the same job code. In this case, if you have a folder structure based on years, then the job will be split up into two different folders, or potentially even more if you have a more fine-grained folder structure. This makes dealing with this job a lot less convenient, for example because Darktable will import these two folders as two different film rolls, losing the connection between them. If all of the photos were instead put into folders based on the date of the first image of the trip/job, they would all end up in the same folder, making dealing with the job much more convenient.

This is pretty much the only thing that is preventing me from using RPD at the moment, because it makes it pretty much impossible to automatically download photos that should stay together unless I completely forgo a date-based folder structure. Thanks!

[Damon Lynch (dlynch3)]

Please share the configuration file 'Rapid Photo Downloader.conf', which is located in ~/.config/Rapid Photo Downloader

Thanks.

[Jan Larres (majutsushi)]

Hi, sorry for the late reply. Here is my configuration, although I'm not sure how it would really help since I can't configure it the way I want to due to this issue.

[Damon Lynch (dlynch3)]

What you're describing is not a bug. It's a feature request. In your case I suggest you create a subfolder yourself, e.g. 2017, and then download the files into that using a top level job code.

I have no plan to implement your particular feature request, because in my assessment the number of people likely to use it apart from yourself is extremely small indeed -- it could even be zero.