+++ This bug was initially created as a clone of Bug #166747 +++ Every time that I pass through the icon of a big pdf file, it freezes dolphin. After chasing a little bit thius bug it seems that dolphin call libstream0 that call pdftotext that is so slow, but in any case it should not freeze dolphin. information retrieval should be async and done by a low priority thread. This bug kill me browsing with dolphin, because it is really really slow (near crash for 3 minutes, may be need to be classified as crash). Workarround: disable information pannel
Debian bug 539488
On which KDE version ? Dolphin at KDE4.2 retrieves the information using Strigi which causes freezes. Dolphin at KDE4.3 has fixed this issue and now it uses Nepomuk to show already fetched information without blocking the GUI. Thanks
Qt: 4.5.1 KDE: 4.2.4 (KDE 4.2.4) Dolphin: 1.2.1 Could be possible to get the back port for distrib or at least a pointer to the patch used?
A backport would be difficult and very risky, as the patch relies on new Nepomuk interfaces and also includes translation changes.
I forgot: If this blocking issue should be solved for KDE 4.2.x the "easiest" thing would be to fix the strigi analyzers. Some strigi analyzers (MPEG, PDF) don't respect the maximum size hint of 64 KB which is given when retrieving the data by KFileMetaInfo. I've informed the maintainers about this 2 months ago, but AFAIK the issues have not been fixed yet...
Ok thank could you point to the bug report ??? thank you for your answer
The bug reports are here: http://sourceforge.net/tracker/?func=detail&aid=2830902&group_id=171000&atid=856302 http://sourceforge.net/tracker/?func=detail&aid=2830904&group_id=171000&atid=856302 (I've just created them, as until now I just had an e-mail conversation with the maintainers)
Unfortnatly 4.3 does not solve this problem or half close it. the first time dolphin freeze, but the second time it work as expected. Thank you
Any news of this bug ?
Any news ???? the strigi bugs are really boring. I suppose this bug could be worked arround if creating the index is made using a lower priority thread. What do you think about that ? It will be quite natural to lower the priority of this task
@roucaries: I cannot reproduce this issue with KDE 4.3.x/trunk. The index is created asynchronously already. The issue with KDE < 4.3 has been that: 1. The meta data has been read synchronously. 2. The Strigi indexers for PDFs and MPEGs (see comment #7) did not respect the maximum file size. Since KDE 4.3 Dolphin uses Nepomuk to read the meta data, which is done asynchronously. Is it possible that you have enabled the tooltips? They still need to get ported to use Nepomuk too (will be done for KDE 4.4).
Dear Peter, I use the tooltips as you say. Thank you for the precision. Could you also remind the strigi maintener about the bug in comment #7 Regards PS: BTW I believe you could change bug status from unconfirmed ;) Bastien
OK, the tooltip issue will be fixed with KDE 4.4 :-) Regarding the strigi issue: I hope I find time to fix this issues myself (I contacted the maintainer already, but he seems to be busy with other things).
Any news of this ?
Sorry, I forgot to close this issue (too many duplicates in the database...). This issue has been fixed in KDE 4.4: also the tooltips now use the same approach as in the Information Panel (-> asynchronous reading in a separate thread).