Forum Replies Created
-
-
26th June 2007 at 5:43 pm #14701Then could you provide the exact data you put in the crashing job ?
The best thing would be a queue snapshot sent to vvsupport@vvertex.com
Regards.
26th June 2007 at 5:41 pm #14700By the time of your writings, any kind of installation issue has been solved. If you get this kind of error, it means there’s a problem with the user created or assigned to the service.
try to install Muster as console application and check it’s working. then move on the service install again.
you can tell the Installer to use a customer user and leave the fields blank, this will install the services using the builtin windows account, then you can change it manually through the service control panel applet.
25th June 2007 at 3:17 pm #14697The dispatcher should not crash but reports an “unavailable memory” error. I’m going to test a render with your exact size.
did you try with different sizes ?Regards.
21st June 2007 at 12:25 pm #14691Bug confirmed.
This has been fixed in version 5.2 and later.
21st June 2007 at 12:24 pm #14696About this topic:
We are working on release 5.3 that will provide an in-memory cache working setup. This will speed up things as they were on version 4.X but won’t let INSERTION/UPDATED on the DB during Muster usages (only SELECTS). This will be user configurable, so if you don’t need to modify the database from custom applications, you can move to the in-memory caching feature when the new version will be ready.
Regards.
21st June 2007 at 12:17 pm #14695To modify an existing template, there’re several sections to be changed. In order to help you, we need a dump of the external render usage.
If you’re able to post it here, I’ll be glad to give it a look.By the way, the Muster reference manual has a section fully dedicated to the template engine where you can understand the meaning of each section.
Regarding what you posted, that will work if the render is directly integrated in the Maya batch render , that’s why we need further info on the Vray plugin you’re using.
If this is the case, you just need to change the -r sw to -r vray and assign a new template ID at the beginning of the template file.
But as I said, we need more info.
Regards.
21st June 2007 at 12:15 pm #14694This happens cause the job goes in timeout. Small packets are rendering because the timeout doesn’t happen before the rendering completation and Muster still process the render as successfully, but unfortunately , the template is configured badly.
Check the following section of the template you’re writing:
SET DETECTION_LOGIC CHILDPROC
SET DETECTION_LOGIC_PROC “PROCESS NAME”This is where you tell Muster how to hook to the spawned child process. If the nuke executable batch render is a SINGLE process, in example, you spawn a MYRENDER.EXE -MYPARAMS and the Task Manager reports a MYRENDER.EXE allocating memory and working, you should modify the lines to:
SET DETECTION_LOGIC DIRECTPROC
SET DETECTION_LOGIC_PROC “MYRENDER.EXE”If the batch render spawns another process, as it happens on Maya where the Render.exe command spawns the mayabatch.exe command, you should modify it to:
SET DETECTION_LOGIC CHILDPROC
SET DETECTION_LOGIC_PROC “Mayabatch.exe”Off course, Mayabatch and myrender.exe are only placeholders, you should check inside the task manager, how the processes are called.
Also, if you post your template, I could give it a further look.
Regards.
16th June 2007 at 11:07 pm #14690Just go to the download section and download the latest what’s new.pdf document, in includes all the changes since 5.0.
Regards.
11th June 2007 at 11:03 am #14689Never heard about such kind of crashes, I suggest you to check your file server as well as your licensing configuration.
Regards.
9th June 2007 at 1:59 am #14687Related to this issue:
We find a problem when starting the clients in daemon mode, I hope that kind of problems happens when forcing Muster to run using the -d.
If that’s positive, then version 5.2 address the problem on the renderclient. Also we are going to release 5.21 in the next days that address the entire daemoning sequence.The problem is dued to some broken pipes that stay opens after firing as daemon. Under certain circumnstances, the processes get the SIG_PIPE signal that’s actually unhandled and dies spountaneous.
Regarding previous versions, running the base process forcing background processing (i.e. dispatcher& ) will fix the issue.
9th June 2007 at 1:54 am #14686Ok, regarding XSI, the next service release will include a modified template that allows you to set the environmental variables on a client basis using the management console.
Regarding Max,as the log says, it’s an unexpected exception,I suppose you’re rendering a basic scene, so it may be something related to your file server ? As you see, it’s the max batch render that’s crashing just before starting the render. I may suppose it crashes when loading textures or other stuff.
You said in happens randomly. What’s the frequence of this behaviour ?
7th June 2007 at 10:30 am #14684If you submit the log of the chunk, it could be easier to give suggestions.
Regards.
31st May 2007 at 10:34 am #14683There’s a Fusion 5.1 template now into the newer versions of Muster 5.
29th May 2007 at 10:41 pm #14681You’re using the /k flag, this means, from Microsoft help:
Executes the command and stay
Basically the command is executed but the cmd.exe process stay alive, that’s why Muster is stuck with “Job in progress…”
You should check the /k with the /c flag, that means: Execute the command then terminate.
So:
SET COMMAND_LINE “/k %ATTR(THECOMMAND)”
should be:
SET COMMAND_LINE “/c %ATTR(THECOMMAND)”
Hope this helps.
-
