Version: (using KDE 4.0.3) Installed from: Gentoo Packages OS: Linux When I enter a folder with gzip-ed pdf files, dolphin seems to unpack them all. Folder with 5 or more .pdf.gz files causes dolphin to hang and only way to unhang it is to wait until it finishes (really long time for me) and close it (hovering mouse over any of this files will make dolphin go over all of this again) or kill it.
Does the problem occur immediately when entering the directory or only if you hover over the files with the mouse? Do you have Preview enabled or disabled, or is the problem independent of this? What happens if you close the Information panel? Does the problem persist? Finally, does the problem only occur with gzipped PDFs or e.g. with the same PDFs unzipped? Thanks for trying out and detailing.
If we are talking about the same bug, I found the problem: It's the constructor of KFileMetaInfo which is called in line 394 of infosidebarpage.cpp that takes a lot of time to crawl for its data (if someone needs a test case file, I can send it to you). It would be good to encapsulate this search and others (like the preview) in a separate thread, anyway. I am new to KDE, can someone tell me what is the KDE way of doing this?
@Pascal: thanks for having a look on the root cause. Regarding KFileMetaInfo: this class may not block for a long time when KFileMetaInfo::Fastest is used. If this is the case (like it seems for .pdf.gz) there is an issue in the corresponding strigi classes that are used by KFileMetaInfo (strigi is also used internally if "strigi searching" is turned off in the system settings). In KDE 4.2 all blocking tasks are done asynchronously in the information sidebar: - generating of the preview (this is also done asynchronously since 4.0) - getting the nepomuk meta data like rating + tags (since 4.2) Judging from other bug reports we got this seems to be a strigi issue. I hope I've time to check this before 4.2...
Created attachment 28681 [details] reads meta info asynchronously, does NOT solve bug With this patch the meta information is read asynchronously, but strangely enough, dolphin still hangs when previewing some files. Aren't the jobs executed in a separate thread, or is there a bug deep down?
Thanks Pascal for the patch. I did not have the time yet to try your patch, but I'm wondering that it still blocks - everything looks fine... I had a short look at the sources of MetaInfoJob, but everything looks OK there (no blocking stuff in the ctor etc.). I've added David Faure to CC, maybe he can see something obvious. I'll take a look on this issue, as I can reproduce it when hovering a huge tar.gz file. In any case I think your patch can be committed, but please give me some time first for verifying why Dolphin still gets blocked...
Thanks for the answer, Peter, and for looking at the issue. The patch was only meant to track down the problem, I would not recommend you to commit it, because: 1) it does not solve the problem 2) it does not cancel pending jobs if a new job is started. Actually, first I wanted to write a complete patch that does 2) but since the problem lies apparently elsewhere I stopped in the middle.
You're right Pascal, the patch should not be committed (I missed the cancel pending jobs point). I had a look at the KFileMetaInfo source and to my surprise the KFileMetaInfo::What flags are completely ignored in KDE4. I'm not sure whether it is possible giving Strigi a hint to return only meta data which can be received in a fast way. As you said the constructor of KFileMetaInfo blocks for a long time when hovering huge zip files, the blocking happens in KFileMetaInfo::init(), where strigi is asked for delivering the meta data... I've reassigned this issue to kdelibs, as it needs someone who has the time + knowledge to fix this in a correct way. @Jos: I think you'd have the best knowledge to fix this issue. May I reassign this issue to you?
OK, great that it is going to be fixed by the right person. Nevertheless, I don't understand why the asynchronous job could block the system. Aren't jobs executed in a separate thread by the scheduler?
Peter, you committed the fix for this one today, right?
@David: Yes, I committed a fix yesterday on trunk that does not use KFileMetaInfo anymore. The patch uses Nepomuk directly -> more meta data is available and no blocking occurs. There are still some details open, which will be clarified during the next weeks, but I'd like to close this issue for now.