Configure Backburner Manager

Linux setup

Stop the Backburner Manager service: /etc/init.d/backburner stop. The Backburner Manager service on the workstation is stopped, if it was running previously. If it was not running previously, a “Failed” error message is displayed. If starting Backburner Manager for the first time, configure the Manager before starting it. Otherwise, start the Manager.
The Backburner configuration file is at /usr/discreet/backburner/Network/backburner.xml
Start Backburner Manager: /etc/init.d/backburner start. Events are logged in /usr/discreet/backburner/Network/backburner.log.

OS X setup

In the Terminal run /usr/discreet/backburner/backburner stop
Edit /usr/discreet/backburner/Network/backburner.xml and configure the Backburner Manager settings as desired.
Save and close the edited backburner.xml file.
Start the Backburner Manager with: /usr/discreet/backburner/backburner stop. All Backburner Manager events are recorded in log files in /usr/discreet/backburner/Log.

Windows setup

As an administrator, run backburner.exe. The Backburner installation wizard appears.
If there is an earlier version of Backburner on the system, you are prompted to uninstall it.
Follow the prompts to install Backburner on the workstation. It is recommended that Backburner components be installed in the same destination folders on all machines.

Start and configure the Backburner Manager:

From the Start menu, choose Programs, Autodesk, Backburner, and then Manager. The first time the application is started, the General Properties dialog appears.
Optionally customize the manager configuration.
Click OK to start the application. The configuration settings are written to the Backburner configuration file, for example, C:\Documents and Settings\<user>\Local Settings\Application Data\backburner \backburner.xml. To restore the default settings, delete backburner.xml. Note that this file contains the configuration settings for all Backburner components installed on the same machine. The Backburner Manager GUI appears, displaying startup messages.
From the Edit menu, choose Log Settings to change the information that gets displayed in the GUI and/or written to the log file.
Click OK. The configuration settings are written to the Backburner configuration file, backburner.xml.
Restart the Backburner Manager for the changes to take effect.

Backburner Manager can be set up to run as a Windows service so that it starts with the workstation's operating system and runs in the background. When running as a service, no GUI is presented—events are logged to the log file only. Depending on how Windows is configured, it may be necessary to log on to a Windows account for the service to load.

Running the Backburner Manager as a service changes the location of the backburner.xml, wiretap.cfg, and log files to /backburner subdirectories of the per-user application data directory subdirectories belonging to the Local Service user. These directories are hidden to non-administrative level users. For example, on Windows XP: C:\Documents and Settings\Local Service\Local Settings\Application Data\backburner \backburner.xml

Set up Backburner Manager as a Windows service:

Open a shell and navigate to the Backburner root directory
Register the Backburner Manager executable as a service with the command managersvc -i.
To undo this, do managersvc -r.
The service can be started without rebooting from the Services GUI, typically accessed at Control Panel > Administrative Tools > Services. The service can be configured here.

General configuration

TCP/IP settings
Manager Port: <ManagerPort> The port used by the Backburner Manager. Default: 3234.
Server Port: <ServerPort> The port used by the render node(s). Default: 3233.
N/A: <NetworkMask> The default subnet mask used for the network. Default: 255.255.255.0. This value can be overridden using the Windows-based Backburner Monitor; when you launch the Monitor, from the Manager menu, choose Connect. Enter the subnet mask in the dialog that appears.

General settings
Max Concurrent Assignment: <MaxConcurrentAssignments> The number of jobs the Manager sends out simultaneously. This number depends on the processor speed of the Manager workstation, general job size, and overall network speed. Generally, the default value of four is adequate. Too high a value may cause an increased number of node timeouts because the jobs are sent faster than the nodes can handle them. In such cases, decrease the value.
Use Server Limit: <UseServerLimit> and <ServerLimit> The maximum number of render nodes allocated for a job. This can override the server limit settings in some applications. For information, see the application's Advanced Settings Dialog.
Use Task Error Limit: <UseTaskErrorLimit> and <TaskErrorLimit> The number of times a render node retries a task before suspending it.
Default Mail Server: <DefaultMailServer> The default mail server used for email notification. This mail server is used only for jobs that do not already have a mail server associated with them.

Failed node behaviour
Restart Failed Servers: <RetryFailedServers> Activate to enable automatic render node restarting. If this option is disabled, the render node does not attempt to render the job again after the first failure. This option is enabled by default.
Number of Retries: <RetryCount> The number of times the Manager attempts to restart a failed render node. The range is between 1 and 1024, default is 3.
Seconds Between Retries: <TimeBetweenRetries> The time between each retry in milliseconds. Default: 30000 milliseconds.

The state of a render node is recorded on a per-job basis. The Backburner Manager regularly goes through the list of render nodes for a job, checking for failures. If Restarts Failed Servers is enabled (set as 1 in the backburner.xml file), the Manager keeps track of the following:

The time a render node fails on a particular job.
The time elapsed since the node failed on a particular job.

If the time elapsed is greater than the specified seconds between retries, the Backburner Manager decreases the number of retries by one and resets the Failed flag for the render node. Once the failure count reaches the specified Number of Retries, the Manager stops trying to restart the render node for that particular job.

Once a restarted render node completes a frame, it is flagged as active and resumes processing until the job is complete.

Configure the Backburner Manager to access jobs on specified system or network drives by modifying either fields in the Direct Access to Job Path group of the Backburner Manager General Properties dialog, or elements of the ManagerSettings sub-element of the AppDetails element of the backburner.xml file.

Use these fields/elements when you do not want to have jobs kept on the drive or workstation where the Backburner Manager is installed. Examples of such situations are:

There is very little space on the system drive where the Backburner Manager is installed. If another system drive has plenty of space, share a folder on this drive called MyJobs, where jobs are placed when submitted. In this case, you would direct jobs to \\computername\MyJobs.
The workstation is used simultaneously as a Backburner Manager and creative workstation. To reduce the overhead on the workstation from the Backburner Manager, set up a shared job folder on a network file server, called backburnerJobs. The Win32 job path would be set to \\fileserver\backburnerJobs and jobs you submit placed on the file server.

Job path settings
Use Jobs Path: <RetryFailedServers> When enabled, defines job location using the Win32 or Linux paths. This tells the render nodes to get the job files from this location, minimizing the file I/O traffic on the Manager workstation.
Win32 Path: <Win32Path> The Windows file path where jobs are located. Click the Browse button in the General Properties dialog to search the system for the job location.
Unix Path: <UnixPath> The path where jobs are located. Click the Browse button in the General Properties dialog to search the system for the job location.

These settings can be overridden from the Advanced Settings dialog accessed from the Network Job Assignment dialog.

Default job handling behaviour
0: State: Do Nothing. When enabled, a completed job is left in the queue.
1: State: Delete it. When enabled, the job is deleted from the queue upon completion.
2: State: Delete After. XML element: <DeleteDays>. When enabled: the job is kept in the queue for the specified number of days upon completion. Once the number of days has been exceeded, the job is deleted from the queue.
3: State: Archive it. When enabled, the job is archived upon completion. Archive it is enabled by default for Windows Managers.
4: State: Archive After. XML Element: <ArchiveDays>. When enabled, the job is kept in the queue for the specified number of days upon completion. Once the number of days has been exceeded, the job is deleted from the queue.

These settings can be overridden from the Advanced Settings dialog accessed from the Network Job Assignment dialog.