Panda hangs on startup if Internet connection active

Good morning/afternoon/evening/midnight! :stuck_out_tongue:

I have been developing a Panda3D/Python app on a standalone machine for quite some time. The other day I connected it to the Internet, and got a shock when my app hung for up to a minute on startup before displaying the GUI. I checked my code for recent bugs, but it was absolutely perfect in every way . Finally I realized the Ethernet cable was still in, and removed it. The app launched in seconds, as before.

OS: WIndows XP
Panda3D: 1.6.2 [EDIT: also 1.7.0]

Command line output:

DirectStart: Starting the game.
Known pipe types:
(all display modules loaded.)
[hangs here]

Any help here would be appreciated. Thanks!

Hmm, if you’re not using the p3d system–and you’re not, since you’re just running “python”–then I know of know reason Panda would be attempting to contact anything on the internet at startup. Certainly there’s nothing built into Panda that does this automatically.

How about pview? Does the same thing happen there?


I know nothing about pview, but running “pview” with no arguments works… It has the same problem, though. The console window opens and the lines from my last post are printed, then it hangs for 23 seconds before showing a Panda screen with a little triangle.

When I pull the Ethernet cable (there is no wifi whatsoever within range btw, and the adapter is off), running “pview” opens the console window, immediately followed by the Panda screen with the triangle.

Ah, I have an idea what this is. I bet it’s trying to contact a pstats server. Check your Config.prc file, you probably have “want-pstats 1” and/or “pstats-host” configured on. Comment it out with a hash mark, or remove these lines altogether.


My config.prc contains just one mention to pstats, and it is disabled:

want-pstats            #f

That being said, I did have that enabled at one point, so maybe the problem is closely related. Thanks for spending brain time on this :slight_smile:

From Python, run the command:

print ConfigVariableBool('want-pstats')

It will tell you all the places this variable is defined. Maybe you’re loading another prc file you’re not aware of.


Sorry it doesn’t seem to work, and I don’t see any useful suggestions about how to use ConfigVariableBool on Google…

Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> print ConfigVariableBool('want-pstats')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'ConfigVariableBool' is not defined

Sorry, try importing it from PandaModules first:

from pandac.PandaModules import *


Done. Here is the output:

Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from pandac.PandaModules import *
>>> print ConfigVariableBool('want-pstats')
ConfigVariable want-pstats:
  want-pstats #f  (from /c/Panda3D-1.6.2/etc/Config.prc)


And here is the contents of that Config.prc (with comment lines removed):

load-display pandadx8

win-origin 50 50
win-size 800 600

fullscreen #f

framebuffer-hardware #t
framebuffer-software #f

depth-bits 1
color-bits 1
alpha-bits 0
stencil-bits 0
multisamples 0

notify-level warning
default-directnotify-level warning

model-path    $MAIN_DIR
model-path    $THIS_PRC_DIR/..
model-path    $THIS_PRC_DIR/../models
model-path    C:/Workspace/.../Application/graphics

want-directtools  #f
want-tk           #f

want-pstats            #f
show-frame-rate-meter  #f

audio-library-name p3fmod_audio

use-movietexture #t

hardware-animated-vertices #f

model-cache-dir $THIS_PRC_DIR/../modelcache
model-cache-textures #f

basic-shaders-only #t


Hmm, so I guess it’s not pstats after all.

Could it be something weird in your graphics driver? What happens if you replace “load-display pandadx8” with “load-display tinydisplay”?


Well well, that works! What could be wrong with pandadx8? And are there any downsides to using tinydisplay permanently?

Also, I had previously tried using pandadx9 and pandagl one at a time, but both made startup horribly slow. Any thoughts?

Thanks in the meantime! :slight_smile:

UPDATE: I seem to have found the lost time by looking through the spam-level log output. Kindly observe the last line in the following segment of output:

:display(debug): DisplayRegion::do_compute_pixels(800, 600)
:display(debug): DisplayRegion::do_compute_pixels(800, 600)
:display(debug): Creating new window window1
:display(debug): Created wdxGraphicsWindow8 016CA22C
:display(debug): Windows resorted: window1(0) window1(0)
:task(debug): AsyncTaskManager TaskManager task chain loader; 0 tasks: set_num_threads(1)
:display:wdxdisplay8: D3D8.1 Adapter[0]: Mobile Intel(R) 4 Series Express Chipset Family, Driver: igxprd32.dll, DriverVersion: (
VendorID: 0x00008086 DeviceID: 0x00002A42 SubsysID: 0x30DB103C Revision: 0x00000007
:display:wdxdisplay8(debug): _wcontext._window is 00000000
:express:clock(debug): Clock error detected; elapsed time 12.8724s on high-resolution counter, and 22.8434s on time-of-day clock.

Interesting, no? :slight_smile:

Well, that suggests that it’s something in your graphics driver, not Panda3D itself. Maybe the graphics driver is trying to contact its host to look for updates or something freaky? I’ve never heard of graphics drivers that attempt to make an internet connection at startup, though. Might be worth checking for a newer version of your graphics driver from or or or whoever provides your card.

You could continue to use tinydisplay, of course, but visual quality and performance will suffer.

What do you mean “horribly slow” for pandadx9 and pandagl? More than seconds? Could it be the same issue?

Hmm, that’s interesting, though I’m not sure if it’s related to the problem. You shouldn’t be seeing this kind of message unless “paranoid-clock” is set on in some config.prc file. I don’t see it mentioned above, though. Could it be set somewhere else? What do you get for “print ConfigVariableBool(‘paranoid-clock’)”?


Hi again David,

Err I just tried it again, and it seems to have gotten much better. pandagl is instantaneous, and pandadx9 takes ten seconds. Seems doubtful now whether it’s related to the main issue.

EDIT: So to summarize, pandagl/tinydisplay work well, pandadx9 takes 10 seconds, and pandadx8 takes 23 seconds. These numbers are all for when the Internet is connected. END EDIT

Cool-sounding idea. Two copy/pastes later:

Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from pandac.PandaModules import *
>>> print ConfigVariableBool('paranoid-clock')
ConfigVariable paranoid-clock:
  paranoid-clock 1  (from /c/Panda3D-1.6.2/etc/Confauto.prc)
  paranoid-clock 0  (default value)

Here is the relevant section of Confauto.prc:

# The following two lines are a fix for flaky hardware clocks.

lock-to-one-cpu #t
paranoid-clock 1

I changed the value of paranoid-clock to 0, #f, and finally commented out the whole line, but with no luck. Note that I ran it using pandadx8.


Right, removing the paranoid-clock line would remove that error message from your output (and remove the corresponding clock fix-up that happens internally), but probably that wasn’t related to your lockup. Although the fact that it does produce an error message is interesting, and means your clock is doing something wonky there.

I wonder if (with paranoid-clock back in) you would still get that clock error message when running with tinydisplay? If you don’t, it does suggest that something in your graphics driver is doing something funny not only with the network, but with the clock, which would be weird.


With paranoic-clock on and tinydisplay loaded, there are no messages from the clock whatsoever, and definitely nothing about a clock error.

tgif [for posterity: I edited this on a Fri, k? :stuck_out_tongue:]