If the problem is related to VTR:  

IMPORTANT NOTE: The most common cause for VTR problems are unwanted loops in the video signal. Before starting diagnostics DISCONNECT THE SDI CABLE THAT IS NOT NEEDED, that is, if you are doing a playout disconnect the input cable, and if you are doing a video capture disconnect the output cable. This will prevent sync loops, clock missmatchs, and other common  problems. In principle this can also be prevented by correct configuration of patch panels and VTR internal menus, but disconnecting unnecessary cables will radically  discard potential related  issues and making diagnostics much easier.

When entering the Mistika VTR panel no errors should appear, and the timecode that is shown in the VTR display must immediately appear in the Mistika VTR panel. Also when entering the VTR panel, the input signal (if any) must immediately appear in the reference monitor (Mistika does a loop trough while in “Capture” mode). 

As soon as you enter in the VTR panel also check these points:

- If a “Video signal is not detected” message appear, it can be one of these reasons:

 a) SDI cable not connected to an VTR

 b) The VTR is in a different video mode than mConfig->VideoIO format. Check if it matches the same video format appearing in the VTR display

If the VTR panel does not show the same timecode as in the VTR display.:

 a) If you see a 00:00:00:00 timecode in the Mistika VTR panel but a different TC in the VTR display, then the remote cable is not connected to the VTR or it is not a standard RS422 cable (a typical confusion is when reusing cables from other systems. Some systems different than Mistika use RS232 cables, that have similar connectors but are not valid for Mistika. Mistika requires an RS422 cable connected the DVS board.

 b) If you see a timecode different than 00:00:00:00 but it does not match what you see in the VTR display (you have to check it both in still mode and playback mode ), then it could be a wrong cable as in case a), but most probably it is due to a difference between the VITC and LTC of the video tape. Both of them should be identical, tapes recorded with different VITC & LTC will create problems with Mistika. Typically this situation can be detected when you press play / stop in the VTR, because it’s TC will change between LTC and VITC at that point.

- Always keep a trust-able tape and test with it. The fastest way to confirm or discard if the problem is related to a tape issue is to test the capture with a tape that you now it was working well.  

- In case of persistent problems, a system reboot is recommended before starting further diagnostics. The  following points will assume that you already tried it

Problem: When trying to capture, the VTR starts moving, but the capture never starts 

Mistika must put a “starting capture..” message in the status line, just after the VTR completes the pre-rol stage when it finds the In point.. If the “starting capture..” message never appears:

- Check that there is enough pre-roll time recorded on tape with continuous timecodes before the in point. (as specified in Mistika->vtr->setup->prerroll, typically 5sg). If the tape has timecode jumps in this area the capture may fail to start.

Problem: Capture or playout starts but it is interrupted before the out point (you will find a partial clip with only the first images, but not complete) 

- First look to the disk lights of the disk array. When Mistika starts capturing they should be showing disk activity. This will tell you if Mistika was really writing images or if the problem happened before this point. 

- Look at the status line feedback in the mistika capture panel, if you see that the number of image buffers is growing too much during a capture ( up to the limit (mConfig->Performance>RingBuffer) or if they are not growing or decreasing up to very low values during a playout to tape, (except when they are emptied on purpose at the end of the playout) then it means that there is not enough disk speed, check the disk array as follows:

 * Check if other processes are using it simultaneously, or maybe through the network (stop your activity and look to the disk array activity lights, they should not  be blinking) 

* Check fragmentation levels. If you have been working with the disk arrays almost full for a while, it is time to make space and defragment. 

* Check that the disk array is not in "a rebuild process due to a failing disk. This will reduce it’s performance temporally.

 As a temporal workaround, Increasing the RingBuffer can help to capture, specially if you split  the capture time in several segments)

- During a capture, if the buffers are all the time at high values but a capture is suddenly interrupted, it points to a problem with the video sync. Remove all SDI cables both from VTR and Mistika (including the sync/ref cable and the output cables), and only connect the HD SDI IN 1 cable coming from the VTR. Set mConfig->MasterFormat>SyncInput1 and restart Mistika.  If it works in that way, one of the cables that you have disconnected is creating the troubles. (typically a sync loop going through the output cables) or a wrong genlock signal of a different format)

Problem: The Capture or Playout works but it is not frame accurate or it repeat frames

- If a frame is repeated one or more times at the inpoint, or if the first frame is not repeated but it is not the correct frame, then check Mistika->VTR->Setup->EditLag. This value must be “5”  for most digital VTR’s. (it will vary for old analog VTR’s). 

- If you are capturing, check that the VTR is not in “sync to input” mode. During a capture, the VTR must be either creating its own sync or it must be using a genlock signal that is also connected to the Mistika system. An VTR trying to sync to its input would be trying to sync on the same signal that it is sending to the mistika system and coming back through the Mistika output, thus creating an invalid sync loop.  In the Mistika side do the opposite (put mConfig->MasterFormats>Sync to Input1 to hook on the incoming signal)  or use genlock if you have a trustable sync..

- If you are doing a playout rather than a capture, check that mConfig->VideoIO->Sync is set to genlock (if you have a genlcok cables both to VTR and Mistika ) or to “Internal”, do not set it to SyncInput1 if you pretend to playout. 

Problem: Doing Stereo 3D dual link capture or playouts, there is electronic noise appearing in the second SDI channel, or discrepancies between both SDI signals (channel-B, only apply to stereo3D systems)

- This may happen when the second link is not active. Check that you have these settings:

 mConfig->MasterFormats->VideoIOmode = Stereo3D mode

 mConfig->MasterFormats-->InternalVideoStorage = YUV422 or YUV422-10bit 

 Mistika->Visual->Editor->Stereo mode = dual link.

They are the only valid combinations for Stereo dual link capture and playouts to tape.