Since we debugged this offline, here is what we found for anyone interested:
*The SMTD defaults and sticky settings are being loaded from two global INI files located in the Repository\Submission\3dsMax\Main folder.
*When the Repository is on a remote server, the access to these INI files can be very slow, esp. if the network is optimized for large files (e.g. image files).
*The obvious solution would be to copy the two INI files together with all the script files which are already being copied locally to speed up the start up of SMTD, and then parse the values from these local copies.
This fix will be in Deadline 6.1.
If anyone else is experiencing this problem, please let us know and we will show you how to fix it or will fix it for you in your 6.0 files.
Interesting. Just throwing in some passing comments here…
I assume you will be adding these INI files to the local disk caching SMTD code and therefore if either of these INI files are updated server side, then upon re-launch of SMTD they will be copied back down again?
Also, just for consistency, I would include the other INI files to be cached locally as well?
The only drawback is that the Client-side script has to be updated again on all workstations since part of the change is in the list of files to copy over.
Cool. As this will mean all clients updating their client side script again, I’m thinking this would be a good reason to get Ryan to update the “Submission Scripts” py menu UI, to help users easily re-deploy the client side script when v6.x comes out in the future? (Ryan never got round to updating this py tool before v6.0 launch)
Alternatively, I was thinking the other day, it would be good if the client side script could somehow be decoupled and therefore have the ability to auto-update itself? ie: distil the absolute minimum MXS code in the MCR file (‘never’ needs updating), which in turn when executed within the 3dsMaX GUI environment, it pulls in a file which critically is referenced from the repository? Then on the odd occasion, when the MCR is updated (a few times over the years IIRC), then it won’t be such a big deal…? Effectively, Yes, I’m describing the already in place local caching system!..I’m just writing out loud if there is a better way that should be explored to try and avoid the client side script having to be touched…?
I had the same thoughts last night.
It is a bit of a problem because the file that you are running is not the same file that is in the Repository, it is an MCR copy unser #usermacros created by Max. I have to make sure it is actually identical in size, because the date would not be an useful check for this kind of update.
I have some ideas, but I see a lot of question marks on the way. And with Siggraph coming fast, I’d rather not concentrate on this problem right now…
