Bug Report (1618): Timecode Source Change

jabadgerjabadger Registered User, Hog Beta
edited May 2007 in v2.1.0
Name: Badger
Date: 4/16/07
Software Version and build number: 2.1.0 (1618)
Number of displays: 0
Connected USB Devices: 0
Networked Devices: RCU, 1DP, 1IOP

When changing the timecode source in a cuelist from local (Console) to an IOP, the change sometimes will delay, taking up to a minute sometimes to effectively change over to the new source OR not at all requiring a reboot. Wildly unpredictable.

Comments

  • jabadgerjabadger Registered User, Hog Beta
    edited April 2007
    Somewhat related to this - When making anysort of source change or Enable Disable Change - the cuelist behaves erratically.

    Case in point; I try to use ET/DT comment macro triggers whenever possible in maintaining my show. I have found that in this build whenever I invoke an ET trigger sometimes the cuelist will respond right away, but usually not (especially if the show has been on for a long time - 12hrs+).

    In one instance, timecode was running all night, like it does, but the list on the console was Disabled. In the morning I started up my show start list and it performed an ET command on the list, which it took but, the list did not execute any cues. I verified that the console was receiving timecode by opening up a timecode window temporarily. I just left the console alone thinking that it would eventually enable as I had seen this condition before. It did enable but once it did it was in an extreme studdering mode that was affecting the ENTIRE facility. A cue or several cues would execute on the timecode list and then pause then try and "catch up" by executing several cues again in succession. This "infected" other cuelists (not running to timecode) by making them skip and catch up in cues too.

    I would guess that the IOP is getting me down on this one - sounds like something it would do to me, because it hates me - especially after all we've been through.

    I removed the DT/ET triggers from the start up and just let the list remain active the whole time, which as it turns out, will be okay for this show because audio mutes timecode once we go into night mode, allowing me to release the list.

    I can't troubleshoot this show anymore, fyi. It's a few thousand miles away from me now.
  • Akito.HAkito.H Registered User, Hog Beta
    edited May 2007
    Badger san,
    I am in the place where the trouble shoot of this show can be done.

    Akito
  • FloydFloyd Registered User
    edited May 2007
    Name: Jeremy
    Date: 05/02/2007
    Console 1 Rackmount Hog III
    Software Version and build number: 2.1.0 (1618)
    Number of displays: 2
    Connected USB Devices: 2, 1 programmer wing, 1 playback wing
    Networked Devices: 1 IOP, 2 DP2000

    Console 2 Wholehog III Console
    Software Version and build number: 2.1.0 (1618)
    Number of displays: 2
    Connected USB Devices: None
    Networked Devices: 1 IOP, 2 DP2000

    I've had a similar issue on both my consoles, and the problem has only started to occur after the upgrade to 2.1.0 (1618). Running my show I manually enable timecode on 2 cuelists. A larger majority of the time 1 of the 2 cuelists will not take it's cues via SMPTE. When this problem occurs the last cuelist that I enable is always the one that will take cues, and the first list enabled will not. The issue is resolved with a console reboot, however that solution only works about 30-40% of the time. I am unable to duplicate the issue on command.

    Also I've had a slightly less frequent problem of starting SMTPE in the middle of the show (for show rehersals) and the cuelist that will take cues won't start taking cues until SMPTE has been running for 30-45 seconds.

    A power cycle of the IOP doesn't resolve the issue.
Sign In or Register to comment.