algorithmic modeling for Rhino
Once connecting the image sampler to a file path on the server GH will take forever to load the image (couple minutes). Even if they are just a few kb. Not sure, if I should redirect this to our IT, but as everything else works fine, I guess the problem is within Grasshopper itself.
Can anyone reproduce this delay?
I noticed the same problem and wanted to post as a bug, but saw your post. Its not your IT, its Grasshopper somehow not liking file servers, even though that seems ridiculous, since any company with more than 2 people (ie. most of Rhino's professional user base) will have a file server. Its the same problem for the text file reader, it just takes a few minutes. David Rutten gave some explanation why it happens, but I cant remember exactly what it was.
I really hope this gets fixed in GH2!!
I think the problem is that Grasshopper tries to keep track of files everywhere so it can respond when those files are updated. I started experimenting with a different approach from FileSystemWatcher a while ago, but I don't think I ever got anywhere.
Okay, but I dont understand why it would take several minutes to do so. Shouldn't there be some mechanism that will kick in after a few seconds? What is it doing for 4.1 minutes? I think if you were to use UNC paths instead of windows file paths, this wouldn't be a problem, since then it shouldn't matter where the file is located. Thinking about it though, I guess you must be using them anyways to have cross-platform compatibility with GH on Mac!? If not than using a file server would be a safe way to have files with links to external text/image files that will open in GH for Windows and Mac.
There is a script I found that converts server paths to UNC when using the fileopendialog. Maybe thats one piece of the puzzle. https://www.codeproject.com/tips/158829/convert-a-file-path-to-a-un...
For the text file reader I use a custom component, which simply uses the systems file reader:
lines = System.IO.File.ReadAllLines(file)
That takes 6ms to read a file on a server (J: is a mapped network drive). Could you not switch to that for the file reader?
As for the Image Sampler, not sure if it is related, but a lot of times the image sampler simply disappears due to some error. Do you know what is causing it? This is with images set from local file paths, so I guess its unrelated to the bug above.
Actually just saw here: https://msdn.microsoft.com/en-us/library/b36854c3(v=vs.110).aspx
that it says
The component can watch files on your personal computer, a network drive, or a remote computer.
So it would appear that it is not the function itself that is the problem, but something else. If you are using UNC paths, make sure to wrap them in " " in case there are spaces in any parts of the path. Once you convert from file path to UNC you will also see if it is on a server and can then not create a file watcher if for some reason in your case it CANT use a network drive as advertised.
Can I ask why you need the file watcher in the first place? I get that in theory its nice for the file to update instantly, but I can just use a timer or it would be nice to have an update pin on the file reader. Same with the image sampler, I dont need or even want it to always update instantly without being able to turn it off. With the advent of always autosaving software I'd rather not have my GH script constantly reevvaluate if I am working on a file that it is referencing in the script. Especially if I had to choose between automatic updates and not being able to use a file server/NAS, making all updating useless, because I have to copy the files locally first anyways. So the only way to actually get files to update across several computers with GH open is to use Dropbox, which is not really an option in larger firms and an incredible waste of resources uploading/downloading via the cloud.
Sorry to be rambling on about this, but its so incredibly frustrating to have to always copy images to the desktop first and then on another machine the image isnt there or its not the latest version, which like I said makes the filewatcher totally useless in its original purpose.