What operating system, what hardware configuration?

I'm running WinXP on a dual Athlon 2400+, 2 GB RAM, Ultra160 SCSI disks... and I get the same thing occasionally. I wonder if the MP serialization points (mutexes, spinlocks) in a dual-proc system aren't exacerbating the issue rather than helping it.

Some things that help on XP: Turn off the indexing service, pull the ethernet cable or else disable the network connection, turn off the virus scanner "permanent" protection, kill things like Outlook that would try to check for email or etc. every few minutes... and don't touch the mouse or the keyboard during the hour.

I'm considering putting together a single-proc Barton box that will just do rendering and keeping it utterly clean. or maybe have an alternate OS install set up that's completely clean.

This process of "rendering" out to a DVcam reminds me of burning CD-Rs in the early days, when a Pentium 100 could barely keep up with a 4x burner. You didn't dare so much as move the mouse during a burn. We're in the same sitch now - as far as I can tell the DVcam has almost no buffering on board, so it needs the data over the firewire port at an extremely steady 3 GB/sec or so. Now 3 GB/sec is a very slow crawl to modern computers, hard drives, and a 1394 cable, but as important as the long-term average transfer rate is the avoidance of gaps between chunks of data - gaps caused by your system getting "distracted". Even though the computer could send the data faster, the cam can't take it any faster... so the computer can never get ahead, and once it falls behind, your tape has a dropout. The only cure is to make sure it never gets behind.

Does anyone know why miniDV tapes had to be a different form factor than DDS3? Looks like the same capacity. If the silly cams had just used DDS3 carts you could simply "render" to an internal DDS3 drive, and not worry about gapping. Alternately, why can't I buy a miniDV transport that can go on my SCSI or IDE bus?