[digikam] [Bug 314441] New: Rename settings during import ignored

[Andi Clemens]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #55 from Andi Clemens <[hidden email]> ---
(In reply to comment #50)
> Is generating the name always fast or are there cases where loading of data
> is necessary?

Yes, it is rather fast. When I rename 800 images (change the rename settings)
in the albumUI, the new filenames are generated in approx 1 second, even when
reading metadata or file properties.
There is also the possibility to add more cache maps in the RenameManager
during initialization, to read the most important file properties and metadata
information (or even create new cache maps dynamically when the rename settings
are changed).
But right now I think it is fast enough.

I'll take a look at implementing a preview widget in the rename settings, to.
Maybe a label is sufficient that displays the new name of the first (selected)
image?

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Andi Clemens]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #56 from Andi Clemens <[hidden email]> ---
Git commit 78c5968a304f10bdbee5e329a915a93136c03daa by Andi Clemens.
Committed on 30/06/2013 at 08:53.
Pushed by aclemens into branch 'master'.

Display the download file in the icon view for the selected items, like we did
in digiKam 2.x.
I still think this is not the best solution, but it seems to work right now.

There is a refresh problem with the view, that has always been there and is not
introduced by this patch.
If you change rename settings or if you download images, the icon view is only
refreshed when you move the mouse out of the view and in again.
I tried fixing this issue, but failed.
Maybe someone who knows this code can take a look at the issue?

Andi

M  +1    -1    utilities/importui/items/importdelegate.cpp
M  +120  -101  utilities/importui/main/importui.cpp
M  +7    -1    utilities/importui/widgets/renamecustomizer.cpp
M  +1    -0    utilities/importui/widgets/renamecustomizer.h

http://commits.kde.org/digikam/78c5968a304f10bdbee5e329a915a93136c03daa

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Anders Lund]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #57 from Anders Lund <[hidden email]> ---
In 3.2.0, this is still present. Any hope for 3.3?

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #58 from Gilles Caulier <[hidden email]> ---
Yes, some stuff have already fixed by Andi for 3.3.0

I will take holiday 3 weeks in July. I will take time to hack download flag
feature for 3.3.0.

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Thomas Bettler-2]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #59 from Thomas Bettler <[hidden email]> ---
Hi Andi, hi Gilles

Many thanks for all your efforts in fixing the involved bugs.

I observed an unexpected behaviour probably in the same context of this.
If you delete any selected pictures in the download dialog, the pictures being
deleted are the ones selected. However the pictures being displayed after the
operation aren't the ones effectively remaining on the device.

May the major bugs be fixed in 3.3.0

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[CABPSOFT - Camilo Bohórquez]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #60 from CABPSOFT - Camilo Bohórquez <[hidden email]> ---
The bug still in the last patch for openSUSE 12.3 x86_64 (3.2.0-1.83.3 - At the
image download, renaming settings is ignored).

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Sylvain ZUCCA]

https://bugs.kde.org/show_bug.cgi?id=314441

sylvainsjc <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #61 from sylvainsjc <[hidden email]> ---
Hello,

I notice also this incorrect behavior on LinuxMint 15 (Digikam 3.1) and ROSA
Desktop Fresh (Digikam 3.2) with PTP mode on NIKON D5100

When I tell Digikam to download / delete images from the camera, all is well
downloaded but only the first image is deleted, the others stay and Digikam
seems to wait something to finish the operation

Using debug mode with gdb, I can see this :
"No location could be retrieved for url KUrl("") "

Is it a consequence of the above bug or should I declare a new one ?

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Sylvain ZUCCA]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #62 from sylvainsjc <[hidden email]> ---
Further details, if I ask Digikam to delete only, it works

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #63 from Gilles Caulier <[hidden email]> ---
To comment #61 : It's another bug that i can confirm. Please, check first if a
file about it doesn't exist yet in bugzilla. If not, open a new one.

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Stefano Ferri]

https://bugs.kde.org/show_bug.cgi?id=314441

Stefano Ferri <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #64 from Stefano Ferri <[hidden email]> ---
This bug is still present in 3.3. It is partially solved, in the sense that now
the basename is  changed (i.e., DSC_2546.JPG can be changed to
my_name_007.JPG), but, sadly, other rename options are ignored or applied in a
bad way.
For example, let's say we want to rename some photos to bird_001.JPG: one need
to enter bird_### in the rename mask. Well, digiKam accepts the basename, the
fact that there should be 3 digits, but chooses the number by itself. In the
above example, numbering should start from 1, while digiKam insists to start
numbering from a number that seems to be the position in the import view. More
precisely, if the image is the 8th in the view, numbering starts (as far as I
have tried) from 9 or so.
Also bird_###[10] is ignored: the number between square brackets doesn't mean
nothing to digiKam.

Other options (like [cam], etc) don't work.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=314441

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|3.2.0                       |3.3.0

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Stefano Ferri]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #65 from Stefano Ferri <[hidden email]> ---
I've found a workaround for the problem mentioned in my previous comment. I
don't like it too much, but it works.
If the name is set to something like my_name_###[f] (so "folder aware
numbering" is active) digiKam correctly starts from 1 for numbering renamed
items. Also my_name_###[f,start,step] works.

Options tested as non-working: [cam], [dir]
Working: [file], [date] (I've tested these ones)

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Stefano Ferri]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #66 from Stefano Ferri <[hidden email]> ---
I don't know if this is the correct place, but there are two other minor
problems with advance rename. They regards the field used for writing new
names.

#1: the button on the right for deleting field content doesn't work
#2: the field is too small and does not display the bottom part of some
characters, for example "p". Underscores are not visible at all.

If needed I will file a new bug for this.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[CABPSOFT - Camilo Bohórquez]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #67 from CABPSOFT - Camilo Bohórquez <[hidden email]> ---
In the new digikam versión 3.5.0, the renaming settings during import, has been
SOLVED !!!

I auto rename my pictures, with exif date-time in format
[date:"yyyy-MM-dd_hh-mm-ss"], and it works !!!.

:)

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Teemu Rytilahti]

https://bugs.kde.org/show_bug.cgi?id=314441

Teemu Rytilahti <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #68 from Teemu Rytilahti <[hidden email]> ---

> If needed I will file a new bug for this.

Please do if there is no similar entries available. Both could go to the same
bug report, as they seem to be related.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Peter Albrecht-2]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #69 from Peter Albrecht <[hidden email]> ---
Bug checked against digikam 3.5.0 (KDE 4.10.5, gentoo linux):
I can confirm Stefano Ferri's  comment #64
> This bug is still present in 3.3. It is partially solved, in the sense that
> now the basename is  changed (i.e., DSC_2546.JPG can be changed to
> my_name_007.JPG), but, sadly, other rename options are ignored or applied in
> a bad way...

And comment #65
> ... Options tested as non-working: [cam], [dir]
> Working: [file], [date] (I've tested these ones)

For import from SD card, my default setting is:
"[cam]{range:13,15}-[file]{lower}.[ext]{lower}"
expected result: "EOS-img_2108.jpg"
actual result: "-img_2108.jpg"

So "[file]", "[ext]" and "{lower}" work. But "[cam]{range...}" only brings up
an empty string.
Also "[meta:Exif.Image.Model]", "[meta:Exif.Canon.ImageType]",
"[dir]" and a sole "[cam]" (without "range"-modifier) only give an empty
string.
These are the points I tested. This matches with Stefano Ferri's test results.

Also "Auto-rotate/flip image" does not work. Portraits are not automatically
rotated, but remain in landscape orientation.

In the console debug output one can find a lot of
  "Cannot load metadata from file   (Error # 9 :  IMG_1995.JPG: Failed to open
the data source:  (errno = 2)"
The reason might be: "IMG_1995.JPG" was the original image name on SD card,
but while importing the picture is renamed to "-img_1995.jpg" (see above).
So the error message is correct. But the question is, why does digikam look for
files with the old name?

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Peter Albrecht-2]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #70 from Peter Albrecht <[hidden email]> ---
As for the "Failed to open the data source" errors from comment #69:
If I disable image renaming during import, those error messages don't show up.
But rotation according to EXIF-Flag also does not work.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=314441

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|3.3.0                       |3.5.0

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Andreas Mair]

https://bugs.kde.org/show_bug.cgi?id=314441

Andreas Mair <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #71 from Andreas Mair <[hidden email]> ---
(In reply to comment #67)
> In the new digikam versión 3.5.0, the renaming settings during import, has
> been SOLVED !!!
>
> I auto rename my pictures, with exif date-time in format
> [date:"yyyy-MM-dd_hh-mm-ss"], and it works !!!.
>
> :)

Are you sure that [date:"yyyy-MM-dd_hh-mm-ss"] uses *exif date-time*?
After reading the documentation I'd say it uses the image file's timestamp.
[meta:Exif.Photo.DateTimeOriginal] uses EXIF date-time but it can't be formated
like this: [meta:Exif.Photo.DateTimeOriginal:"yyyy-MM-dd_HH-mm-ss"].

I don't know if that's a bug or simply not supported.

Best regards,
Andreas

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=314441

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]
                   |                            |t

--- Comment #72 from Gilles Caulier <[hidden email]> ---
*** Bug 322539 has been marked as a duplicate of this bug. ***

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel