Hi, John, and thanks for all the help you've provided. I can see you've been very active on this topic and others.

I did a load of checking this morning. I fixed a DNS problem on my server (my bad). I changed the names of the shares on the "main" machine, deleted them on the remote renderer, and then remapped them.

I modified the firewall settings on both machines. Their firewall settings now include a Vegas service at the correct port (57304?) activated for each machine on that machine.

I started the firewall logging service on both machines. When I begin rendering on the main pc, the firewall logged that it opened the tcp port. Then it closed it almost immediately.

On the rendering machine's firewall log, the port opened, stayed open for about 45 seconds, then closed. Meanwhile, it never "got" the job from the main machine, but continues to show "ready" in its status. It shows ready in the main machine's network rendering box, too.

Curious.

I am a bit confused about what goes into the second dialog box that opens when you start a network render. For testing, should I check the distributed box or no? Also, in the dropdown box, am I correct that it should have the name of the main (or local), machine rather than the network rendering machine?

Further, the temporary files dropdown box at the bottom of the dialog seems to be defaulting to a UNC path. Is that correct or should it be in the other form, e.g.

C:\Rendering where that's the share name?

Thanks again,

Bill

OK, I got it working.

I will make a complete list of what I checked to make it work.... name resolution and security settings are suspects.

The following information applies to network rendering on a network with a domain controller. Here are the things I did. Unfortunately, I ran out of patience to test each one individually so that it many have been a combination of more than one thing... but you will have some ideas if you are fighting this battle.

The initial symptom was that the network rendering interfaces on both computers were showing "Ready" but the network rendering computer never got the job.


1. Run ipconfig from a command prompt. If your domain name is not listed in the top field, open up My Network Places, click properties, select TCP/IP. Make sure your computer has a static IP and that your domain controller's IP is in the DNS server list. Click the advanced button. On the DNS tab, make sure your domain controller's IP is in the DNS server box. At the bottom, put in the domain name in the DNS suffix box (i.e., "yourdomain.com" with no quotes). Check the Register this connection's addresses in DNS box and the Use this connection's DNS suffix inDNS registration box.

2. On the WINS tab, enter the IP of your domain controller if you are using WINS. Enable LMHOSTS lookup (won't hurt, might help). In NetBios settings, select Enable NetBios over TCP/IP.

3. Re-run ipconfig to verify that your domain suffix is now listed.

4. On the domain controller, make sure your computer is listed in the DNS service.

5. Firewall - add a Vegas TCP service at port 53704 and make sure it points to your primary computer, not the computer you are setting it on. You can set up a log file for your firewall which will specifically tell you about activity on this port. Handy for troubleshooting.

6. Shares on the primary computer must have permissions set up properly. One of the last things I did before it started working was to explicitly list the remote rendering computer in the security tab of the FOLDER, as opposed to the share dialog. I also put my user name for the rendering computer in and gave both the computer and user name full control over the folder.


7. I do not know if this is necessary or not. Some people here have posted that it is not, but I think it's not a bad idea to set up shares on the specific folders you are going to use instead of setting up a drive share and assuming that the share will propagate to subfolders.

8. Delete all the shares for rendering on your remote computer and then re-add them, being careful that you name the share the same way that it is named on the main computer.

9. I saw somewhere that someone advised to put the fully qualified domain name in the rendering hosts tab of the main computer. I found out that after I fixed the DNS for my network, this was not only unnecessary, it didn't work. Just the computer name, not the domain suffix. I think this is actually a good way to test your DNS functionality.

So, after doing all of this, I did a comparison between a render on my single computer vs a networked render. On a 5 minute video, the amount of time saved was about 45 seconds. The networked PC is a 1.6 GHz Athlon with 1G of memory on a 100 Mbit network.

Wow.

I have a third PC that I am going to add to my little "farm", and will report back as to the amount of time saved. I am not expecting a lot, since the 3rd PC is the same as the 2nd one. Well, maybe with the extra 45 seconds I could jot off an email to my mom.

I would appreciate anybody's comments on any of the above if you know what was relevant or not relevant to fixing the problem. No sense in sending people like me on a wild goose chase.

Thanks,
Bill

I am actually surprised that you got it to to work. I tried a couple of times but gave up. More power to you.

A little caution could be worth mentioning to some.

Playing with your DNS (and altering a DC setting) can have 'annoying' consequenques to those who run a network. Altering Ip config can lose your internet connectiviity, network access or anything similar.

Playing is good - but make a note of your current settings first in case you need to revert back! (that's really the point I'm making here)

You could always speficiy machine by ip, instead of FQDN, and those at home typically use 192.168.x.x and ipconfig will help if you don't know.

Network rendering is very useful, and with a properly set up network, it should not be that hard to actually get going. It's worth the effort to get it going - but as I said - make a note of your current config first just in case..

Good point, Kenny. I should have noted that if you are a client on somebody else's network, you should talk to the network administrator before you start changing anything having to do with your network connection! LOL! You might give somebody a few gray hairs if you don't!

Actually, if you have a network administrator, it ought to be part of their job to help you track this down and nail it. They would probably enjoy the break from some of the support questions they get like the ones in that other thread I was reading here yesterday. :-)

I have my own Win2k and Linux servers at home. So, this is a case of "Don't try this at work!" as opposed to "Don't try this at home!"

Thanks to all the previous threads on this topic that gave me an idea of some of the issues. It would be great to nail down exactly what works and what breaks it and document it somewhere. Maybe I'll do that, once I get my client's job done which will follow learning how to use the rest of the software.

-Bill

On a 5 minute video, the amount of time saved was about 45 seconds.Let's be clear on what network rendering is good for. First, it is rendering, and not encoding. This has been described in past posts, but rendering is the act of blending the tracks and fX together, whereas encoding is the act of putting the results of that rendering into a particular video format.

The feature is called network rendering and as a result, with the exception of DV video, it will only help you distribute rendering. With DV video, you can also distribute the encoding.

The next thing to note is that there are only two situations where it is worth spending the time to set up network rendering (which once you figure it out, doesn't take much time if you do it again). First, if you want your computer to be completely responsive while do a background render. For those of you with multiple cores or CPUs, this may be less of a problem because you can assign the render to one core/CPU while getting full performance on your timeline while editing another project. However, you use the non-distributed render to simply send the whole thing to another PC and have that PC handle everything. When not distributing, you can actually have that other PC do the render as well.

The other time you want to use this is when you have a ridiculously difficult render. If you are doing green screen, with lots of masks, various fX, 256-bit color (OK, that's an exaggeration), and anything else that takes time, a five minute chunk of video can take a day or more to render, even on a fast PC. In this case, I would consider network rendering almost a necessity. If you do this stuff a lot, then it would be worth it to create a rendering farm and put 5-10 PCs on the project, each with multiple cores and CPUs.

Well that shows you what I know. I'm a newbie, and on top of it I'm from Iowa where the term "rendering farm" has a whole 'nuther meaning.

Seriously, I have a lot to learn and I need to get up to speed quickly. I'm going to try to spend more time reading and less time pursuing things that are less important (like network rendering). I thought this would be a biggie but on my PC budget it doesn't amount to much.

Thanks,
Bill