Bug 363510

Created attachment 99180 [details]
...and image shown with incorrect filename (i.e. the same filename as attachment #1 [details])

Created attachment 99181 [details]
Screenshot of digikam showing identical filenames for different images

Please run ls -al in the directory tmp where images are hosted...

Gilles Caulier

HI Gilles,

no secrets hidden here:

[code]
drwxr-xr-x  2 tcrass tcrass   4096 May 25 17:03 .
drwxr-xr-x 11 tcrass tcrass  16384 May 25 17:01 ..
-rw-r--r--  1 tcrass tcrass 185726 May 25 16:43 01-lce-100x0.4.jpg
-rw-r--r--  1 tcrass tcrass 176065 May 25 16:43 01-lce-200x0.2.jpg 
[/code]

Cheers --

-- Torsten

I think the problem is with the double dot in file name :

01-lce-100x0.4.jpg
01-lce-200x0.2.jpg 

Can you test to rename file like this :

01-lce-100x0dot4.jpg
01-lce-200x0dot2.jpg 

Gilles Caulier

Gilles,

> I think the problem is with the double dot in file name :
>
> 01-lce-100x0.4.jpg
> 01-lce-200x0.2.jpg
>
> Can you test to rename file like this :
>
> 01-lce-100x0dot4.jpg
> 01-lce-200x0dot2.jpg

yeah, renaming does sometimes help (I've tried that already) -- for 
instance if I rename the files as you suggest.

Another successful example: When renaming the files like

01-lce-100x0.4.jpg
01-lce-200x0.2a.jpg

the correct names are shown. But when I subsequently rename the first 
file so that I end up with

01-lce-100x0.4a.jpg
01-lce-200x0.2a.jpg

both files are shown as "01-lce-200x0.2a.jpg" in digikam.

And now it gets really strange: when renaming like

01-lce-100x0.4a.jpg
01-lce-200x0.2.jpg

the first file gets shown in digikam as "01-lce-200x0.2a.jpg" and the 
second file as "01-lce-100x0.4.jpg"!

Any further ideas...?

	Torsten

How did you process file renaming ? Through rename tool in digiKam or externally (as with dolphin or CLI) ?

Gilles Caulier

Gilles,

> How did you process file renaming ? Through rename tool in digiKam or
> externally (as with dolphin or CLI) ?

tried both methods, didn't make any difference.

Cheers --

	Torsten

> How did you process file renaming ? Through rename tool in digiKam or
> externally (as with dolphin or CLI) ?

P.S: With "both" I meant both from within digikam and using external tools.

Gilles,

can you actually reproduce the problem, or is it restricted to my 
personal (Debian Jessie) system (with digikam from backports)?

Cheers --

	Torsten

The problem is not to reproduce here. Both images are displayed with correct file name in the album.

Maik

Same here, using current implementation from git/master (digiKam 5.0.0-beta6)

Gilles Caulier

Hi,

> Same here, using current implementation from git/master (digiKam 5.0.0-beta6)

weird... although, on Debian, I'm stuck with 4.4(.14), of course.

Any suggestions on how to get debug output from digikam in order to 
track down the issue?

Cheers --

-- Torsten

Enable debug statements on the console as explained here :

https://www.digikam.org/contrib

Look section "For hangs out or dysfunctions"

Gilles Caulier

Hi,

> --- Comment #14 from caulier.gilles@gmail.com ---
> Enable debug statements on the console as explained here :
>
> https://www.digikam.org/contrib
>
> Look section "For hangs out or dysfunctions"

debugging output had already been enabled. Can't see anything suspicious 
there, though. For instance, when moving the two sample images from one 
album to another using the digikam GUI, sensible filenames are mentioned 
in the debugging output.

I now downloaded the Debian source code for 4.4.14. Could you please 
give me a hint which file contains the code finally outputting the 
filename in the albums' thumbnail views? That might be a good starting 
point for digging through the source in order to find the place where 
things start going wrong.

Thanks --

	Torsten

OK,

I found out what's going on!

After installing tons of dependencies, I compiled and debugged the 
digikam 4.4.14 source (from 
http://download.kde.org/stable/digikam/digikam-4.14.0.tar.bz2) from 
within kdevelop. The problem resides in the function

QString DItemDelegate::squeezedTextCached(QPainter* const p, int width, 
const QString& text) const

at line 184 in .../core/libs/widgets/itemviewditemdelegate.cpp. It seems 
that my problematic filenames prove that unlikely events like cache 
collisions are prone to occur sooner or later, regardless how unlikely 
they may seem. (Think Fukushima... ;)

When commenting out lines 191-194, which return a cached version of the 
squeezed filename, if existant, the correct filename gets displayed in 
the album view, freshly generated by applying the squeezedText function 
to the filename.

I suppose very little can be done about this. On the other hand, if you 
digikam developer folks can't reproduce my problem in 5.0, something 
must have changed in the sourc, preventing that cache collision from 
happening any longer. So I guess I'll for now stick with my modified 
digikam version with the uncommented caching code and just wait for 5.0 
to eventually show up in Debian.

Anyway, thanks for your great work on this great application!

Cheers --

	Torsten

Torsten,

Thanks for your investigations.

The code in unchanged in this function with 5.0.0. The main difference is to use Qt5 instead Qt4 to play with QHash  API to cache strings of squeezed filename.

I close this file as resolved with 5.0.0. Don't hesitate to re-ope if necessary.

Gilles Caulier