can't locate local ip and startup delay

[I][note from moderator -- the topic of this thread shifts below to a discussion of slow startup times for DirectRT v2010 when launched from within MediaLab][/I]

I am running a csv file (dot-probe task) in direct rt (Version 2006.2.0.28) via media lab (Version 2006.2.39). The task will freeze up (light purple screen, no error messages). It most frequently freezes at the start of the task, but often also freezes midway through the task. When this happens, sometimes a data file with partial or no data is exported, but sometimes no data file is exported at all. The files are stored on a network drive, however both media lab and direct rt are saved onto the computers directly. The problem that we are having happens on all machines running the program and we have re-installed direct rt and media lab on all machines. We use media lab for other tasks and questionnaire batteries, and it only regularly freezes when we run a direct rt csv file through it. Any thoughts?

Check this out and see if it helps:

[URL]http://empirisoft.com/Support/showthread.php?t=1795[/URL]

Sometimes when a file within the current experiment's directory is being accessed by another program, MediaLab and DirectRT will not be able to run properly.
Hopefully this solves the problem.

any tips on how I would figure out if another program is interfering? I don't believe I would be able to open the data folder while MediaLab and DirectRT are running (as is suggested here: [URL]http://empirisoft.com/Support/showthread.php?t=1795[/URL]). They take up the whole screen. Is there a way to minimize the programs while the task is running so I can access the data folder?

Hm - this is possible in MediaLab; however not in DirectRT. If you're in MediaLab, simply run the input file without the main window maximized before hand.

The best way to solve this problem is to simply troubleshoot any possible programs that might be interrupting the flow of DirectRT or MediaLab.

Hello,

I'm using windows 7, media lab 2008.1 and direct rt2010. Media lab seems to be working fine until it has to transfer to direct rt and then all I see is a blank purple screen (no continue button). Direct rt never shows up. This is happening with several of my experiments which use direct rt within media lab questionnaires.

I am having a very similar problem with an experiment that one of our labs is trying to run.

Windows 7 running Medialab 2008 w/ DirectRT 2010. When MediaLab starts up executeDRT.exe ... the system hangs at the white/purple-ish screen for about 50 seconds before executeDRT.exe seems to finally pull up the experiment. We can then run the experiment without any problem. Is there anything that can be done to prevent this delay? I can't figure out what is causing it.

that's interesting that it moves forward after a few seconds. Mine doesn't seem to be moving forward at all. I waited for 2 minutes. The strange thing is we were running this experiment fine on Windows XP but we got new computers with Windows 7 and now it keeps getting stuck when it's supposed to transition to direct rt.

Does anyone have a suggestion as to what is happening?

What version(s) of DirectRT v2010 are we talking about here? If its a beta version, I would suggest uninstalling it and installing the current version from the main download webpage ([URL="http://www.empirisoft.com/download.aspx"]www.empirisoft.com/download.aspx[/URL]).

How can I find out which version it is? I clicked on the about direct rt tab and it said "Version 2010: 38.824.9F".

That's a beta version. It should (at this date, Dec 2, 2010) read 2010.2.x.x in order to indicate that it's a final "official" release of v2010. I would suggest uninstalling and downloading the current non-beta version from [URL="http://www.empirisoft.com/download.aspx"]www.empirisoft.com/download.aspx[/URL].

If you run the "Voice Response" setup utility from the DirectRT v2010's [I]Tools[/I] menu--do you see a microphone input listed there? We've discovered on the machines here that if a valid sound input device is not listed then it creates a lengthy delay when DirectRT starts to run an input file. Try to use the utility to see if it can capture your test voice response times. When I selected a valid microphone input and saved the settings, DirectRT started up very quickly once again. Would be curious to know if anyone else finds this as we look for a better solution. This assumes that the delay in DirectRT happens regardless of whether it's run from within MediaLab or on its own.

Occasionally, DirectRt says it "can't locate local ip" for authorization on startup, but I can't reliably reproduce this. This error has caused me some serious problems because it also occurs when Medialab (v2010) switches to a DirectRT (2010.2.103.1115) portion of an experiment (WinXP).

Do you have any hint what might be causing this? The network connection seems to be fine.

I also noticed that in DirectRT 2010, there is a varying delay when starting DirectRt from within Medialab (about 1 to 5 seconds, sometimes longer). What has been particularly problematic is that if the participant makes a mouse click within this time frame, the purple medialab window will stay in the foreground and directrt will run invisibly in the background. Even a doubleclick on the continue button in medialab can cause this behavior. Unfortunately, the microphone setting didn't help.
(Win Xp/Windows7, Medialab 2010.2.19 , DirectRT 2010.2.103.1115)

In going through the code for the new 2010 DirectRT v2010.2.103.1115, I've noticed a potential cause for a delay *if* IP licensing is being used. It's going to to the internet to compare and validate the IP rather than simply getting the value from Windows. It was a security measure but I expect it could add a variable delay to the startup of a DirectRT session because the IP check is run any time a session is run. Are the delays mentioned in the posts above tending to be happening on machines with IP licenses? If so, why don't we try a manual (i.e., m10... ) license on one of them and see if that resolves it. If so, then we'll fix the IP coding so that it will not slow down the start of any given session.