Figured out what's causing this: Zone Alarm Anti-Virus.

I have a project that fails everytime on the first segment (which is rendered by the host). Turning off ZA AV fixes it.

Interesting facts:

Doing a local render doesn't exhibit the problem, even though it's a locally rendered segment that fails if doing a network render.

Vegas 5 did not do this - worked fine with ZA AV running.

Issue: I can't do any other internet based work if network rendering since I don't want to be working on other stuff w/o anti virus active.

i'm sure there must be a way to configure ZA to allow the NR to ocurr and still keep it protecting other stuff.

Presumably all the computers on the LAN are in a local address block, probably 192.168.1.0/24 (or 192.168.1.0 -- 192.168.1.255 if you prefer). It's very easy to tell Zone Alarm to pass all requests in this range. In fact, i believe Zone Alarm has an option to "allow all LAN communication" or something like that. It's also safe to do this when connected to the 'net since requests in this range simply cannot pass through the gateway to the outside world and the outside world cannot "pretend" to be in this range. Your ISP's routers simply won't allow it.

If you have real IP addresses rather than a NAT-mapped private range then you can still tell Zone Alarm to allow just the ranges of addresses you use.

One caveat: if you do this you are not protected from other computers in your LAN that may be infected! Hopefully you've avoided having that happen.

It's not a problem with access over the network or ZA setup. Everything works fine. I can open Vegas temp files over the network from the render clients.

It is also a LOCAL issue - sometimes the error occurs when the HOST tries to open a file on the HOST. ONLY if network rendering. If locally (not network) rendering everthing works fine.

Also, it frequently fails PARTWAY through the ENTIRE job. Many segments render fine and it fails on segment 5 or 25 or 39 ....

Again, Vegas 5 worked fine network rendering on the same system. The change is to Vegas 6.

Theory: it takes time to scan the temp file and vegas times out quickly waiting for access and fails the segment.

If it's not a problem with Zone Alarm - then why did you tell us this was the problem above? I'm confused!

Even if you are doing a local NR - ZA MAY have an impact as the local copy of your NR client will still be utilizing some parts of the networking stack to get it's jobs done. In fact... the LIKELY issue here is a common one related to the DNS SUFFIX of your computers. Follow the instructions in the following Sony Knowledgebase Article

Have you looked into the NR Logs as I suggested in the first reply to your question two weeks ago? The log files will often give much more information to you of what the issue is - and may be especially helpful for the problems with the segments that you say don't get rendered. Check the logs on each of your NR nodes.

The problem may not be simply an issue of V5 vs V6 but issues to do with access to the assets used in the Veg file you are now trying to network render.

The logs may hold the key. Please check.

Sorry if I confused things - it IS some kind of interaction between ZA and Vegas. It is not basic networking setup such as putting my local network in the trusted zone. All normal networking is working fine.

I looked in the logs when you first suggested it. There is no more information than the same error text I got.

I checked the accessability of all media files and plugins. This happens even if there are no audio or video FX used at all, not even the defaults.

I do not see how DNS suffixes come into play as I have directly entered into the network rendering app the static IP addresses of the devices on my network.

I will try that and see what happens though.

Basic networking (like sharing files and stuff) is no indicator of how other types of programs which do anything with networking will work with Zone alarm. Programs like the Vegas NR will connect using special "ports" which would usually be blocked by ZA.

I do not see how DNS suffixes come into play as I have directly entered into the network rendering app the static IP addresses of the devices on my network.

It does SEEM as if that would be unlikely... however I have had the exact same issue with one of my render nodes a few weeks ago. In fact if you look at the status bar on the network rendering window - you will see that each one has the full DNS name - even if you just specified the IP address in your "master" Network Rendering node (the one which communicates with the other nodes to tell them what to do).

In fact in my case it was definitely something that worked find in V5 but when I upgraded to V6 is when this one particular node stopped working. I traced the issue (with the help of Sony support) to the DNS suffix on that one computer. On that one computer I could not run any NR (even - non-distributed) it would simply say it was "Starting" and then never do anything else. As soon as I followed the instructions to configure the DNS suffix as specified it started working.

The even stranger thing is that my other 3 network rendering nodes do not have a DNS suffix specified either - and yet they all work just fine.

Bottom line... try setting your DNS suffix. I bet it will cure at least one of your problems.

I have no DNS suffix - I'm not using a domain server, just a peer to peer network with static private IPs.

FYI: Disabling specifically the anti-virus and NOT the firewall in ZA security suite fixes this problem.

Yes... and me too.

Did you try the suggestion in that knowlegdebase article. See what your DNS suffix comes in as... mine is set by the ISP I use (COX)... so when you do IPCONFIG it comes up and says "computername.oc.cox.net". That's what you have to plug into the computer name suffix.

Don't resist... just try it. It'll take you a lot less time to try it than it did to post how it didn't apply to you.

I'm not resisting - I already tried it and it comes up blank. I'm behind a Win2K workstation acting as a router and NAT firewall between my net and the outside world. It also comes up blank on that machine.

Still more data: the problem goes away by only disabling "on access scanning" i.e. inline virus scanning in the anti virus setup of ZA. I'm convinced it's not the firewall but the antivirus.

Ok... I'm convinced (now) I wasn't quite getting that you had verified this before... I do now.

SOunds like you have the answer there now... so does disabling that feature make all your NR work now?