FileBrowserComponent extremely slow with network drives?

General JUCE discussion
1

Something odd is happening in my app when I use the JUCE themed FileChooserDialogBox. When the network drive is selected, entries are listed one at a time, at a rate of about one every 10 or so seconds. It can take upwards of a minute to grab the full directory list of even a small directory list.

When I watch the call stack, it looks like one entry is being picked up per refresh - where the refreshes are being called by an async event somewhere. The pause seems to be the interval between these events.

To my uneducated eye, it looks like the event that is supposed to be watching for file-system changes is doing the entire directory list, and for some reason is not finshing the job in one pass.

The code that calls the browser is nothing fancy:

void ScriptHandler::installScript()
{
	// prompt user for a script file to import
	WildcardFileFilter wildcardFilter(T("*.lua"), T("LUA script file"));
	File myFilePath(fImportPath);
	FileBrowserComponent browser(FileBrowserComponent::loadFileMode, myFilePath, &wildcardFilter, 0);
	FileChooserDialogBox dialogBox(T("Select LUA script file to install."),
		T("Please choose a LUA script file to install."), browser, false, Colours::silver);
	if (dialogBox.show()) 
	{
              ....
	} 
}

:?

2

The directory listing is actually done continuously by another thread, which posts occasional messages to make the UI update as it finds new files.

I’d guess it’s actually the win32 call that searches a directory which is blocking, but you can find out by tracing into DirectoryContentsList::checkNextFile(), and see if it’s getting stuck in the juce_findFileNext() call.

It’s odd, because I’ve browsed network drives here, on mac and PC, with no bother at all.

3

i’d go for the “Windows is slowing you down” part.

check if you have netork shares caching disabled and if your SMB settings are correct (using CIFS perhaps?)

in a bad network configuraiton windows can hang forever trying to find shares (some weird NMB packets are generated than).

use CIFS where you can if you can, all should be better.

4

hmmm, so where it is getting snarled up is:

DirectoryContentsList::addFile()

specifically, each of the lines:

info->fileSize = file.getSize();
info->creationTime = file.getCreationTime();
info->isReadOnly = ! file.hasWriteAccess();

can freeze for quite some time. This is intermittent. Sometimes a given file or directory can freeze on all of these, sometimes, only one, and sometimes none at all. I say file or directory - it could just be directories, I’m not really sure.

It seems the other info loading methods don’t cause pauses, but since the results are intermittent, I can’t be sure of this.

Tracing a little deeper, seems to suggest that is locking up when trying to gain handles to the files.

The share is a little odd in that it is a samba share from a linux box, and the machine hosting it is getting a little old in the tooth. However, Windows, and Linux can both natively access and manipulate files on this server at respectable speeds. Indeed, I can stream images off of this server at a respectable rate in other parts of my app.

5

That is kind of strange. It must be doing something like releasing and re-connecting the share for each operation.

I guess the solution would be for the file search routine to also return all the file’s info, which it could do much more optimally than using separate calls. That’d be a bit messy, as it’d involve changes to all the findFile methods, and platform-specific changes, but I’ll see what I can do.