Version: 1.8.0 (using KDE 4.5.4) OS: Linux For every single .AVI file in the selection the rename dialog says «cannot rename» or «file does not exist» (even though it did rename the file). The progress dialog then does not continue until it is aborted and restarted. Reproducible: Always OS: Linux (x86_64) release 2.6.36-2.slh.3-aptosid-amd64 Compiler: cc
Created attachment 57182 [details] Crash when renaming, maybe related? This is becoming a little annoying. Renaming JPEG files works fine, but AVI files nearly always fail.
No, it's completly different. Probably the thumbnails thread issue: Thread 2 (Thread 0x7f6478b27710 (LWP 9061)): [KCrash Handler] #5 0x00007f64cbd39854 in Digikam::ThumbnailLoadingTask::execute (this=0x7f64706b8190) at /data/cworkspace/digikam-trunk/digikam/libs/threadimageio/thumbnailtask.cpp:100 #6 0x00007f64cbd18c0d in Digikam::LoadSaveThread::run (this=0x2b41800) at /data/cworkspace/digikam-trunk/digikam/libs/threadimageio/loadsavethread.cpp:124 #7 0x00007f64cbd6095c in Digikam::DynamicThread::DynamicThreadPriv::run (this=0x2b59e50) at /data/cworkspace/digikam-trunk/digikam/libs/threads/dynamicthread.cpp:306 #8 0x00007f64c7ddbd5f in ?? () from /usr/lib/libQtCore.so.4 #9 0x00007f64c7de5e15 in ?? () from /usr/lib/libQtCore.so.4 #10 0x00007f64c525a8ba in start_thread (arg=<value optimized out>) at pthread_create.c:300 #11 0x00007f64c70a502d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #12 0x0000000000000000 in ?? () Gilles Caulier
Could I, in theory, debug this with qtcreator? I could try, as soon as I know where libkexiv2 and Co. have gone and how to compile/install everything with the new git repo.
The best thing would be to ignore media types that are not images in the progress bar dialog. The problem with crashing could arise in other places, too. Gilles, what do you think? Should we just skip displaying a thumbnail for video, audio and other types when showing the graphical progress bar dialog? Andi
Must confirm this behaiviour with AVI files - additionally renaming multiple files when including any AVI results in flickering thumbnails for the respective album; this occurs after renaming the automatically marked rest of the files which remained unrenamed after the error. Reproducible: Always Digikam Version: 2.2 on ubuntu 11.04 64bit
Additional information to my previous comment: Obviously related to thumbnail creation, here the output from cmd line: digikam(22884)/digikam (core) Digikam::ThumbnailCreator::createThumbnail: Cannot create thumbnail for "/path/to/file/FILENAME.AVI" digikam(22884)/digikam (core) Digikam::ThumbnailCreator::load: Thumbnail is null for "/path/to/file/FILENAME.AVI" seems to be related to bug 261773
This is still valid in 2.6.0.
And with 2.7.0 ?
Still happening in Version 3.0.0-rc (on KDE 4.10, OpenSuse)
What's happen with 3.0.0 final release ? (not RC) Gilles Caulier
Will check as soon as package is provided. This will happen with OpenSuse 12.3., due in about 2 weeks. But is there hope? Has anything been done to address this bug between RC and final?
Yes, it still happens with 3.0.0 final. digiKam Version 3.0.0 Using KDE Development Platform 4.10.00 "release 1"
Still happens with 3.2. digiKam Version 3.2.0 Using KDE Development Platform 4.10.3 "release 1"
To Andi, comment #4, See my comment here about progressmanager : https://bugs.kde.org/show_bug.cgi?id=261773#c10 Gilles Caulier
Michael, This file still valid using last digiKam 4.2.0 and last Exiv2 shared lib 0.24 (this last one is able to manage video metadata) ? Gilles Caulier
Michael, Did you seen my previous comment ? Can you check with last digiKam 4.10.0 ? Gilles Caulier
Gilles, sorry for missing this, I don't always realize if KDE mails are for me or cc'ed to me. Don't have 4.1 yet, but I can properly rename .avi files with digikam 3.5 on KDE 4.14.6. I did not realize the manual renaming works now because renaming on import now works properly as well, minimizing the need for manual renaming. In any case: Thank you for your efforts in solving this! Michael
Indeed, it works fine with 3.5, thanks a lot for fixing this bug!
I am using 4.4.0 now, and it seems like there is a regression. It shows exactly the same behaviour again.
4.4.0 is not the last one, but 4.14.0, which is a big difference. Gilles Caulier
Fixed with next 6.0.0 release which integrate a new video metadata parser based on FFMPEg instead Exiv2. Video date extraction work as expected and video file rename is completed properly.