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
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