[zparrish]

I had to stop a render task with 400 frames. Upon resubmitting the job, my render nodes all said the same thing:

"[18/July/2014 09:17:07] New job order received
[18/July/2014 09:17:07] ##### Current frame changed. Frame: 124 #####
[18/July/2014 09:17:07] ANIMATION: fileFinalPath: GFPS-200_Rev02_0124.mxs
[18/July/2014 09:17:07] Entering in allDependenciesReceived..
[18/July/2014 09:17:07] This node will not receive dependencies
[18/July/2014 09:17:07] Scene:Y:\CS Products\EJC\All_Products-Max2013\export\Floors\GFPS-200\Animations\GFPS-200_Rev02_0124.mxs not found yet. Waiting for more dependencies..."

In the monitor, I don't have the "Send Dependencies" box checked, so each node should just go get the network resources. I also verified that the resources exist and are accessible to all nodes. I even RDP'd into each node and manually browsed to the assets. They are on mapped network drives (drive "Y:\" as shown in the pasted log messages) as opposed to direct UNC paths (\\<Server>\<Network Share>\CS Products\EJC\All_Products-Max2013\export\Floors\GFPS-200\Animations\GFPS-200_Rev02_0124.mxs). I restarted all the render nodes (mxnetwork.exe, not the actual machines themselves) and even restarted the running Manager.

None of the above seemed to work. I had to physically reboot all the machines in my farm before it returned to normal.

There was one non-Maxwell issue that happened in the midst of all of this though that may be the culprit. Our IT team is migrating 20-30 users to a different part of the building. To do so, they are doing some major work in the IDF where my main ethernet switch is. They "accidentally" unplugged the switch for a second but quickly plugged it back in. Fortunately, this happened between any major read/write requests by the nodes, so the render job never crashed. Surprisingly, the monitor didn't even crash or fail to report the status of each node.

The switch going down threw some kind of flag within Windows networking, but it appeared that all normal traffic was restored. When the switch rebooted, each node flagged the network drives with a big red "X", but once the switch was back, any basic request to those mapped drives was successful. I assumed that by reloading all the Maxwell network utilities, they would run as normal. That just simply wasn't the case. Does mxnetwork.exe store a non-persistent (dies upon reboot) cache of available file/system resources? If so, it would be nice if that cache was completely flushed every time mxnetwork.exe was launched. The ethernet switch might not even have anything to do with it either, I honestly don't know.

Thanks Maxwell Team! Happy Friday!

[limbus]

When the switch rebooted, each node flagged the network drives with a big red "X", but once the switch was back, any basic request to those mapped drives was successful.

Maxwell will fail loading dependencies rom any network drive with a red "X" even if it is accessible.

[zparrish]

Thanks for confirming that Limbus!

I did some research into the red "x" issue unrelated to Maxwell. Do you know if it has something to do with the "EnableLinkedConnections" registry value?

As an attempted work around, and since I'm really the only one that can access the nodes on my micro farm, I specifically set "mxnetwork.exe" to always run as an admin. I figured that was a little more secure than changing the registry value and potentially having all my network maps use admin rights for programs that aren't "Run as Administrator".

Here's the links I found regarding the registry value:

http://answers.microsoft.com/en-us/wind ... 8cbd136fb4

http://serverfault.com/questions/182758 ... ical-level

[zparrish]

Setting it to run as admin didn't work. I also tried the registry setting and that didn't work either. Mapping the drives via batch script on startup "kind of" worked, but it wasn't 100% effective. I think it's something here on our end unrelated to Maxwell that I need to resolve, probably related to GPO since the drive is part of a domain but the render node isn't.

Thanks again Limbus!