Bug 363510 - Wrong filename shown in album view
Summary: Wrong filename shown in album view
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Unclassified
Component: Thumbs-Image (show other bugs)
Version: 4.14.0
Platform: Debian stable Linux
: NOR major (vote)
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-25 15:16 UTC by Torsten Crass
Modified: 2016-06-02 03:58 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.0.0


Attachments
Image shown with correct filename... (181.37 KB, image/jpeg)
2016-05-25 15:16 UTC, Torsten Crass
Details
...and image shown with incorrect filename (i.e. the same filename as attachment #1) (171.94 KB, image/jpeg)
2016-05-25 15:17 UTC, Torsten Crass
Details
Screenshot of digikam showing identical filenames for different images (243.10 KB, image/png)
2016-05-25 15:20 UTC, Torsten Crass
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Torsten Crass 2016-05-25 15:16:25 UTC
Created attachment 99179 [details]
Image shown with correct filename...

Hi there,

for some images, identical filenames are shown in the album view when present in the same album. In other views (e.g. the image editor or the light table) the correct filenames are shown. This is kinda annoying since it prevents users from correctly picking individual images for further processing.

When checking directly in the (sqlite) database, the images' file names are stored correctly; also, the images do have different fingerprints. So I really wonder how the album view can mess up the display this way...

Example images will be attached to this bug report.

Regards --

-- Torsten
Comment 1 Torsten Crass 2016-05-25 15:17:32 UTC
Created attachment 99180 [details]
...and image shown with incorrect filename (i.e. the same filename as attachment #1 [details])
Comment 2 Torsten Crass 2016-05-25 15:20:56 UTC
Created attachment 99181 [details]
Screenshot of digikam showing identical filenames for different images
Comment 3 caulier.gilles 2016-05-25 15:24:52 UTC
Please run ls -al in the directory tmp where images are hosted...

Gilles Caulier
Comment 4 Torsten Crass 2016-05-26 07:08:32 UTC
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
Comment 5 caulier.gilles 2016-05-26 07:53:42 UTC
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
Comment 6 Torsten Crass 2016-05-26 14:54:02 UTC
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
Comment 7 caulier.gilles 2016-05-26 14:56:45 UTC
How did you process file renaming ? Through rename tool in digiKam or externally (as with dolphin or CLI) ?

Gilles Caulier
Comment 8 Torsten Crass 2016-05-26 16:30:33 UTC
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
Comment 9 Torsten Crass 2016-05-26 16:31:17 UTC
> 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.
Comment 10 Torsten Crass 2016-05-27 15:16:18 UTC
Gilles,

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

Cheers --

	Torsten
Comment 11 Maik Qualmann 2016-05-27 21:39:07 UTC
The problem is not to reproduce here. Both images are displayed with correct file name in the album.

Maik
Comment 12 caulier.gilles 2016-05-27 21:47:12 UTC
Same here, using current implementation from git/master (digiKam 5.0.0-beta6)

Gilles Caulier
Comment 13 Torsten Crass 2016-05-28 07:07:43 UTC
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
Comment 14 caulier.gilles 2016-05-28 07:10:39 UTC
Enable debug statements on the console as explained here :

https://www.digikam.org/contrib

Look section "For hangs out or dysfunctions"

Gilles Caulier
Comment 15 Torsten Crass 2016-05-29 18:33:49 UTC
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
Comment 16 Torsten Crass 2016-06-01 19:21:12 UTC
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
Comment 17 caulier.gilles 2016-06-02 03:58:14 UTC
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