LimeWire 4.3.3 Beta

[sberlin]

The LimeWire 4.3.3 beta has been released. You can download the free version from the LimeWire download page . PRO users can download the beta from their personal download page.

LimeWire 4.3.3 include the following changes:
- Fixed widespread 'Could not move to Library' bug on Windows.
- Fixed 'Direct Connect' tab to update your IP address as it changes, as well as show that you are behind a firewall or router if LimeWire detects it.
- Added a 'Shutting Down LimeWire...' window as LimeWire closes.
- Fixed internal bugs in UPnP.
- Optimized filtering based on IP addresses. Thanks to Philippe Verdy for this optimization.
- Reduced the upload bandwidth required when downloading files via LimeWire's new "firewall to firewall" technology.
- Added the Java version to the 'About' dialog.
- Added a Creative Commons playlist when in LimeWire's shared playlists (using DAAP). Thanks to Roger Kapsi for contributing this.
- Fixed improper window sizing after changing themes or restoring from the system tray when using Java 1.5.
- Simplified firewall configuration and added UPnP configuration. This is under your Options (or Preferences on OSX), Advanced -> Firewall Config.

Barring any terrible bugs, this release will go into production on Monday.

Thanks,
The LimeWire Team

[Lord of the Rings]

this release will go into production on Monday

Does that mean the factory will be set to churn them out one by one by then?

[sberlin]

Yup.

[et voilà]

Thanks for the direct connect improvements and the firewall config. I really appreciate them! I'll stress 4.3.3 as UP this weekend.

Merci beaucoup à tous ceux qui participent au développement de LW

[stief]

Connected as an UP here (outgoing connections only), even though I'd forgotten to turn off my firewall.

LimeWire version 4.3.3 Pro
Java version 1.4.2_05 from Apple Computer, Inc.
Mac OS X v. 10.3.7 on ppc
Free/total memory: 3972384/19726336
-- listing session information --
Current thread: AWT-EventQueue-0
Active Threads: 70
Uptime: 4:28
Is Connected: true
Number of Ultrapeer -> Ultrapeer Connections: 25
Number of Ultrapeer -> Leaf Connections: 0
Number of Leaf -> Ultrapeer Connections: 0
Number of Old Connections: 0
Acting as Ultrapeer: true
Acting as Shielded Leaf: false
Number of Active Uploads: 0
Number of Queued Uploads: 0
Number of Active Managed Downloads: 0
Number of Active HTTP Downloaders: 0
Number of Waiting Downloads: 0
Received incoming this session: false
Number of Shared Files: 349
Guess Capable: true
Received Solicited UDP: true
SIMPP version: 7
Port Stable: true
FWT Capable: true
Last Reported Port: 20300
External Port: 20300
IP Pongs Received: 0

And congrats aussi on all the developments.

[sberlin]

That's normal behaviour. LimeWire doesn't expect people to be consistently changing their firewall status, and will remember whether or not you received a connection during your last run. If you did, then LimeWire has a chance of starting up as an Ultrapeer on the next run. Of course, if during that run it can't get any incoming connections, the next run won't start as an Ultrapeer.

[stief]

Thanks for the quick reply Sam

hmmm--makes sense, but why not throw up the "detected a firewall warning" then as a reminder?

(btw--I rarely change the firewall setting on the desktop computer, but the laptop firewall changes daily between work and home. I'd guess other laptop users might be in the same situation).

[et voilà]

Having a dynamic IP I've noticed two problems related to IP changes in a same session of LW:

1) On downloads, LW doesn't detect that IP have changed and shows a download speed of 0KB/s for a long time before going into "more sources need" (when there is no download mesh or a little dl mesh)
-LW should detect the IP change, time out those connections and request again download ranges from the previous uploading hosts.

2) On uploads, clients loose the source of the files they were dling
-LW should send a queryhit to those IP so they can continue dling from the new IP without them making a new search in the case the download mesh is inexistent.

Ciao

[stief]

FWIW, in 4.3.3 VM rose overnight @ 5.7 KB/second on OS X here (no searches or downloads; few uploads; running as an UP. details available).

Thread count looked OK (~150), but CPU % seems high at ~ 40-50%

[fabion]

Been running new version for about 3 hours now. No problems yet, and the new version got rid of it appearing to go into standby mood. I am just a little confused why it keeps shifting between excellent and turbocharged, and in connections I show incoming and outgoing as UP this has never happened before.
Not to bright on software sometimes. But I sure do like the way it operates. Running windowsXP MCE sp2 512MB DDR2@533Mhz 1.5MB/s connection

[et voilà]

After a 36 hours session, dling 1 gig, uploading 3 gigs and switching between UP and leaf in a same session, I see no problem on os x beside the usual VM problem. It also seems stable on the house winXP machine as a leaf Will this release be called 4.4 or 4.3.x?

Ciao

[sdsalsero]

I'm running 4.3.3 on JRE 1.5.0_01 (Update 1) on Win2000, and I'm getting significant GUI corruption. On all four pages, there's no vertical scrollbars. Nor is there any of the bottom controls. It's as if it thinks my screen is infinitely tall; this was fine on 4.3.2.

Also, with both 4.3.2 (on JRE 1.5.0) and 4.3.3 (on JRE 1.5.0_01), the window doesn't redraw correctly if I've got Monitor window open and walk away long enough for the screensaver to kick in. The contents of the windows will re-appear but all the 'permanent' part of the GUI will be blank. If I resize the overall program window-size, everything redraws correctly.
______________

Also, I've been running as an UP overnight now and I'm only connected to 26 peers and 27 leaves, but not to any other UPs. Is this correct? Most of the peers appear to be LW 4.2.6 users.

[et voilà]

sdsalsero: UP to UP connections are now called "peer connections" so its normal. When you are a leaf, the LW GUI tells that you are connected to UPs.

Sam: why basic 0.6 connections are still allowed? It seems like a waste of bandwidth when there are some Zultrax that connect to me. (leaf protocol is easy to implement, no?)

[sberlin]

Peers are UPs. I forget in which LimeWire version (and the feature history doesn't seem to have it), but the Connections tab was changed to have a few different words.

Peer describes a connection from an Ultrapeer to an Ultrapeer.
Ultrapeer describes a connection from a Leaf to an Ultrapeer.
Leaf describes a connection from an Ultrapeer to a Leaf.

This is so that we can easily spot cases where a connection was established one way, but the status of the LimeWire changes. It would be very bad, for instance, if a LimeWire had an ultrapeer connection and then became an ultrapeer itself.

Re: GUI corruption -- that's not good at all. On all tabs? That's really not good. Nothing significant changed. Were you also using Java 1.5.0_01 when running 4.3.2? What happens if you click to resize the program?

Re: screensaver. -- We'll look into that.

Re: both GUI corruption & screensaver -- Do you have the most recent video drivers for your graphics card?

[sberlin]

Basic connections shouldn't be allowed. You're still seeing some Zultrax connections? (I noticed one of those one night and quickly changed the code to stop allowing them.)