[juan]

Hello Zoppo,

We have other reports of a few people experiencing the same issue but we have not been able to reproduce it in our systems yet.

Could you please let us know if your OS language is german? Also, do you have paths (mxs, output paths or textures) in german? It should be supported, but in 3.0.0.0 there was a problem depending on the local settings that was corrupting tcp sockets after sending a message with non supported characters.

Which version are you running? We uploaded 3.0.0.2 to the beta page (http://www.maxwellrender.com/betas/), it is recommended you use that one (and please double check you update all the nodes, I know it sounds obvious but that is a very common issue).

Besides could you please confirm you have to enable the "send dependencies" options? What happens if you disable it? (which is the default behavior, recommended for networks with all the machines with the same OS)

Thanks,

Juan

[zoppo]

Could you please let us know if your OS language is german? Also, do you have paths (mxs, output paths or textures) in german? It should be supported, but in 3.0.0.0 there was a problem depending on the local settings that was corrupting tcp sockets after sending a message with non supported characters.

Yes, the OS language is German. I have some textures named in German but I do not use any special characters like ä or ö in any place.

Which version are you running? We uploaded 3.0.0.2 to the beta page (http://www.maxwellrender.com/betas/), it is recommended you use that one (and please double check you update all the nodes, I know it sounds obvious but that is a very common issue).

I run 3.0.0.0 with C4D.
I will install 3.0.0.2 in the next hour.

Besides could you please confirm you have to enable the "send dependencies" options? What happens if you disable it? (which is the default behavior, recommended for networks with all the machines with the same OS)

Confirmed. The workstation and some of the nodes are running Win7 pro x64, some of the nodes are on Vista x64.

"Send Dependencies" enabled:
The "Dependencies Path" setting is ignored (U: is the NAS)
"Dependencies Check" shows the texture path on the local drive F:


Nodes are getting the textures and are rendering.

"Send Dependencies" disabled:
"Dependencies Check" shows the textures in the NAS path.


Nodes are not rendering.

[zoppo]

3.0.0.2 beta solved the dependencies issues, all nodes are rendering now.

But the rendering still crashes right after voxelisation if "Auto-generate Instances" is enabled.
It doesn't matter if I just start Fire, if I start the render in MW Render or if I save the mxs and then start the network rendering.
Disabling displacement has no effect.

So I probably should take this issue to the plugin section?


In conclusion for others who have similar problems:

- Check if the firewall rules are set not only for Maxwell but also for the license manager RLM.exe!

- Reload your license file from the customer portal

- Disable IPv6

- Try the latest Beta

[Mihai]

The dependencies path thing you did there is "reversed" though - you need to enter a dependency path when you have Send dependencies unchecked. With Send dependencies checked, the Monitor will take care to send all the textures to the Nodes.

[zoppo]

Thanks. Your reply came just in time for animation render test.

[Mihai]

Forgot to mention, it's not always needed to enter a dependency path when you have 'send dep.' unchecked. For example, if you set up your scenes materials, IBL, IES, by browsing to textures,hdrs, ies etc. files through UNC paths (so your entire scene only uses UNC paths) a dependency path is not necessary. It IS necessary though if you worked on a scene locally, the paths to dependencies are local. Then you need to move/copy all these dependencies to a networked folder, and specify the path to it in the Dependencies path.

[juan]

Thanks for the info Zoppo, glad to see it works now!.

But the rendering still crashes right after voxelisation if "Auto-generate Instances" is enabled.
It doesn't matter if I just start Fire, if I start the render in MW Render or if I save the mxs and then start the network rendering.
Disabling displacement has no effect.

So I probably should take this issue to the plugin section?

Yes, please, open a thread there to discuss this issue further, thanks.

Juan

[zoppo]

Thanks for the info Zoppo, glad to see it works now!.

I'm sorry to disappoint you but I wrote too early.

I started a batch rendering of 250 mxs' in "single" mode without "send dependencies".
The nodes each grabbed a file and started rendering.
After a while I realized that one Node had crashed and that the Monitor window was not updated.
I restarted the Monitor and it showed the render progress but also still had the crashed Node in its list.
I restarted the crashed Node and suddenly / after a few moments the Manager crashed, taking all the Nodes except the restarted one with it down.

Then I restarted the Manager and the nodes and started the rendering as "Animation".
All the nodes started, each grabbing a frame. But only two recognized their frames as already finished and started new ones.
All other Nodes still say "State: running" but don't do a thing. It's like before when the said "New job received" but idled.
Then I reset one of the Nodes in the "Render Nodes" window of the Monitor.
The Node restarted but its name staid in the Monitors Job list with the same frame as running and now it is also in the job list under its IP adress, state "running" but doing nothing.

I will try it again, this time with "send dependencies".

Meanwhile one of the Nodes shows this:

[zoppo]

Again ...

It's the same Node (Quad3) as above.

The Node has crashed and the Monitor says:


I restart the Node and it says (and stays that way):


Meanwhile in the Monitor:


ATM the Monitor is still updating the other clients.


Edit:
The Node still shows this second CMD window:


It is the only node who does this.

[zoppo]

Well, this is getting ridiculous ...

The first "batch" of frames was finished fine apart from the one that Quad3 should have rendered.

The Nodes grabbed a new frame - and this happened:


Quad3 is 3 times in the list (blue !)

2600-2 (green) and most of the others say "state: running" but don't do a thing:


4770 (red) is the only one who got to his second frame and is rendering!

And Quad3 doesn't like the dependencies all the others took for the first frames:



ADDITION:

I restarted the Monitor, nothing changed.

Then I reseted a Node from the Monitor's node list.
The Node stayed in the list and was listed in the job list a second time under his IP address.
It did say it had a new job assignment but did not render.

Then I closed the Node manually and restarted it manually. Now it shows the same dependencies failure as Quad3.

And the Node is four times in the job list:

1 - finished first frame render
2 - second frame, state: running
3 - after the reset: under its IP, another frame, state: running
4 - after the manual restart: under its name again, "Received file (0/1) Tire ...) - BTW it is not file 0/1 - there are 20 textures / dependencies.


ADDITION 2:

I manually terminated all Nodes and shut them down and they vanished from the Monitor's Node List.

Except one: 4770, the only one that worked as it should is still in the list and the Monitor says "state: running" but shows errors in the console because 4770 failed to send dependencies ...


SOMETHING IS VERY WRONG.

[zoppo]

I started the same rendering in a smaller size so it took under 3 minutes per frame.
"Send dependencies" had to be enabled, without it the Nodes were shown as "State: Running" but didn't do a thing.

That is what happened:


Frames 0 - 46 were finished without a problem

All Nodes took a new frame as shown in the screenshot.

Suddenly the updates in the Monitor stopped as shown in the screenshot. It is frozen.

No Node / Manager / Monitor has crashed - Windows says they are responding, they just don't do a thing.

E.g. Node "Main-Brain" (red):
Monitor says the Node is rendering frame 49

But Main-Brain has finished frame 49 and went on to frame 57 where it stopped:






Seems like the Manager just stopped doing its job.

What should I do?


PS: After stopping the job this happens

[zoppo]

When I try to restart this job which got rendered up to frame 53 and chose Animation > Resume I get this:



The MXI files present are 0000 - 0053.

[juan]

Hello Zoppo,

Something went wrong during the send dependencies process, maybe due locale settings, or paths that some machines cannot understand. I suggest you give another try with "send dependencies" disabled, which is the default behavior. If all the nodes, monitors, and manager can see the NAS and have read/write permissions there, the jobs should start, we will try to reproduce it here, but I insist in the fact that in networks where all the machines are running the same OS it is better to keep send dependencies unchecked.

[zoppo]

Something went wrong during the send dependencies process, maybe due locale settings, or paths that some machines cannot understand. I suggest you give another try with "send dependencies" disabled, which is the default behavior. If all the nodes, monitors, and manager can see the NAS and have read/write permissions there, the jobs should start, we will try to reproduce it here, but I insist in the fact that in networks where all the machines are running the same OS it is better to keep send dependencies unchecked.

All Nodes, the Manager and the Monitor do see the NAS and have read / write permissions.

As you can see above they rendered over 50 frames before stopping without any reason.
It looks like the Manager lost contact to the job - the Monitor doesn't get updated, the Nodes don't get new frames assigned.

Node Quad3 read the dependency "Surface... .jpg" and rendered the frame, in the next frame he says he can't read it. Nothing changed between these two frames.

But those were separate incidences.

I know my posting is a lot to read but please read it carefully - I tried my best to explain what I did each time and how MW responded.

[zoppo]

Some facts:

It is a simple Windows network - Win7pro and Vista64.
The Nodes and the the work station which runs the Manager and the Monitor have fixed IPs.
The NAS is a Netgear DuoNAS v2. Its shares are connected as drive U: on all Nodes and the work station.

Cinema4D R14 Net Render, R15 Team Render, Vray DR via Standalone are running without a problem.

What more do you want to know?

Are there any log files to send?