For some strange reasons, that I'm looking for since several months, this occurs due to an internal exception when building QRP tables. The QRP table is dropped or marked incomplete by the recipient.

Another bug is caused the first time a Shareaza node enters to a LimeWire UltraPeer with its 1MBit table (apparently there's a transient problem that causes its table not being resized before computing the intra-QRP table, and there are attempt to patch bits after the last one 65535 in the resized table.) This bug is more common, but may affect the intra QRP table that your should have received.

In your case, Et Voilà, this is probably what happens: this is a connection from UltraPeer to UltraPeer, which should join its Leaf-to-UP tables and a map of its local shared library to create a merged QRP table. If this exception occurs, the QRP table becomes resized despite is is still not complete and new patches are received from a Shareaza node connecting to the remote LimeWire.

This bug is more frequent, but I really can't understand why this can happen, given the code we have. My modified version of LimeWire detects it (attempt to patch bits number 65535..65599 in a 65536-bits QRP table), but I have still not found a reason for why such exception occurs.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

I have been running 3.9.9 since I downloaded it a day or two agao. Earlier his evening, I had to reboot, and when my system came up again, 3.9.9 couldn't reconnect. Kept twitching at Quality: Poor for a couple minutes before giving up. Connections window showed only two or three connections which eventually died. I dropped back to 3.9.2 which reconnected quickly. Relaunched 3.9.9 but still no luck. Something broke after 3.9.3 but I can't tell what.

I encountered this a couple times already with 3.9.7 and 3.9.8 but dropping back to an earlier version than returning to latest beta fixed things. This time it didn't.

Did you enable "Locale Preferencing" for connections? And set it to a too high threshold in the "Advanced" options?

This new feature will not work appropriately (for now) with other locales than English, French and German, due to an insufficient installed base of users showing this locale.

Things will go better once 4.0 will be released and more largely deployed. But for now, if you have difficulties to connect with Locale Preferencing and your locale is Dutch/Nederlands, disable this option, or set it to a lower number of connections.

Locale preferencing works great for French with 2 connections set with preferencing, but for other locales it may be useful to set this threshold to a lower value.

This feature works by looking for LimeWire agents that share the same locale as you (using a "X-Locale: lc" connection header where lc is the language code.

Don't set this value too high, notably if you're running in Leaf mode; may be this option will be off by default in 4.0 for other locales than English (en) and French (fr), and may be German (de) or Spanish (es). The Locale indicator is already sent by all 3.9.x versions, even if they disable connection preferencing. This will allow setting workable thresholds later. For now it's best to be careful and not use this feature too high.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

Thanks for the reply. Local preferencing was indeed enabled with the default 3. I disabled it but I was still unable to reconnect using 3.9.9.

I solved the problem this morning by deleting the file limeware.props in the .limeware directory. Some setting in it was screwing things up (although it didn't seem to effect 3.9.2, only the latest betas).

Did you keep a copy of your previous "limewire.props" file?

We could see what is needed for upgrades, or if this was caused by some weird properties which were used in a intermediate beta but not supported now (it may be important to facilitate upgrades from released versions)

What I suppose is that this may be a setting related to firewalls/NAT routers (the advanced "force IP" option no longer accepts manual input of the IP address, as LimeWire will determine now the public IP in echoes from the network with a new callback option).

Or it may be special settings used only for debugging/testing purpose. Some settings are normally only used within the automated tests project, to simulate Internet connections through local hosts only. They are not meant to be used in normal installations.

Thanks for pointing that some previous settings may not work as expected in the new version.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

For your information, you should know that LimeWire integrates now a "Revert to Defaults" button in the options panel. This should help in case your custom settings get garbled and don't work. Click it and apply.

However if you have a firewall with NAT routing, you'll need to reconfigure the port number set in its port-forwarding rule, and add agains your custom shared folders, meaning that all shared files out of the default folder will be rehashed and reindexed.

Limewire has been enhanced so that file hashing will work faster than before, and with less CPU used.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

Yep, tell me where to send it.

Did you keep a copy of your previous "limewire.props" file?
Why not to the bugs report address?.
If there's nothing secret in it, you may also copy/paste it here... This is a plain-text file.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

#LimeWire Properties IO Test
#LimeWire properties file
#Sun May 09 11:58:05 EST 2004
WINDOW_Y=212
BANNED_WORDS=.wma;.rm;.m4a
PORT=6348
WINDOW_X=220
CLEAR_UPLOAD=false
INSTALLED=true
USE_LOCALE_PREF=false
EXTENSIONS_TO_SEARCH_FOR=mp3;jpg;ogg
AVERAGE_UPTIME=939127
TOTAL_UPTIME=939127
MAX_UPLOAD_BYTES_PER_SEC=113
BLACK_LISTED_IP_ADDRESSES=80.11.114.38;200.56.156. 47;82.169.225.112;81.67.236.34;200.52.198.135;24.2 21.226.42;193.253.178.169;89.149.185.154;81.49.209 .167;213.13.216.171;81.208.36.89;82.104.98.80;62.1 01.126.217;213.80.33.231;80.177.223.72;64.26.167.1 69;64.26.167.135;64.26.167.175;217.81.70.47;213.13 .208.115;82.197.208.59;80.145.64.23;83.154.239.236 ;80.221.70.97;82.121.39.99;81.74.102.31;24.126.4.6 3;64.170.115.159;64.170.115.159;81.193.174.156;213 .13.218.231;43.244.149.63;203.45.215.118;208.35.94 .50;69.70.238.142;69.81.93.19;207.237.42.28;212.41 .84.217;213.58.88.181;81.193.174.170;209.6.154.12; 213.58.88.58;80.108.60.239;200.142.186.71;213.58.8 8.196;213.66.98.167;81.57.241.82;69.192.144.10;65. 66.22.175;213.118.10.70;82.225.7.6;138.88.186.247; 213.23.143.249;213.84.21.47;66.27.138.153;200.119. 43.109;81.251.229.118;209.88.131.25;212.41.72.175; 81.51.50.244;82.66.184.188;201.8.6.137;200.207.190 .238;80.202.32.126;216.58.75.21;213.156.52.121;65. 6.160.211;82.48.203.78;138.231.75.148;194.183.7.22 6;213.84.141.22;200.149.26.70;24.203.59.23
COUNTRY=
FREELOADER_FILES=100
SHOW_TOTD=false
PROXY_HOST=www-cache.demon.nl
UPLOADS_PER_PERSON=1
CONNECTION_SPEED=350
LAST_EXPIRE_TIME=1083527005240
DIRECTORY_FOR_SAVING_FILES=E\:\\cb\\mp3
MAX_DOWNLOAD_BYTES_PER_SEC=213
CONNECTION_TYPE=1
EVER_SUPERNODE_CAPABLE=true
FREELOADER_ALLOWED=10
MAX_SIM_DOWNLOAD=12
DIRECTORIES_TO_SEARCH_FOR_FILES=e\:\\cb\\mp3
LAST_GWEBCACHE_FETCH_TIME=1083527017110
EVER_ACCEPTED_INCOMING=true
CLIENT_ID=621FF7AA6D0AF415FF2CE524971F0800
THEME_DIR=C\:\\JAVA142\\.limewire\\themes\\limewir ePro_theme
PLAYER_ENABLED=false
INCOMPLETE_PURGE_TIME=30
PARALLEL_SEARCH=10
PROXY_PORT=8080
CONNECTION_VIEW_ENABLED=true

Maybe the large number of black-listed IP numbers caused a problem... if you are wondering, I am sharing 4,5k files, and regularly get leachers trying to d/l +100 a time and I shut them down by adding them to the list, but maybe this isn't necessary...

Well I wonder why you blacklist those IPs. If they are dynamic IPs assigned by ISP to some users, their validatity will be shortlived before they get reassigned to another user...
It's quite uncommon to have these many IPs, but does not explain why you've got problems to connect.

But I see something interesting:
PROXY_HOST=www-cache.demon.nl
are you sure that this external proxy works as expected?
This may prevent you of performing requests to Gwebcaches, as this proxy may cache their data for too long (so that the IPs that get returned get too old).

I'm not sure you need such external proxy. The proxy settings are just there for those that absolutely require passing through a HTTP proxy to get connected to the Internet. It won't have any impact on your performance, but will just worsen your experience as GWebcache requests and replies should not be cached in proxies...

If Limewire works without proxy settings, then don't use such proxy with LimeWire... Your only interest would be to let this proxy enhance ("accelerate") your web browsing, as the web should be mostly static. But if this proxy has too long caching timeout, it will negatively impact your performance as Gwebcaches return non static data.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml