<p>Go into your capture settings and first try non VTR controllable device and if that does not work, there is a check box I believe for warn if there is dropped frames uncheck that, there may be another for stop capture if there is dropped frames, uncheck this as well</p>

CC BY-SA 3.0
2012-10-10T22:34:02.047Z
2012-10-10T22:34:02.047Z
Chris James Champeau
<p>Are you sure that there is not a problem with the actual recorded timecode?  Under certain situations (such as two clips with a blank spot between them on the tape) the timecode can get screwed up.  My guess is that this is what is happening.  It is weird that you would end up with a problem with the final output as a result of this though.  I've normally only seen problems related to not being able to relog the same clip later.</p>

<p>Either way, your timecode on an output should come from the timeline, not the source clip, so it would either produce an issue for everyone watching your final video or it would produce no issue for anyone.  If you have only gotten one report of an issue, then it is not related to the capture problem in any way that I can see being feasible.</p>

CC BY-SA 3.0
2013-04-09T13:24:53.077Z
2013-04-09T13:24:53.077Z
AJ Henderson
<p>I'm having an issue capturing video on our Final Cut Pro (version 6.0.6) edit system when pulling in video from our MiniDV tape deck (via Firewire, linked via an Ethernet "extender"). We seem to get a few different timecode errors. We had normally captured video using Log and Capture, setting <em>in</em> and <em>out</em> points and then clicking Capture <strong>Clip</strong>, but a few weeks back that resulted in getting an error (I believe that there was not sufficient pre/post-roll space, even though there surely was) and the tape being reset to about <code>00:02:00</code> (2 minutes) in the deck, regardless of set positions. </p>

<p>Our workaround to this situation was to revert to "Capture <strong>Now</strong>" from the Log and Capture window. We line up near our starting point, click <em>Play</em> and then hit Capture Now. This has seemed to worked decently (other than you have to monitor to the clip to see when it's over and hit <code>&lt;Escape&gt;</code> to back out), but it does, nearly all the time display this error message:</p>

<p><img src="https://i.sstatic.net/YAt0C.png" alt="enter image description here"></p>

<p>This hasn't normally caused much in the way of issues (all of our videos are pretty much a single weather forecast clip with a pre-recorded open and close that we put together and then render as a final video), though I have at least one report of a clip "jumping" at some point that might be related.</p>

<p>Also, we <em>must</em> hit play before hitting Capture Now or else we get the following screen, which never results in anything productive:</p>

<p><img src="https://i.sstatic.net/FT2BW.png" alt="enter image description here"></p>

<p>It certainly appears that there's some sort of timecode errors going on somewhere, but I have no idea how to go about fixing these. In case it's necessary, the tape deck is a <strong>Panasonic AG-DV2000P</strong> that we purchased earlier this year. Any thoughts on a potential solution to our timecode woes?</p>

<final-cut-pro><timecode>
Resolving timecode errors when capturing in FCP from MiniDV tape deck
Devin
# Resolving timecode errors when capturing in FCP from MiniDV tape deck

(Asked by: username_0 on 2012-10-08)

I'm having an issue capturing video on our Final Cut Pro (version 6.0.6) edit system when pulling in video from our MiniDV tape deck (via Firewire, linked via an Ethernet "extender"). We seem to get a few different timecode errors. We had normally captured video using Log and Capture, setting *in* and *out* points and then clicking Capture **Clip**, but a few weeks back that resulted in getting an error (I believe that there was not sufficient pre/post-roll space, even though there surely was) and the tape being reset to about `00:02:00` (2 minutes) in the deck, regardless of set positions.

Our workaround to this situation was to revert to "Capture **Now**" from the Log and Capture window. We line up near our starting point, click *Play* and then hit Capture Now. This has seemed to worked decently (other than you have to monitor to the clip to see when it's over and hit  to back out), but it does, nearly all the time display this error message:

![enter image description here](https://i.sstatic.net/YAt0C.png)

This hasn't normally caused much in the way of issues (all of our videos are pretty much a single weather forecast clip with a pre-recorded open and close that we put together and then render as a final video), though I have at least one report of a clip "jumping" at some point that might be related.

Also, we *must* hit play before hitting Capture Now or else we get the following screen, which never results in anything productive:

![enter image description here](https://i.sstatic.net/FT2BW.png)

It certainly appears that there's some sort of timecode errors going on somewhere, but I have no idea how to go about fixing these. In case it's necessary, the tape deck is a **Panasonic AG-DV2000P** that we purchased earlier this year. Any thoughts on a potential solution to our timecode woes?

**Tags:** final-cut-pro, timecode


---

## 2 answers

### Answer by username_1 on 2012-10-10. Score: 1

Go into your capture settings and first try non VTR controllable device and if that does not work, there is a check box I believe for warn if there is dropped frames uncheck that, there may be another for stop capture if there is dropped frames, uncheck this as well


---

### Answer by username_2 on 2013-04-09. Score: 1

Are you sure that there is not a problem with the actual recorded timecode? Under certain situations (such as two clips with a blank spot between them on the tape) the timecode can get screwed up. My guess is that this is what is happening. It is weird that you would end up with a problem with the final output as a result of this though. I've normally only seen problems related to not being able to relog the same clip later.

Either way, your timecode on an output should come from the timeline, not the source clip, so it would either produce an issue for everyone watching your final video or it would produce no issue for anyone. If you have only gotten one report of an issue, then it is not related to the capture problem in any way that I can see being feasible.


---

