LimeWire 4.3.3 Beta
 

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

Yup. :)

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 :)

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

Quote:

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.

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.

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).

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

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%

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

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

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.

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?)

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?

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.)

I had some with the CVS versions after the 4.2 release and I did not see anything about that in changelogs of the 4.3 series, so I thought you didn't know ;) But now that I think of it, I've not seen them for 1-2 weeks, so I guess you blocked them right. Nice :)

Ciao

I'm not seeing the spinning lime icon any more when searching. Has it been removed?

[re the 'peer' change: it was at least in 3.9.8 http://www.gnutellaforums.com/showth...peer#post88002 ]

Shouldn't be removed... Are you seeing no logo at all, or it just isn't spinning when searching? The spinning only will happen while it still has sources to find, so if the search finishes quickly, it'll stop spinning.

Oh wow, you're right, there's no logo. Odd. That'll be fixed.

Good catch Stief! It is not there on windows and os x. I guess the spinning icon is not important after all (since nobody noticed) and it makes the GUI cleaner IMO.

re a cleaner GUI, I think I'll miss the lime, but not much. The search progress tabs make it redundant anyway.

I wondered if maybe the lime was removed to cut down on memory use ;)

Well, at least we know it's not the cause of the VM problem :D

re the VM situation--I give up. For less than 1 GB of bandwidth, the VM rose to >1.5 GB before my G3 became pretty much unusable (took ~20 minutes of thrashing before I could quit this morning--and I still lost the BigTop graph). Would have been nice to track it down before Apple updates Java.

Hmm don't know if this is normal since I'm a really new user of LimeWire, but I just came to check the machine and when I was watching the connections screen It dumped about 20 peers and all of the leafs. The window flickered 3 0r 4 times and then it stabilized. I checked the Upload screen and all the speeds went way down (30 kb/s to 2kb/s). I wasn't downloading just sharing. No other programs running except Norton Internet Security. Now everything is back to normal. I've been connected for appx. 7 hours and 38 minutes

LimeWire 4.3.3 beta freezes
 

Ugh! I am still having a problem in LimeWire 4.3.3 beta (that also occurs in LimeWire 4.2.6) where LimeWire continues to download/upload but the actual window fails to redraw or respond to any keys or mouse clicks. To continue doing anything in LimeWire, I basically have to kill it and reload it. When reloaded, it runs for a little while (half an hour to 45 minutes) then the interface stops redrawing yet again. It seems to occur most often when "Advanced Statistics" is enabled, although it has happened a few times even with that turned off. This is on a machine with SuSE 9.0 Professional using Java 1.4.2_06. I've also tried java version 1.5.0_01 and it happens with that java version also. It occurs even with no downloads active.

Since you're running on SuSe, I take it you're running LimeWire from a console. If you could do a 'ps -aux' and locate the PID of the LimeWire process, then do a kill -QUIT on that process, LimeWire will spit out a stack trace on the console it was started on. The strack trace will show what is locked and preventing the GUI from refreshing.

Ok. I did a kill -SIGQUIT on LimeWire 4.3.3 beta running in java 1.4.2_06 during a recent GUI freeze and attached the full output of that stack trace.

Whelp, looks like it's the clipboard listening on Unixes that is freezing up the GUI -- it's waiting for the system to give it the available transfer types. Thanks for that clip, limenut.

No problem! Since you said it was clipboard related, it looks like I found reproducible way to trigger this bug.

1. Open LimeWire and don't minimize it.

2. Open Firefox in Linux.

3. Highlight some text on a web page then press CTRL C.

4. Exit Firefox.

The GUI in LimeWire would immediately fail to redraw after this.

hm, could you try with the latest jre from sun? You can get it from http://java.sun.com, it is 1.5.0_01

With 1.5.0_01, it freezes, but only for half a minute, then the GUI unfreezes afterwards when repeating the same steps that freezes the GUI permanently with java 1.4.2_06.

sberlin,
Yes, it happens on all tabs.
I was running 4.3.2 on JRE 1.5.0 (not "Update 1") so it's possible the problem is with Java.
The GUI corruption doesn't start right away. I think it only happens after the screensaver has run.

Since the change-log for 4.3.3 mentions "fix for GUI" I assume that something related was broken.
____________

As for the labels used in Connections, I think it would make more sense to refer to what kind of servent you're talking to, rather than to what kind of connection you have. I mean, if you're in Leaf mode and you upgrade to a UP, what are you going to learn from your former leaf-UP connections being re-labeled "peer" connections? OTOH, if you're in UP mode and you're talking to older non-UP clients, the current labels make it impossible to know.

The labels in the connections tab refer to the type of connection it was when established. If you see an "Ultrapeer" connection as a leaf, and then somehow become promoted to an Ultrapeer, you'll see still that "Ultrapeer" connection -- that means there's a big bug. Your servent should never change status and retain its old connections. If an Ultrapeer sees an "Ultrapeer" connection, or a Leaf sees a "Peer" or "Leaf" connection, there's a large problem.

We'll look into that GUI thing, though I suspect it'll be difficult to track down. You've updated all the video drivers and there's still a problem?

I noticed almost immediatley... and I miss it! :(

A number of versions ago, the spinning Lime was replaced by the 'blinking' plug... personally I preferred the spinning Lime! ;)

LimeNut:

the problem is most likely in the version of X that you're using. The next version of Limewire will not freeze anymore, but will unfortunately not be able to download magnet links on such systems.

You should see if there are any updates available for your X environment, and potentially upgrade the entire distro (there is Suse 9.2 out afaik)

I just installed 4.3.3 on my SuSE 9.1 machine at work (which also has JRE 1.5.0_01 but a different video card and -- obviously -- different drivers) and it had the same GUI corruption.

It looked ok until I tried to download something. So I think the code to add the download sub-window must be the source of the problem.

One thing that's different, and may be a clue, is that the Linux version acted like my windowed copy of LW was actually running full-screen, even though it wasn't. In other words, if I did maximize LW, then I could see the bottom controls. Re-windowing it 'lost' them. I checked this on my Windows machine though and it's not the same; still a mystery there.

I did a net install of SuSE 9.2 onto another partition on my hard drive and the freezes also occur in SuSE 9.2 running X.org 6.8.1 (using java 1.4.2_06 that came with it).

Here is the kill -SIGQUIT output during the freeze in SuSE 9.2 with Java 1.4.2_06.

Also, here is the kill -SIGQUIT output during the 15 to 30 second freeze in java 1.5.0 in SuSE 9.2.

lime nut:

:( . There isn't much we can do about it, we haven't been able to reproduce it on our linux systems which use virtually the same setup as Suse 9.2.

The next version will not freeze anymore, unfortunately magnet links will be available only through the command line.

Nothing wrong in this dump. There's no deadlock and all threads are in normal wait state.

Probably a freeze caused in your X11 display server by another X11 application: possibly a screensaver not starting properly or wanting to grab your mouse/keyboard input focus?
Does it occur if you disable your X11 screensaver?

Also check the status of your window manager. There may be some uncaught conditions. (Look at its log). Does it occur if you switch to another window manager (Motif, twm, ...)?

Also check the status of your X11 font server. May be there are logs indicating that it fails to initialize some font properly. May be caused by a corrupted font, or a font feature not working properly. This may cause the X11 display server to wait for a reply from the X11 font server. (check the logs too). I've read that the support and integration of TrueType font servers for X11 display servers was still not finished, or that some features in OpenType fonts were particularly slow or consuming too much resource. (Try disabling the TrueType fonts: does it still occur?)

beta
 

been running beta for 2 day know i go away from computer and limewire turn i self off all the time even when it is uploading and downloading got all the upto date on java any help with this

what's up with another update? I'm surprised to have had to live with these GUI errors (which only cropped up in the transition from 4.3.2 to 4.3.3) for almost a week now.

Plus, I'm seeing lots of "Limewire 4.4.1" connections which I'm assuming are from some other person (not you guys). Is there any recourse against someone compiling their own version and distributing it as "Limewire" ?

compiled LW's show up as "@LimeWire@" with no version number.

The 4.4.1's are somewhat official (for Windows at least), being released by the 'new' method, and it's what people get when they do an official update.

Sam's been really good with the changelogs, but I've been getting my info less offically on this 4.4.1 change.

So, *shrug*, I imagine he'll let us know when he has a chance, but in the meantime--no worries :)

We just don't wanna announce the 4.4 stuff yet. Given that every other time I've posted anything (where here or in the feature history area) some site somewhere marks it as 'new release!', we're waiting till we're ready to officially announce it.

Great! And I'm glad to see I'm not the only person sitting around on a Sunday morning... :)

Another question:
I've been running LW 4.3.3-Pro with JRE 1.5.0_01 on Win2000. I've been an UP almost the whole time and I've been concerned that a lot of downloaders (from me) are stuck at 0 kb/s. Maybe 5% of the time I'll see someone downloading at normal speed (10kb/s on up). But today, for the first time, I seem to have 'dropped' from UP to leaf mode, and now I've got several people downloading at normal speed. And this has held true all morning. Is it possible there's a bug in the UP code that's interfering with uploading?

"And another thing!..."

I frequently have the situation where I've been looking for something rare, find someone who's got it (and do Browse Host successfully on them) but then lose the 'shortcut' to them when I have to restart LW or the computer. Is there some method of bookmarking computers? Maybe, is their IP memorized along with any incomplete downloads? I realize that other people have to unload LW, too, just like me. So I guess what I'd like to see is something that allows me to continue to check if they're back on-line.

Sam: I got two Zultrax 3.31 (released 19 jan 2005) basic connections in UP mode with the thursday night CVS version (basically the same as today CVS).

Here's a follow-up to my comment re UP and not sharing files. As I said before, when I dropped back to Leaf I suddenly had a full upload list *and* the uploads were working - very few people were stuck at 0 kb/s. Hours later, I was promoted again to UP and the "good" uploading has continued. But I still think there's a problem with UP. I think maybe my available files list was not distributed correctly (or something!) when I started as UP, but was distributed correctly while I was a Leaf and that all the current upload requests are based on my "Leaf info" (if that makes any sense).

wow, here i see a discussion on limewire 4.4.3 and 4.4.5 has been released. anyone aware of the modifications i mean improvements.

Sure, see: http://www.limewire.com/english/cont..._history.shtml

With the minor updates .x.x they're usually small bug fixes & perhaps the other odd thing added.

I see that you use the French version. Are there things you noted in this translation that I have not detected or forgot to correct?
What do you think about this translation itself?

I suppose you have my direct email, but you may write to the translate list, like other contributor...
Are there typically Franco-French translation that are not well suited for Canadian? Limewire may include country-specific variants for some resources (i.e. with code "fr_CA" to override some resources in the general "fr" translation I maintain).
Also, are there projects in Canada to support the Inuktikut language?