Breaking OSC to localhost

168 views
Skip to first unread message

Rich Walsh

unread,
Jun 27, 2016, 6:45:09 PM6/27/16
to ql...@googlegroups.com
Discovered this by accident – and have not done it again to check. I had a machine running with wall clock triggers, connected to a WiFi network for remote viewing. We had to delete the WiFi network as the password had escaped. The localhost OSC cues in QLab stopped working – although it took me a while to figure that out (I thought it was the triggers that had stopped firing). I had to restart the machine to fix this; connecting to the new WiFi network didn't do it (and nor did relaunching QLab).

Worth knowing?

Rich

Rich Walsh

unread,
Jul 4, 2016, 9:14:03 AM7/4/16
to ql...@googlegroups.com
This fixed one thing, but didn't actually fix the original symptom: wall-clock-triggered cues have stopped firing (some of which contain OSC, some don't)…

What level of logging do I need to record every cue that is fired? Or is it scripting time again?

Are wall clock triggers reliable? I've not used them before, and found a post from Mic that suggested similar issues back in 2012.

Rich

Chris Ashworth

unread,
Jul 4, 2016, 9:30:02 AM7/4/16
to Rich Walsh, ql...@googlegroups.com
Hi Rich,

The historic problem with wall clock triggers was that in version 2 the timing mechanism could drift from the true time due to whatever error the computer’s internal clock had relative to true time.  In version 3 the wall clock periodically adjusts itself to stay on true time.

However, I do have one ticket in my support inbox (aside from this report, which would be #2) that I believe shows there is a bug that can cause a wall clock trigger to fail. I do not have any details about when or how, as the nature of the report is a trigger that happens once a week, and I have not been able to set up conditions to reproduce it so it has languished in my queue of possible-but-fuzzy-bugs.

That’s about all I know about it at this point. You can set to log level 2 to view just when cues start (rather than all the extra detail of log level 3). That’d be a decent first step. 

-C

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab

Follow Figure 53 on Twitter: http://twitter.com/Figure53
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/62A08249-58EB-42E7-8D87-DFA44A08486C%40mac.com.
For more options, visit https://groups.google.com/d/optout.

Rich Walsh

unread,
Jul 4, 2016, 9:36:21 AM7/4/16
to Chris Ashworth, ql...@googlegroups.com
On 4 Jul 2016, at 14:29, Chris Ashworth <ch...@figure53.com> wrote:

Hi Rich,

The historic problem with wall clock triggers was that in version 2 the timing mechanism could drift from the true time due to whatever error the computer’s internal clock had relative to true time.  In version 3 the wall clock periodically adjusts itself to stay on true time.

Could that get messed up if the computer loses its Internet connection while QLab is running? I think this issue started when the Mac would have lost touch with any ntp servers. I didn't try restarting the Mac once it had been reconnected to a network (only QLab).

Do wall clock triggers have the same fundamental vulnerability as timecode triggers: if you miss the timecode for that specific frame the cue won't fire? Can you build some fuzziness in so that cues will start if they see a time reference within a second or so of their trigger and adjust accordingly?

Rich

Chris Ashworth

unread,
Jul 5, 2016, 1:31:43 PM7/5/16
to Rich Walsh, ql...@googlegroups.com
Worth checking — I’ll remind myself what’s going on there when I have a chance and let you know.

I wish I could install more RAM in my brain so I could maintain more simultaneous code-related threads in my brain simultaneously without pushing some of them to slower storage mediums!

-C

Chris Ashworth

unread,
Jul 7, 2016, 3:16:07 PM7/7/16
to Rich Walsh, ql...@googlegroups.com
Hi again Rich,

I’ve just stepped through the code again to refresh my memory, and the answer is:

1) The wall clock trigger could drift if the Mac loses connection to a network that allows it to keep updating its internal clock to the true time.

2) The wall clock trigger does not “miss” a trigger; any scheduled event that is past the scheduled time will be triggered, and it attempts to do this as quickly as possible but will always do it. Log Level 2 will show something like "wall clock trigger fired” any time the cue gets that trigger.

-C

On July 4, 2016 at 9:36:19 AM, Rich Walsh (rich...@mac.com) wrote:

Christopher Ashworth

unread,
Jul 7, 2016, 4:53:19 PM7/7/16
to Rich Walsh, ql...@googlegroups.com
Modulo any bugs, but of course I've never written code with bugs so we can count that out.

(mobile)

Rich Walsh

unread,
Jul 8, 2016, 8:19:29 PM7/8/16
to ql...@googlegroups.com
The machine has been restarted (actually, put in a box and driven up a motorway or two); now the wall clock triggers are firing again. I think I found an edge case to break it…

Rich
Reply all
Reply to author
Forward
0 new messages