I do not know what is crashing in that case (OS X, LimeWire.app, your router?), but LimeWire with Force IP enabled is supposed to survive these routing changes.

Quote:

After restarting (prefs set to not connect automatically) and curiously--while disconnected, noted CPU was just as high as when connected. (50-70%). I had no searches going, so what's using all the CPU? Uploads trying to connect? btw--CPU usage as a leaf shows~ 25% open or hidden.

Upon startup LimeWire normally does eat CPU for rescanning the library. The CPU should return to normal after the counting stops in the lower left corner.

Quote:

Took this as a chance to see if I could get et voilà's reported uploads at a steady 7k--mine usually show a steady 0k. I was watching the 3-5 uploads which started very quickly to see if they'd be steadier. They weren't: same initial burst of ~30KB/s (the initial burst doesn't show in the average reported on the Monitor pane, only in the stats) and then nothing--the uploads usually end up as "interrupted." Why should the uploads stutter? Something is breaking the connection, right? If this is not LW related, then I need to get my cablemodem replaced. (LW is sure good for testing equipment limits! )

It is definitely not supposed to stutter, and does not for example on my Mac. I have one additional idea what might induce stutter in the display: if the destination node is much slower than your connection it could be possible that your LimeWire process is sending the data quickly out to the network and the routers on the way to the destination buffer the data. As the destination node is slow it does slowly drain the routers buffers. After that your LimeWire again sends a big chunk and so on.

As far as I understand the situation TCP is supposed to fix this by adapting the window size and send fewer data. But only a network sniffer trace could reveal what is happening here and who is the culprit.

Quote:

tried trap_jaw's magnet http://www.gnutellaforums.com/showth...threadid=19732 when disconnected---didn't show in the downloads pane, so chose connect, but then LWj wouldn't hide (kept coming to the front) and wouldn't allow any other window to be foremost. Had to quit. This happened when connected directly or behind the NAT.

This is a rather unfortunate problem. The Apple Java 1.4 implementation does not support AppleEvents from Java any more as the 1.3 implementation did (the JDirect subsystem is no longer available). I have no idea yet how to do AppleEvents from Java 1.4, so if anybody has any enlighting ideas I am all ears.

Quote:

Console entries are a bit different. Under the previous LW3, console would report /Applications/LimeWire/LimeWire.app/Contents/MacOS/LimeWire: kCGErrorFailure : CGTranslateCTM is obsolete; use CGContextTranslateCTM instead The similar message in LWj3 is much more specific: /Applications/LimeWire/LimeWire.app/Contents/MacOS/LimeWire: kCGErrorFailure : *** Parser error line 1, character position 52 Is this related to my setup compatibility issue or do other OSX users see this too? Here's one I've never seen before: 2003-06-08 13:22:09.154 LimeWire[942] Warning: Font LucidaSans-TypewriterBold claims fixed-pitch with 0 max advance! So, just some notes on the little I've seen so far. Thanks again for making the CVS build available. I owe you and others--can I send you a drink? Cheers--stief

The console differences are due to the fact that all of the Java engine is different in 1.4 than it was with 1.3. I do not see these on my Mac, so I what suspect that these are dependent upon installed video card and fonts.

Do not send a drink to me - just support your local neighbourhood instead.