Created attachment 61544 [details] Thumbnail view with the incorrect file size. Version: 2.0.0 (using KDE 4.6.4) OS: Linux When showing the thumbnails of big files (.MOV files from a EOS 60D) the file size shown for the files >2Gib is not correct, and shows as 16EiB. Reproducible: Always Steps to Reproduce: Import files bigger than 2Gib into Digikam, and open the thumbnail view with the thumbnails showing the file size. Actual Results: Files greater than 2Gib incorrectly report the file size as 16Eib. Expected Results: The thumbnail should show the correct file size. This is an ls -ls with the size of the original files: -rw-r--r-- 1 joseluis joseluis 2845517348 2011-06-07 12:28 MVI_1379.MOV -rw-r--r-- 1 joseluis joseluis 1527880952 2011-06-07 12:37 MVI_1380.MOV -rw-r--r-- 1 joseluis joseluis 2648664444 2011-06-07 12:54 MVI_1381.MOV Attached is a capture of the thumbnails. This bug was showing in Digikam 1.9.0 and after updating to 2.0.0~rc1-natty~ppa1 from Phillip's PPA, it is still happening.
Dolphin give the right value if you try with it ? Gilles Caulier
Created attachment 61547 [details] Dolphin showing the correct file size I don't usually use Dolphin but Konqueror, but I understand that they use the same libraries. Anyway, I opened Dolphin and the correct file size is shown in the right panel and in the Properties window.
Quite simple: The filesize is stored in an integer, at some places even a signed integer. It is straightforward to change fields to qlonglong on the C++ side. Question is if the database is ready to store a longer value. With SQlite, the field is declared as INTEGER but that apparently also allows 64bit values. Francesco, what about MySQL?
(In reply to comment #3) > Quite simple: The filesize is stored in an integer, at some places even a > signed integer. > > It is straightforward to change fields to qlonglong on the C++ side. Question > is if the database is ready to store a longer value. With SQlite, the field is > declared as INTEGER but that apparently also allows 64bit values. sqlite is ok: INSERT INTO "Tags" VALUES(9223372036854775807,9223372036854775807,'PIPPO',0,NULL); SELECT * FROM Tags WHERE id = 9223372036854775807; delete from Tags where id = 9223372036854775807; > > Francesco, what about MySQL? nope mysql has different types for 32 and 64 bit integer (and has a few more for smaller ones), one of the things I want to do with next revision of the database is to change many fields from type INT to BIGINT, if needed I can do it for 2.0 but cannot suggest it. mysql> INSERT INTO Tags VALUES(9223372036854775807,9223372036854775807,'PIPPO',0,NULL,0,0); Query OK, 1 row affected, 2 warnings (0.02 sec) mysql> show warnings -> ; +---------+------+----------------------------------------------+ | Level | Code | Message | +---------+------+----------------------------------------------+ | Warning | 1264 | Out of range value for column 'id' at row 1 | | Warning | 1264 | Out of range value for column 'pid' at row 1 | +---------+------+----------------------------------------------+ 2 rows in set (0.01 sec) what does digikam use the size for? If it's only a display thing we can fix it in c++ for sqlite users and correct mysql database for 2.1
> what does digikam use the size for? If it's only a display thing we can fix it > in c++ for sqlite users and correct mysql database for 2.1 Sounds good. It's used for display, identifying files and thumbnails in combination with a hash, and triggering a rescan. But files >2GB are still a corner case in the year 2011, so it's not that urgent.
Git commit 77cb33ee334b6e6767f2bd734eddbd9dba65df6d by Marcel Wiesweg. Committed on 09/08/2011 at 21:44. Pushed by mwiesweg into branch 'master'. Use qlonglong for file size in C++ This does not yet fix the bug: The binary protocol of the ioslaves will have to be changed. I have avoided this so far, but plan to do it. As well, this change needs to be evaluated for MySQL as discussed by Francesco. CCBUG: 276920 M +2 -2 libs/database/downloadhistory.cpp M +3 -3 libs/dimg/imagehistory/historyimageid.h M +1 -1 libs/database/imageinfodata.h M +1 -1 libs/database/imageinfo.h M +1 -1 libs/database/databasethumbnailinfoprovider.cpp M +3 -3 libs/database/thumbnaildb.h M +6 -6 libs/database/imagelister.cpp M +3 -3 libs/database/thumbnaildb.cpp M +1 -1 libs/threadimageio/thumbnailcreator.h M +1 -1 libs/database/imageinfo.cpp M +5 -5 libs/database/albumdb.h M +2 -2 libs/database/downloadhistory.h M +1 -0 libs/database/imagelisterrecord.h M +2 -2 libs/dimg/imagehistory/historyimageid.cpp M +2 -2 libs/database/collectionscanner.cpp M +2 -3 libs/database/imagescanner.cpp M +1 -1 libs/database/albuminfo.h M +9 -9 libs/database/albumdb.cpp http://commits.kde.org/digikam/77cb33ee334b6e6767f2bd734eddbd9dba65df6d
Git commit af06c4b16c443bda20f6aa423dd474a1e6a869f8 by Marcel Wiesweg. Committed on 20/08/2011 at 15:43. Pushed by mwiesweg into branch 'master'. Make file sizes >2GB work with SQlite without changing ioslave protocol To avoid changing the protocol, any 31bit-value will be passed from the ioslave, any larger value will be reread from the main application. For large file size support in MySQL, a schema change is needed. CCBUG: 276920 M +3 -2 libs/database/imageinfo.cpp M +22 -6 libs/database/imagelister.cpp M +0 -1 libs/database/imagelisterrecord.h http://commits.kde.org/digikam/af06c4b16c443bda20f6aa423dd474a1e6a869f8
Jose, There are a lots of commits from Marcel to fix this issue. Problem still here using digiKam 2.4 ? Gilles Caulier
Created attachment 66776 [details] Digikam 2.4.1 showing the bug Sorry, I've just installed 2.4.1 from phillip5 PPA's (I was still at 2.3.0) and the problem is still happening :S
The size of file information are already registered in database. You need to refresh these information. Just to test, create a new account on your system, run digiKam and import files. Look is size are parsed and stored properly in database. Gilles Caulier
Created attachment 67865 [details] Digikam 2.5 showing the bug Awfully sorry for the delay, I've been abroad for christmas and couldn't try. Unfortunately, bug is still happening with 2.5 from phillip's PPA. - Created new user with default kde config - Open digikam with default options (Next > Next > Next > Finish), so SQLite DB, I suppose. - Open konqueror and drag the videos into Digikam (thus copying into the new user's collection). - Select album, with same result. Screenshot attached. Digikam version: # apt-cache policy digikam digikam: Installed: 2:2.5.0-oneiric~ppa1 Candidate: 2:2.5.0-oneiric~ppa1 Version table: *** 2:2.5.0-oneiric~ppa1 0 500 http://ppa.launchpad.net/philip5/extra/ubuntu/ oneiric/main amd64 Packages 100 /var/lib/dpkg/status 2:2.1.1-0ubuntu1 0 500 http://gb.archive.ubuntu.com/ubuntu/ oneiric/universe amd64 Packages
Git commit 5d12fd5c98073038bd09bafeb3c837d1ddcb12d7 by Marcel Wiesweg. Committed on 03/06/2012 at 19:01. Pushed by mwiesweg into branch 'master'. One "int" was left where a qlonglong is needed M +1 -0 NEWS M +1 -1 libs/widgets/itemview/itemviewimagedelegate.cpp M +1 -1 libs/widgets/itemview/itemviewimagedelegate.h http://commits.kde.org/digikam/5d12fd5c98073038bd09bafeb3c837d1ddcb12d7