What I did: Folder 1 -- add +2 h Folder 2 -- add +2 h Folder 3 -- add +2 h ... Folder 6 -- add +2 h Result: Files in the first folder have been changed to +12 hours, files in the second to +10 hours, etc. This is very not sexy. But I guess re-starting after each date adjustment should work ... Reproducible: Always
PS – Closing Digikam after each adjustment did work.
Simon, please update to last 2.7.0 and confirm... Smit, i CC you if it's relevant of parallelization of processing... Gilles Caulier
Hi Simon I am not able to reproduce it here. As far as I understand, these must have been your steps to reproduce : (a) open the required folder, select the images, and open "adjust time and date" (b) you select "add 2h" (c) you select ____ timestamps to be changed. which of those 8 timestamps are giving this behaviour? and by folder, do you mean the albums in digikam? or you are using this plugin from somewhere else, and not digikam/ Smit
Hi Smit, I selected all of the 8 timestamps except for the file name to be updated. For processing I selected all files in one folder of an album. I'm using it from inside digikam. In Debian testing there is only 2.6, but I can test 2.7 as soon as possible. After each step I closed the dialog for adjusting date and time, but it seems that the images did not get removed from the list there. (I did not check the file names however.) Simon
Hi Simon Okay. Kindly test it on 2.7 when it releases. Also, does it affect all the seven options you select? or just some specific options only? Mostly it should affect everything. I will try to reproduce it here again. As you suggested, mostly this should be a problem with previous images not being removed from the processing list. Smit
Git commit 08ca3eb552bc8ee83ed896bed511d737e2bb1dd5 by Smit Mehta. Committed on 30/08/2012 at 16:35. Pushed by smitmehta into branch 'master'. Clearing itemsUpdatedMap when adding images. M +1 -0 timeadjust/timeadjustdialog.cpp http://commits.kde.org/kipi-plugins/08ca3eb552bc8ee83ed896bed511d737e2bb1dd5
Hi Simon Kindly check now against the latest git/master. Smit
Hi Simon I am not able to reproduce it here, and the commit in comment #6, should have solved it, hence I am closing this bug. Feel free to reopen it / file a new one, in case you are still able to reproduce it in any version >= 2.9.0