DR Render Node stuck on random stripe

[sedus69]

Hi I m using Corona lastest build 1.6 27 March, But Bug was allready there in previus 1.6 beta.

Main Machine XEON 2973V4 64 Go Windows 10, Render Node  XEON 2973V4 48 Go Windows 10.

On a random basis, can't figure out how to have the bug, The node get stuck on a Stripe to render, And not contributing on the whole Image.
It is very annoying because the node doesn't allway contribute to the full render, and render passe go cray 1500 pass after 8 min...

See attached image.

I have no Render Region (Max of VFB) activated, and take special care to disable every region.

If someone have any clue.

[sevecek]

Could you send me logs from the slave? Thank you.

[sedus69]

Here are log file.

On the actual Max file, One camera render with a stripe, The other seems to works fine (Full contribution of Render node)

[sedus69]

File attached

[sevecek]

Too bad the DR log contains only data since 2017/03/30. I don't see any problems there, I suspect the problem happened before that?
Did you check the images that slaves render? Is it indeed the same strip every time, or does the slave render just black images for other strips?

[sedus69]

Sorry for Logs, I have reinstalled many time Corona (news builds), and it seems to erase every time the log file. Or juste to escessive on Purging Temps File on node HArd Drive.

Yes It did happend before, on a pure random basis.

The slave render only a Stripe (a very noise free Stripe...) and every thing else is pure black.

I think I notice tjat the stripe moves everytime, from bottom to too, By the increment on the pixel height... CAn be sure, because, I didnt take time to analyse, but I can enable retain EXR to figure out if it is.

I have 4 renders to run today, I will take attention to those. and get back to you.

[sevecek]

Could you check if the latest daily build fixes the issue?

[sedus69]

I will check, I reintall the slave this moring, BUT with Build 27 march 2017 > same Issue.

I Will download this afternoon the nuew build and get back to you

[sevecek]

I will check, I reintall the slave this moring, BUT with Build 27 march 2017 > same Issue.

I Will download this afternoon the nuew build and get back to you

Thank you, if you can, please save the images rendered by slave.

[sedus69]

I will send you a personal message with a link to a Wetransfert File (too big)

I think I understand what trigger the bug. The question is, Is this a bug, or am I just missing the thing...

The stripe Pixel if more or less 500 000 pixel = 3840*130 (499 200), which is Exactly the Numbers of MAX PIXEL TO TRANSFER AT ONCE.

So Is this a limitation, I missed, And I must increased the number. Or is this a bug anyway?

I didn't take time to Size up the limit and Make some test.

[sevecek]

Thanks for the images. I seems the DR behaves as expected. Each node only renders a strip constrained by the "Max pixel to transfer at once" parameter and when it sends the results over to master, it moves to the next strip. If you want to get the dumps from slaves faster, increase the pixels per transfer, or decrease the synchronization interval.