Baffling Random capture problem

[Adam Gold]

Sometimes when I capture entire tapes (which I need to do for multicam edits of stage shows) about halfway through the captured file, the picture breaks up completely, with HUGE blocks, some black, some with picture. Like a dropout on acid, but it lasts for the duration of the tape. Recapturing usually solves the problem. The breakup is not visible during capture, which I play back on external monitor during capture -- it's only the converted CFHD-AVI.

This has happened on two different capture devices (Sony HC3 and M15U), two different OSes (XP32 and Vista64), with both Cineform capture within Premiere and with HDLink, with differing amounts on RAM (4 gig and 20 gig) and with three different RAID setups (7x1TB in RAID5, RAID5 with Hot Spare and RAID0), whether quality is set to Medium or High, with both Aspect and Prospect.

Capturing HDV 60i footage shot on FX1s and FX7s. No resizing or other conversions.

System: 2 Xeon E5430 CPU (8 cores total)
20 GB RAM
150GB 10K system disk
7 x 1 TB Work Disk, currently in RAID0 (Yes, I know that's stupid, but I'm just experimenting)
nVidia Quadro FX 1500
Areca 1231ML raid controller with 2gb RAM and BBU

Nothing even on the system other than Premiere and Cineform, Internet turned off, virtually nothing running in BG.

Anyone ever seen this before? It doesn't happen all the time, but enough so that it's annoying to spend an hour capturing one of the twelve tapes that need to go into the machine, only to have to do it over again. Happens I'd say maybe 25% of the time.

If this is happening during conversion, would it make sense to capture the original m2ts and then convert as a separate step?

Edit: Additional thoughts -- could this actually be happening during the import or "conforming" into Premiere? I haven't checked these files with another viewer. And if that's the case, could off-lining them and re-importing solve the problem? Will try this next time this happens.

Edit2: Just happened again. Played clip in WMP and it's there too, so it's part of the .avi, not a Premiere issue.

[David Newman]

This is an MPEG artifact, which points to hardware problem. Either the camera is messing up the data (unlikely) or the FireWire port is dropping packets (more common.) Some Firewire Port designs are bad, and will drop packets when the CPU is doing other thing like transcoding. If you capture to M2T and transcode in a second step, and it work fine, replace add or try a different firewire port.

[Adam Gold]

Never thought about the FW port. I'll buy a new one today; I think the existing one is just integrated into the Mobo.

Amazing how a $10 FW card an bring a $7,000 system to its knees. For want of a nail....

Thanks for the help.

[Adam Gold]

Update: I installed a new, separate FW card, but the problem persists, both from Premiere capture and using HDLink.

Any other ideas?

[David Newman]

If it only happens while transcoding, then it is a Firewire port or driver issue. You can confirm in HDLink using the M2T only mode. If that messes up and you replaced the FW port, then the camera is suspect. When this only occurs with trancoding, it means the PC is taking too long to response to packet requests from the firewire port, and due to a poor design the port drop important packets. Your PC is plenty fast enough, about 4X the power needed for RT transcoding, so it should be able to service firewire packets.

[Adam Gold]

Appreciate the response. Not really sure what to do now, though... two different FW ports (mobo and card), three different capture devices (two HC3s and one M15), three different OSes (XP32, Vista 64 and Win7). Rarely capture to m2t but I'll try that, I guess, and see if it happens there as well. The few times I've captured as m2t, no problem.

The constant seems to be long tapes I capture in one piece because they are multicam shows, and I need the whole tape. Don't recall it ever happening when I batch capture multiple little clips.

Maybe I'll just start always capturing to m2t in HDLink by default, then transcode later.

[David Newman]

At has to something the bus controller on the motherboard it causing delay responses to interrupts. This is a first, as I never seen this occur and replacing the firewire port didn't address it.

[Adam Gold]

I'm just proud to be finding new ways to screw this up.

So if that's the problem, what to do? Take the PC back into the shop (again!)? What do I tell them to look for?

Another thought: usually when capturing within Premiere in a CF project, the "Transcoding to Cineform Intermediate" box is only up for a few seconds after the end of the tape capture, no matter how long the actual capture was. But today the box was up for like 20 minutes, and that was the clip that came out that way. Could they be related or does this provide any clues?

[David Newman]

Another possibility: some other hardware device is taking too many cycles, causing the firewire to drop packets. Your RAID controller is a possibility, try capturing to the system drive.

[Adam Gold]

Good idea. Unfortunately, my system drive is pretty full with two OSes and not a lot of space, certainly not enough for an hour of tape transcoded to CF.

Here's another possibility: I have my swap file on the same RAID as I'm capturing to. Could that be the problem?

[David Newman]

Unlikely, can't you test shorter captures to the OS drive. Once you know, you can just add a $60 500GB SATA drive for your RT capture and converts.

[Adam Gold]

Sure, I could, but it's never happened with shorter captures.... only the whole tape, and the problem usually doesn't show up until at least halfway through or later.

Latest development: Just finished my first full-tape capture with HDLink capturing only the m2t... and it crashed for no apparent reason. Nothing captured. Will try again. Interesting: the first (unsuccessful) capture didn't count up the file size as it was capturing. But this time it is.

2nd try ok. No artifacts. Moving forward.

Thanks, David, really appreciate the help. And on a weekend yet!

Latest update: it does happen on straight m2t capture via HDLink. Will try capturing to system drive next.

[Adam Gold]

Well, I'm stumped. Happened when capturing to C: as well. It was just a few minutes in the middle of the capture; in the past it's started about halfway through and continued to the end.

System drive is controlled through the mobo only; the other 7 internal drives are on the RAID controller, so I guess the RAID controller isn't the problem.

Not sure where to look next, or what to try.

Hmph.

[Dan Kline]

Originally Posted by Adam Gold

Well, I'm stumped. Happened when capturing to C: as well. It was just a few minutes in the middle of the capture; in the past it's started about halfway through and continued to the end.

System drive is controlled through the mobo only; the other 7 internal drives are on the RAID controller, so I guess the RAID controller isn't the problem.

Not sure where to look next, or what to try.

Hmph.

Here are some random things to try:
Can you try removing all other cards from your system (including the RAID)?

Can you try putting your FW capture card in another slot? Maybe that slot is sharing interrupts w/ the vid card or another card.

You might want to look into using Window's Perfmon logging during a capture to see if there are any abnormal spikes around the same time the glitch happens. It's in ControlPanel->"Administrative Tools" .. You can log %Interrupt Time, Interrupts/sec, Context switches, CPU time, etc....

Dan

What video card do you have?

[Adam Gold]

Those are all good ideas. I'll try to figure out how to make them work. As I noted earlier, this has happened with both the integrated FW and a separate card I bought and put in my one remaining slot.

Certainly possible it's the RAID card; maybe I could remove and then use mobo RAID control -- wondering if this would mean wiping out RAID data already stored. If so, not an option.

Forgot to mention that this has happened with two video cards as well -- NVidia Quadro FX 1500 before, and now ATI Radeon 4350.

As the glitch isn't visible during capture, only after when you scrub through the file, watching the performance monitor for an hour and writing down any suspicious activity and then checking the captured file will present a challenge -- but it's certainly a good idea.

Thanks for the help.

As it's clear I was barking up the wrong tree by posting in the Cineform forum, I've started a new thread here:

http://www.dvinfo.net/conf/high-defi...s-capture.html

Sorry to effectively double/cross-post -- I hate people who do that -- but I wanted to try to get this in front of a larger audience who might not check out th Cineform forum regularly.