Try the following check list to see what's wrong:

• Make sure that the client is licensed to render. If the Smedge interface says "Not Licensed" in the status bar, this client has not been able to check out a license to render. You can see how many licenses you have and when they expire in the About Smedge dialog box. You can also check if a client is trying to check out a license in the Smedge Options dialog box.

• Make sure that the client is enabled and allowed to render the type of job you submitted (e.g., Maya). These options are in the Client Settings dialog box.

• Make sure that your client has your renderer in the %PATH% environment variable, or that you have set the path to that renderer's executable in the Smedge Options dialog box.

• Make sure that you can see the scene file that you are trying to render on the client. For example, if the job is trying to render "D:\MyProject\scenes\MyScene.mb," make sure that your computer has access to the file through that exact path. If you are using a file server, make sure it's mounted on the same drive letter as the job requests. If you are using UNC paths, make sure that you can log into the machine serving the file and have read access for the file.

If you are still having problems, please contact Technical Support for more assistance.

This means that the OS cannot find the command to actually execute the renderer. The most common cause of this problem is that you do not have the renderer in your PATH environment variable, and have not given Smedge the full path to the rendering executable. You can solve this problem by either adding the folder that contains the executable to your PATH environment variable (then restarting Smedge), or by using the "../manual/client.shtml#options">Smedge Options dialog box to give the full path to the rendering exectuable.

Don't forget to include the .EXE file itself in this field.

Yes. In Smedge #32 or later, you can save all the jobs in the queue by using the Snapshot menu item in the Queue menu. This will save all the jobs, as they were submitted, into a single .SMR file. You can load this file again later using the Load menu option from the Queue menu. Note that no history is saved, so when you load the queue snapshot, it will be as if all the jobs had just been submitted. Any rendered packets will be rerendered.

Yes. Set up the email notification options in the Smedge Options dialog box. See The Smedge Cllient section of the manual for more information.

Smedge saves a lot of different information about jobs in different places.

The settings needed to re-submit a job can be saved in a .smr file. This file contains all the information needed to re-submit the job. The .smr file can be created manually by pressing the Save button on the Submit Job dialog box. It can also be created automatically if you have the Save the job settings with the scene file option checked in the Smedge Options dialog box. In this case, it is automatically saved with the scene file. If you are having trouble finding .smr files, turn your debug level up to Detailed to see the name Smedge is using to save the file, or to Excessive to see both the name and the default directory where the file is saved.

After a job successfully completes, Smedge will save an HTML file that has a complete breakdown of the known history of that job. Every client will create this file. It will be named with the scene name plus the ".html" extension. It is saved by default in the Smedge temp directory, located in the path:
%TEMP%\Smedge
To find out where your %TEMP% directory is, right click My Computer and choose Properties. Click on the Advanced tab. Press the Environment Variables button. Look for the environment variable called TEMP. Note that if this variable is set in the "User variables" section, that will override the value set in the "System variables" section. You can override this location in the Smedge Options dialog box.

Finally, each client can be set to save the captured output from the renderer. The option to tell the client to save this output is the Save captured output from each packet check box in the Smedge Options dialog box. The capture output file is named with the scene name plus the first frame of the packet plus a ".log" extension and is saved by default in the same Smedge temp directory as above. You can override this location in the Smedge Options dialog box.

You can look at the captured output to see where the rendered files went. The captured output is saved in the directory:
%TEMP%\Smedge
The output is saved in a file with the name of the scene + the first frame of the packet + ".log" (e.g., myscene.mb.1.log). In this file is the captured output from the renderer.

To find out where your %TEMP% directory is, right click My Computer and choose Properties. Click on the Advanced tab. Press the Environment Variables button. Look for the environment variable called TEMP. Note that if this variable is set in the "User variables" section, that will override the value set in the "System variables" section.

Choosing a packet size depends on several factors about your scene and your network. In general, the smaller the packet size, the better the granularity of distribution, which means more effecient use of machines. However, there is overhead time involved in starting the rendering application and loading the scene. If the ratio of overhead time to render time is high, you may want to use a larger packet size.

The number of clients in your network also plays a role. If you have 10 clients, it would be ineffecient to divide up a 50 frame scene into packets of 10 frames, because you will only have 5 packets, and thus only use 50% of your available rendering power.

The decision to use single vs. multi-threading is dependent on a lot of factors. Most importantly, if the renderer isn't multi-threaded, don't use multi-threading. In Maya 3, Paint Effects is single threaded. In all versions of Maya, initialization, post processes and particle runup are single threaded. If your scene takes 4 minutes to load and run up, 15 seconds to render, then 2 minutes to post process, use single-threaded. On the other hand, if your scene takes 800 MB of RAM to load, and you only have 1GB of RAM, use multi-threading.

In general, 2 single-threaded processes will be about 5% more effecient than one multi-threaded process, depending on how much bandwith your network and file server can handle. If your file server can't handle a whole bunch of processes hitting it at the same time, you might want to use multi-threaded jobs.

The single- vs. multi-threaded decision, and the packet size decision are ones you will have to experiment with on a scene by scene basis.

You may be able to use the Generic Script module to distribute a single frame render with some products. For example, you can disribute a single frame in maya with a commandline such as:

Render -xl #S -xr #E -im Slice#0S -n 0 -proj J:\MyProject MyFrame.mb

Use the X pixel dimension as your start and end frames, and the packet size as the number of pixels to render in each slice. For example, if you have a 10,000 x 7,000 pixel image, you can put 1 in the start frame, 10000 in the end frame, and use 500 for the packet size to make slices 500 pixels across. Each slice will be named with the starting pixel number (for example Slice0001.iff, Slice0501.iff, Slice1001.iff, etc).

For more information on the Generic Script module, see the manual page:
http://www.uberware.net/smedge2/manual/products.shtml#generic

Unfortunately, no, Smedge does not turn your machine into a hyperthreading monster capable of 50% more work than before. What has happened is that a single threaded job was launched, but when you enabled the second processor, that job was started multi-threaded. While the display is technically inaccurate, the actual affect on your machine isn't much different than if you ran the processes the correct way.

However, there is (isn't there always?) a way to fix this behavior in Smedge. If you go to the Smedge Options dialog box, and click on the Client Options tab, you will see a setting for When I toggle 1 processor on this client. If you set this option to Immediately kill a packet, this also affects the alternate behavior, when you enable that second processor. Smedge will hunt for a single threaded job running on the client, and kill it, leaving only the multi-threaded job.