Some questions:
 - do you see if contents of new directory matter (like "more files = longer delay")?
 - is it the same on other drives (eg. usb attached pendrive)?
 - can you check CPU load during the delay? (running some system monitor that draws graph would be useful)

- no, the delay is independent of the content of the folder (even empty folders produce the delay)
- just checked a pendrive, same issue here.
- I see no peak in CPU load diagramms. Also, manually setting the cpu frequency to 800MHz or 2.2Ghz makes no difference. 

Furthermore I just found out: browsing in a ramdrive (e.g. /dev/) is free of delay. To sum it up:

Delay on ssd drive and pendrive with vfat, ntfs, ext4.
No Delay on sftp and tmpfs.

The pattern i see: in the latter case Krusader can't calculate a free disk space information which is displayed in the panel above the files. CTRL+R also causes Krusader to stand still for 2 secs in locations of the first kind, not on sftp and tmpfs. Could that free-disk space calculation somehow lock the program for a short time? ...just guessing...

Any ideas welcome!

Pretty strange, please provide us with some system info (like kernel version, arch).

I would try to strace the process - can you try that?

My system: 2.6.39-0-generic #5~20110427-Ubuntu SMP Wed Apr 27 15:27:41 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

The issue was on kernel 2.6.38 as well.

I tried strace but I don't really know what I should be looking for in particular in all the output...

More observations:
* No delay: sftp on my local drive (sftp://localhost/)
* No delay: entering and browsing a archive (like tar.gz)
* No delay: ramdrives which "No space information available" e.g. /proc, /dev
* Delay: on ram-drives where space information is available e.g. /var/run
* MountMan reacts very slowly too. Over 5 seconds to start it and then selecting entries in the table by clicking on them happens with 2secs delay or so.

I therefore suspect my issue is somehow correlated to mountman, diskfree or something. Is it possible to disable the feature of automatic disk space calculation/refresh at directory changes?

It seems this bug isn't in Krusader but somewhere in kdelibs or even something specific to your system.
I added the option Panel > Status/Totalsbar > Show space information
in commit be38e2de66910b9bfd2050a582fcf744fa73c53c.

Thanks. Haven't looked into it any further. For the moment I use the Krusader 2.0.0 binary from the Ubuntu 10.10 amd64 distro, which does not show the problem.

I have exactly the same problem. And this doesn't only appear in krusader.
It's the reason I switched from KDE to Openbox and got rid off most KDE programs, because everything KDE related was constantly lagging with these mysterious 2-second lags. And it seemed not a single other person had that issue.

For example kedit & kwrite were hanging for 2 seconds every now and then while typing; non-kde-games were impossible to play because of these lags (if played in a kde session); Just everything had these lags.

Since I couldn't live without krusader, because there's nothing comparable, I fiddled around with this for weeks and finally found a "workaround" (already being in openbox).. Downgrading to kdelibs-4.4.5.
With these kdelibs, everything worked perfectly.

Now, just today I decided to give it a try again and upgraded to 4.7.0.
And *boom* - the lag is here again.

Since the only KDE-program left here is krusader, i can only talk about this one - but I'm pretty sure, it's exactly the same problem as it was 1 year ago, with sympthoms exactly as they're described by hohl@7z7.zapto.org.

Now I can't downgrade that easily, because 4.4.5 is not in portage anymore.

I'll happily provide you with every information you want..

noother@noothbook ~ $ uname -a
Linux noothbook 3.0.0-gentoo #1 SMP Sun Jul 31 08:10:33 CEST 2011 x86_64 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz GenuineIntel GNU/Linux

KDE (kdelibs) 4.4.5 worked fine & it started lagging with KDE 4.5.0.


Please, this 2-second lag on each and every directory change drives me crazy :(

Oh, and one thing I didn't try, but just did is disabling the space information in krusader. (Comment #6)

This works around the problem in krusader and directory changes are fast again. (But that's of course not the ultimate solution - I actually need/want the space information :| )

My krusader-Version btw: 2.4.0_beta1

And I'm not sure anymore, maybe I was mistaken about kwrite/kedit (That was a long time ago and I don't remember exactly.) I just installed kwrite and it works fine. What's not working fine is the krusader internal editor. This still lags every few seconds while typing, but also gets fixed by disabling the space information in krusader.

I'm going to install KDE again and will report, if everything is still unusable or not.

It looks like it is gone from everwhere else. Maybe these were two different bugs, which were introduced with the same upgrade back in 4.5.0.

But still, these 2-second lags in krusader are still current with 4.7.0 and incredibly annoying - and workarounding it by disabling the free space display & typing "df" in a shell every 2 minutes is not a perfect solution :(

I erroneously closed this bug - reopened.

Could you please try the following:
in file krusader/Panel/listpanel.cpp in function ListPanel::gotStats():
remove the last line : mediaButton->mountPointChanged(mountPoint);

And/or you could try if this happens in 2.2.0-beta1 or earlier.

Hi - here are the results:

2.4.0-beta1 with nothing changed
	=> bug happens

2.4.0-beta1 with removed mediaButton->mountPointChanged(mountPoint);
	=> bug doesn't happen :)

2.3.0-beta1 with nothing changed
	=> bug happens

2.3.0-beta1 with removed mediaButton->mountPointChanged(mountPoint);
	=> bug doesn't happen

2.2.0-beta1 with nothing changed
	=> bug doesn't happen (the removed line isn't in there yet)

2.0.0 with nothing changed
	=> can't compile: krusader-2.0.0/krusader/MountMan/kmountmangui.h:116:34: error: call of overloaded ‘QString(int)’ is ambiguous

2.0.0-beta2 with nothing changed
	=> can't compile: krusader-2.0.0-beta2/krusader/ActionMan/actionproperty.h:16:31: fatal error: ui_actionproperty.h: No such file or directory

Also, the lag in the internal editor is gone where I wrote "bug doesn't happen".

I investigated further by trial&error and found, that this is the line which causes the delay:

QList<Solid::Device> storageDevices = Solid::Device::listFromType(Solid::DeviceInterface::Block);

in krusader-2.4.0-beta1/krusader/MountMan/kmountman.cpp, line 484 (part of QString KMountMan::findUdiForPath())

If I put a return QString(); just before that line, the delay is gone. If I put it after it, the delay is there.

Something interesting I just noticed is, that hohl@7z7.zapto.org seems to have a similar computer to what I have.
I also have a 2.2Ghz where I can set the frequency to 800Mhz. It's an Acer Aspire 7720G Notebook.

I don't know - maybe it has something to do with some certain kind of hardware?

I don't have an SSD, though.

Thanks for your investigations. I don't currently have time to look further into this, but looks like a bug in Solid or its back-end.
The two second delay without cpu-peak suggests an IPC problem.
I also remember there were some issues with D-Bus (which Solid might use) and kde.

It would probably be best to report this as a Solid bug.

I have exactly the same problem. I've changed the source according to Comment #14 and now it works for me.

I also have an Acer Aspire: 5742G-384G50Mnrr (Intel Core i3 380M, 2,5GHz, ATI HD 6370)

*** Bug 291669 has been marked as a duplicate of this bug. ***

I also have an Acer aspire 5742G, also have a friend with an Acer notebook (not the same model) who suffers from this.

I have the i5 M480 @ 2.67GHz.

Looks like this might be an Acer only issue?

Makes me think maybe it's worth trying some different kernel cmdline options. Currently the only one I have is acpi_backlight=vendor to get control of my backlight.

This is mainly because we are lacking an Async api, once that's implemented nobody will freeze agian.

*** This bug has been marked as a duplicate of bug 253654 ***

*** Bug 317017 has been marked as a duplicate of this bug. ***