Freezing on search :(

[jpprater]

FARR seems to freeze during search.  The FARR window pops up normally when I hit my hotkey, but after the first character, FARR freezes for about 5 seconds.  It does this on every search.
If this were my web browser, I'd clear the temp files...is there something like this that I should be doing every so often in FARR?  What else should I try to speed things up?  Everything else on my machine seems to be running normally.  I'm using FARR 2.80.02.

Jon

[mouser]

This has been known to happen when search network shares.. can you check your launch history and see if anything is on a network -- maybe clear it to confirm that's not it.  You can also try disabling plugins to see if that's the cause.  Another trick is to enable the option to show subdirectories names during search, and pay attention to the status bar, see what it says it is searching when it hangs.

[jpprater]

This has been known to happen when search network shares.. can you check your launch history and see if anything is on a network -- maybe clear it to confirm that's not it.  You can also try disabling plugins to see if that's the cause.  Another trick is to enable the option to show subdirectories names during search, and pay attention to the status bar, see what it says it is searching when it hangs.

-mouser (January 11, 2010, 08:31 AM)

It was launch history.  I cleared my launch history and that did it.  Thanks!
When you say network shares, does that include network drives (e.g. an H drive that's mapped to a network path), or just UNC shares (e.g. \\server\sharepath)?  Because prior to seeing any slowness, I had just used the run alias to open a UNC share.  The slowness started after that, but the entry for that launch wasn't in my history.

[mouser]

Could be either.. BUT FARR tries to be smart and not resolve the UNC shares, so it probably was not that.  the network path definitely could have done it.

Since it was clearing your launch history that did it, this confirms that i probably need to have a way for farr to figure out which drives are network drives and shouldnt have their shortcuts resolved, or else allow a manual specification of such drives.

[jpprater]

Could be either.. BUT FARR tries to be smart and not resolve the UNC shares, so it probably was not that.  the network path definitely could have done it.

Since it was clearing your launch history that did it, this confirms that i probably need to have a way for farr to figure out which drives are network drives and shouldnt have their shortcuts resolved, or else allow a manual specification of such drives.

-mouser (January 11, 2010, 08:51 AM)

Putting a list of those drives in Options might be best, performance-wise.
I don't know how you'd check which drives are network drives via C++ or another .Net language, but I do know that you can query through WMI for that information.  Of course, you may not want to use that method because WMI can be slow sometimes.  If you want to try it, though, you'd use the following WMI query:

Code: Text [Select]

1. select * from Win32_LogicalDisk where DriveType=4

Win32_LogicalDisk is the WMI class representing drives on a computer, and where that class's DriveType attribute is 4, that drive is a network drive.

[mouser]

Thanks for the tips!

[jpprater]

You're welcome.
[EDIT] This might be of use...