SMPTE Timecoded show jumping to end

Hello,

I am an issue sporatically with my Road Hog console running SMPTE 30 over LTC widget. The playback will snap to the last cue containing a timecode value. It only happens at one of two times (the show has two timecoded segments, and for the section between them another cueslist is run manually), and both of those are when timecode has just been enabled on the list. It never occurs in the middle of a timecoded segment, only when timecode starts up after a period of being stopped. This issue seems to occur most often only at least the second time the show is run after the console after booted. Also there seems to be no way to predict when it will or will not go wrong, sometimes it goes a month between occurences and sometimes it is twice in the same week.

The console is running 3.2.1 although the issue was present before that upgrade I believe. My "Jump after" setting is 60 frames to give SMPTE plenty of time to stabilize and also I have tried more than one LTC widget with no difference.

It is a nuisance because the first cue in each segment is a slow fade up and only with a couple of lights, whereas the last cue in the show is the brightest state of the whole show so essentially it blasts the whole audience with bright light and completely ruins the opening of the show because it takes a few seconds to correct it each time.

Any advice/assistance in any form would be greatly appreciated.

(posted this in another forum too but then realized this is the more appropriate location given that I am using the most recent software version)
  • 0
    This is probably less of an incoming timecode issue and more of a playback interpretation of where the cuelist should. Does the last cue the main time coded cuestack have a time code wait value? How far off from the start and stop values of the show is the final timecode stamp in your list? This is a head scratcher for sure.
  • 0
    Hi Chris,

    The basic structure is as follows:

    SMPTE comes from TASCAM DA-98 deck

    First half of the show, locate point is 4/57.00 and first cue after timecode rolls is 5/00.15, giving just enough time for timecode to lock with a jump of 60 frames.

    Last cue in the first section is at 29/01.29, and timecode stops at about 29/04.00, timecode is disabled by a macro in the last cue, then this list is released.

    Manual bit in the middle on a different cuelist and meanwhile the DA-98 decks re-locate to 33/03.00 for the start of the second half of the show. Manual cuelist, on its last cue, releases itself, triggers the appropriate cue back in the timecoded list (the cue before timecode rolls) and re-enables timecode on that list.

    Second half of the show, first timecoded cue is at 33/06.02.

    Last timecoded cue in the show is at 49/01.07.

    I don't know if it makes a difference, but I often find that once the tapes are located/stopped, the "input timecode" in the timecode bar does not match the "current timecode". The hours column usually jumps ahead several hours, last time around 8. I have a bit of a feeling that this is a root cause but I don't understand why as the console should be waiting for that first 60 frames of SMPTE before locking, and the timecode is always accurate when running, just not after being stopped.

    A head scratcher indeed.
  • 0
    From your description it sounds like your LTC playback device is not starting and stopping "cleanly".

    There is a Cuelist option for timecode "Trigger Forwards Only". If you don't have this enabled, try that....it should keep your list from jumping backwards from where you want it to be.

    Hope this helps. :)
  • 0
    Hi Marty,

    Thanks for your suggestions. This problem only started after upgrading to a Road Hog console from a Wholehog II and on the hog 2 I don't recall seeing the timecode display jump around when stopping and starting. Nonetheless I will check it out as this may be a contributing factor.

    Also I do already have Trigger Forward Only enabled but since the issue is with the cuelist jumping forward it doesn't make much difference to the situation.

    Thanks,

    Ryan
Related

www.etcconnect.com