[digikam] [Bug 455091] Renaming files on import loses image order in some cases

2022-06-24 Thread bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=455091

--- Comment #15 from myaccount...@protonmail.com ---
Just to let you know detecting already imported files appears to be cleared
while *changing the setting* whether metadata is read or not, and all files are
detected as new afterwards. 

Will check the updates when it's handy to upgrade, but this works well enough
now for this version.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 455091] Renaming files on import loses image order in some cases

2022-06-15 Thread Maik Qualmann
https://bugs.kde.org/show_bug.cgi?id=455091

--- Comment #14 from Maik Qualmann  ---
Git commit eeb5ba940b0b7e523200e791b9f98623ab75b65b by Maik Qualmann.
Committed on 15/06/2022 at 17:12.
Pushed by mqualmann into branch 'master'.

fix read creation date from imported items from Import Tool
- Metadata for renaming will only be read after saving in the album
- Correct creation of date based albums.
- Add metadata and camera renaming options in the Import Tool.
- Removed live renaming preview in import view,
  preview for selected item only.
Related: bug 452088, bug 444928, bug 386072, bug 381214
FIXED-IN: 8.0.0

M  +5-1NEWS
M  +9-1core/utilities/advancedrename/advancedrenamemanager.cpp
M  +1-0core/utilities/advancedrename/advancedrenamemanager.h
M  +2-0core/utilities/advancedrename/common/parsesettings.h
M  +1-3core/utilities/advancedrename/parser/importrenameparser.cpp
M  +4-1   
core/utilities/advancedrename/parser/options/filepropertiesoption.cpp
M  +129  -201  core/utilities/import/backend/cameracontroller.cpp
M  +1-18   core/utilities/import/backend/cameracontroller.h
M  +1-1core/utilities/import/backend/camiteminfo.h
M  +1-1core/utilities/import/items/importdelegate.cpp
M  +339  -267  core/utilities/import/main/importui.cpp
M  +9-10   core/utilities/import/main/importui.h
M  +7-1core/utilities/import/main/importui_p.h
M  +8-28   core/utilities/import/widgets/renamecustomizer.cpp
M  +2-1core/utilities/import/widgets/renamecustomizer.h

https://invent.kde.org/graphics/digikam/commit/eeb5ba940b0b7e523200e791b9f98623ab75b65b

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 455091] Renaming files on import loses image order in some cases

2022-06-11 Thread Maik Qualmann
https://bugs.kde.org/show_bug.cgi?id=455091

Maik Qualmann  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #13 from Maik Qualmann  ---
The {unique} modifier only considers the set of files just imported, not
whether any already exist in the album. During the download, the option in the
digiKam camera settings would take effect here, whether duplicate files should
be overwritten, skipped or renamed with a _vxx extension.

I already wrote that renaming just by date is a very bad idea.
Why don't you rename the files after importing them? Then all database renaming
functions are available. The digiKam view can sort by date, then rename all
files with date and a running counter (###).

Detecting whether files have already been imported is a complicated story. We
can't use a fingerprint at the moment because the file isn't available to us
locally when importing from the GPhoto2 driver. The detection is currently a
mix of device ID + file name + file size and date.

Yes, the import tool needs some major improvements that are on my todo list. We
already have a bug report on the problem of recognizing files that have already
been downloaded, I'll close it here.

Maik

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 455091] Renaming files on import loses image order in some cases

2022-06-11 Thread bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=455091

--- Comment #12 from myaccount...@protonmail.com ---
Latest test didn't offer to import duplicates and did mark all correctly
imported. 

I did two changes which could have caused this: 

i) replaced renaming from [date] to [date]{import}
ii) started using metadata to directly get correct hours for photos (videos
handle +2 as +4 and reduces too many hours). 

However problem doesn't seem to occur every time.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 455091] Renaming files on import loses image order in some cases

2022-06-11 Thread bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=455091

myaccount...@protonmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |---

--- Comment #11 from myaccount...@protonmail.com ---
Still one more question. Are you sure this {uniques} actually works on import,
because since switching to it, I'm constantly having images donwloaded second
time afterwards? They seem not to be marked as already downloaded by digikam,
which I constantly have to do manually. There must be reason why I originally
dropped it out from import phase, and chose to do more reliable second rename
afterwards, and it could be this behavior (can't remember anymore).

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 455091] Renaming files on import loses image order in some cases

2022-06-10 Thread Maik Qualmann
https://bugs.kde.org/show_bug.cgi?id=455091

--- Comment #10 from Maik Qualmann  ---
I've played around with the options that QCollator offers, but we can't change
the behavior. It depends on whether QCollator uses the libicu or not. The
libicu is not used on Windows.

Maik

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 455091] Renaming files on import loses image order in some cases

2022-06-09 Thread bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=455091

--- Comment #9 from myaccount...@protonmail.com ---
Ok. 

Also what possibly was earlier left unnoticed, the way files are arranged in
import view (ascending/descending) shouldn't be involved in any way in which
order unique filenames are formed. Renaming should follow only original
filenames (in ascending order) - or possibly metadata if used - which possibly
means that actual import should always be done in that order regardless of what
the view says (I haven't looked at the actual code, this is just how it
appears).

But this is possibly not biggest problem for me in practice, just a
complication possibly deeper in systems which I think shouldn't exist.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 455091] Renaming files on import loses image order in some cases

2022-06-09 Thread Maik Qualmann
https://bugs.kde.org/show_bug.cgi?id=455091

--- Comment #8 from Maik Qualmann  ---
We can't technically implement it either, we would have to check each item with
a regular expression, which would greatly slow down the sorting. By the way,
the sorting in this case also depends on the platform, on Windows the order is
as requested by you. So you would have to contact Qt. I'm still checking
whether we can possibly introduce another option besides the character string
comparison Options "Normal", "Natural" to disable/enable the consideration of
punctual notation.

Maik

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 455091] Renaming files on import loses image order in some cases

2022-06-09 Thread Maik Qualmann
https://bugs.kde.org/show_bug.cgi?id=455091

Maik Qualmann  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #7 from Maik Qualmann  ---
Definitely no, it would break the natural numerical file order for other users.
It would be inconsistent with file managers and we would have the next bug
report. Accept it.

Maik

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 455091] Renaming files on import loses image order in some cases

2022-06-09 Thread bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=455091

myaccount...@protonmail.com changed:

   What|Removed |Added

 Resolution|WORKSFORME  |---
 Status|RESOLVED|REOPENED

--- Comment #6 from myaccount...@protonmail.com ---
Adding v manually seems to change the order. Could the {unique} identifier then
result to 

_v1
_v2
_v3

instead of current

_1
_2
_3

? 

This would make things work as expected. There's no easy way to add another
unique identifier (such as adding original filename after date) because
different cameras seems to give different results to hours (possibly because of
inconsistensies in time zones??) and I normally do double renaming (which
complicate that): first from camera without using metadata, then separate
renames for photos and videos which work differently. I actually have to rename
(fine tune hours for) videos manually since I don't get correct hours by any
method.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 455091] Renaming files on import loses image order in some cases

2022-06-09 Thread Maik Qualmann
https://bugs.kde.org/show_bug.cgi?id=455091

Maik Qualmann  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|REOPENED|RESOLVED

--- Comment #5 from Maik Qualmann  ---
The sort order is correct, it corresponds to the "natural" string sorting. If
you look in the Dolphin file manager, it sorts the files exactly the same way.
We make an exception in versioning if the counter still contains the "v", as
123456_v01.
We won't change it, you'll have to come up with another renaming string to make
it more unique.

Maik

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 455091] Renaming files on import loses image order in some cases

2022-06-09 Thread bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=455091

--- Comment #4 from myaccount...@protonmail.com ---
It actually seems to work with [date]{unique} IF I also sort items in growing
order in import view, when selecting newst first they were renamed backwards
when testing... Latter shouldn't be any criteria.

There's still one wish, digikam album view should view files in correct order.
Now they seem to be:

123456_01.jpg
123456_02.jpg
123456_03.jpg
123456_04.jpg
123456.jpg

when correct is:

123456.jpg
123456_01.jpg
123456_02.jpg
123456_03.jpg
123456_04.jpg

but this is actually not rename bug.

So {unique} actually seems to help in random order which plain [date] gives,
but the view order affects the way it shouldn't. Also album sorting needs minor
fix.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 455091] Renaming files on import loses image order in some cases

2022-06-09 Thread bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=455091

myaccount...@protonmail.com changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #3 from myaccount...@protonmail.com ---
No, it doesn't help {unique} behaves similarly.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 455091] Renaming files on import loses image order in some cases

2022-06-09 Thread Maik Qualmann
https://bugs.kde.org/show_bug.cgi?id=455091

Maik Qualmann  changed:

   What|Removed |Added

 CC||metzping...@gmail.com
   Version Fixed In||7.7.0
 Resolution|--- |FIXED
 Status|REPORTED|RESOLVED

--- Comment #2 from Maik Qualmann  ---
Add the "{unique}" modifier to the [date] option. There can be no other
solution if date and time are identical. The "{unique}" modifier only respects
the file extension correctly in digiKam-7.6.0.

Maik

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 455091] Renaming files on import loses image order in some cases

2022-06-09 Thread bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=455091

--- Comment #1 from myaccount...@protonmail.com ---
Correction: this may actually occur when later similarly using rename option
for bunch of files, or in both cases.

-- 
You are receiving this mail because:
You are watching all bug changes.