[gehany]

Hello,

I have a cooperative render that froze (manager crashed), but managed to get most of the mxi files off of my local render machines. When trying to manually merge them, I am getting the error "Error merging: MXI files have the same cpu ID"? Why am I getting this error, and how can I fix it, if not for this job then the future? Thanks.

[Mihai]

Did you happen to manually specify a CPU ID when you started the coop render? Maxwell needs a random starting "seed" which is the CPU ID so that the merging can work correctly.

[gehany]

Is this something I need to manually set? I've been using the default options. Normally when the job finishes and sends the mxis, I can merge them no problem. This is the first time I've tried to rescue the mxis from a failed coop render by getting them from the machines themselves.

[Mihai]

The CPUID is initialized to a random value when rendering so it's not something you should set yourself. It's highly unlikely that these files had the same CPUID assigned....I can only think that somehow the randomization failed and they got the same ID. I would check and see if at least some of the files merge ok, or if all of them share the same ID.

[Gary Bidwell]

We have the same issue happening here.

We've rendered on 22 machines (via qube), and had 2 renders with the same CPU ID (seed).
And again rendering on 34 machines.

If we allocate our own random number, what's the maximum number of digits we can use?

On a separate note, is there a way to output the CPU ID from the MXI file (using the command line), without opening the mxi file?

cheers,

Steve

[Gary Bidwell]

Bump. Still happening. Can you increase random number choice?

[Gary Bidwell]

Anybody there? it's still happening. You need to increase your random seed count look-up. Only numbers between 1 and 16383 being used? leaving high probability of duplicate seed value.

error : >> Error: ID CPU must be between ( 0 - 16383 )

[Mihai]

If we allocate our own random number

But why are you doing this? This is nothing you need to set, you can do a network render as if that parameter isn't there.

[Gary Bidwell]

Initially we were hoping to circumvent the 16383 limit that is imposed when using -seed flag via command line (OSX) maybe using BASH random would give us a better algorithm.

When submitting jobs via the OSX command line using -seed flag the upper limit is 16383 otherwise it errors with the below.

error : >> Error: ID CPU must be between ( 0 - 16383 )

As we don't use maxwell render manager only command line (qube) each machine receives the exact same command independent of the other with no knowledge of which seed number has already been used. This enables the same seed value to be generated which may well be different than when using Maxwell's own manager. (error check?)

Why is there a limit and why so small when rendering this route?

[Mihai]

But why are you setting the CPUID at all? What if you simply omit it?

[Gary Bidwell]

We have tried letting Maxwell generate the seed but have had duplicate seed values used on different machines. We tried allocating our own random seed which is when we discovered Maxwell's limit of 16383. We are still getting duplicate seed values on occasion where two machines have the same seed, merging then fails. I think the pot of numbers they are selecting from is to small?

Does using Maxwell render manager check for duplicate seed values before submission where submitting via command line (via Qube) doesn't?

[Mihai]

I got some new info so first an important clarification:

The CPUID in fact is not just a random nr or seed but it relates to all the different "stages" a pixel can have during the merging process. So what happens when you use mxnetwork is the Manager sets first of all the CPUID to 0 and increments this nr by 1 for each node that takes part in the rendering. This is what you should do yourself if using a third party render manager such as Qube.

So instead of setting a random nr, simply increment the CPUID by 1 for each node.

If you are getting a merging error about CPUID it is 99% sure it is caused by merging newer MXI files with some older MXI files from a previous render, or invalid MXI files which will have the CPUID of 0. So it's really very unlikely you will reach that nr (16383) in one coop job, unless you haven't restarted Manager in 5 years, or started 2000 coop jobs at the same time...

So to avoid this, make sure to first delete all temp folders that the Maxwell node creates on each machine, and also the temp folder of Manager and Monitor (if you are using the mxnetwork for network rendering). Then restart the nodes (and Manager/Monitor if using mxnetwork).

[Mihai]

On a separate note, is there a way to output the CPU ID from the MXI file (using the command line), without opening the mxi file?

You can do this with the mximerge.exe tool:
mximerge.exe -mxiinfo:path

Which prints the SL, Time, CPUID etc.

[Gary Bidwell]

Hi Mihai,

great stuff, thanks for the info.

Cheers

[Jaime Maestro]

Hi,
We just got this same error using Deadline doing some tests, checked the CPU Ids value with the mximerge.exe and all of the MXI files have "CPU Ids used 0", is there a way to change the CPUID manually after the render is done?

Thanks in advance.