LimeWire 4.3.2 Beta
 

Hi Folks,

The LimeWire 4.3.2 Beta is now available. PRO users can download it from their personal download page. Free users can download it from the LimeWire Beta Page.

Changes in LimeWire 4.3.2 include:
- Fixed a problem with international characters. Previously, some search results would contain 'block' characters and saving these files on some operating systems would fail. This is now fixed. Thanks goes to "heavy_baby" for pointing out the problem and proposing a fix.
- Added expanded server-side support for an upcoming new feature that will allow LimeWire to learn about more sources faster and more intelligently pick which sources to to use when downloading.
- Added a fix for some degenerate FW-FW transfers that would cause the transfer to fail. Thanks goes to Julian from BearShare for pointing out the problem and proposing a fix.
- Re-added the ability to rename files in the library. Thanks goes to FishEye for maintaining our CVS history.
- Updated the Windows installer to better handle a few situations, and LimeWire.exe to ignore a "jre" subdirectory and instead always pick the most recent Java version from the registry.

Thanks for your help in testing the betas! We're hoping to stabilize this installer & version very soon, and release it as a the production version. Then we'll continue work and release a more feature-filled version shortly afterwards.

Thanks,
The LimeWire Team

That was 3 hours before this post of yours so you weren't kidding were you! lol :D

re cc Licenses

A quick check showed all working here as expected.

Is it possible to use LW to search for only licensed material? i.e, something like the What's new? search, or a filter . . .

Yup. It won't work well right now, since not many clients understand the licensing, and it only works for Audio when it does work, but it's possible. Just do an 'Audio' search, choose 'More Options', and choose 'Creative Commons' from the 'License Type' dropdown box. You can also specify further criteria, if you want.

When will the FULL version of Limewire 4.3.2 be out?
As Im using Limewire 4.2.5 out now and dont wanna risk using a BETA.

From my experience: Neither beta never got me no problems (this is true, even though the style is a parody on some I already read (and used myself) in english :-) )

I can't recall having problems with betas except for memory issues on os x. Now, using CVS builds is an other matter, but beta builds are pretty safe. You can alway do a backup of your inomplete files folder if you fear loosing downloads.

Ciao :)

I think I started using LW betas from 4.1.4/5 but only struck an issue when I jumped back from 4.1.7 to 4.0.4 where the incompletes refused to load. Before that I had no problem interchanging b/w the 2 versions. Since then I haven't had any issues jumping between betas, most recent official release versions, & jum cvs. Thus LW is one program I have confidence with their betas (unlike betas of other softwares.)

LW betas have been really quite safe for me, but that's not the point.

Betas are betas BECAUSE they haven't been tested as much, so we SHOULD be careful.

Easy solution though: I just install betas on another admin account. If the beta wipes out the home directory, no problem: I only have files in that account that I know I might lose, and I don't worry about a beta messing the 'valuable' files I didn't get arouund to backing up ;)

btw Lime-UK: what OS are you using? Someone here has probably tested the beta on a similar one.

btw, the OS X VM problem is still here. I had to quit yesterday after it rose to 1.3 GB and the system warned that the HD was almost full.

Any more news on tracking this down? I noticed Apple updated the CHUD tools, and hoped that might have helped.

... I suppose I shouldn't have 1077 threads open too... This is with one big dl going on, some uploads and running as UP with saturday CVS version. 185 MB ram and 1.09 GB VM. Want the threads samples Sam?

I doubt the threads made much difference: I had very little transfers yesterday (1/2 GB up and down; mostly gnutella traffic as an UP)

Salut Stief! A thread isn't using much memory at all, but LW sould close the threads nonetheless. It has an impact on the computer performance at some point ... now 1138 threads open.

Ciao

salut et voilà -- and a happy new year to you.

I'll take another look at the thread count here (with whatever beta is officially released), and see if that might help spot something.

cheers

You're correct -- unless you've got a massive amount of downloads going on, there shouldn't be that many threads. (There should be around 10-25 threads if a leaf and 80-120 if an ultrapeer.)

The best way to get a sample, though, is to get the Java thread names & stack traces. To do this, open up Terminal, Console, and Process Viewer. In Process Viewer, click on 'LimeWire' and note the 'Process ID' listed at the bottom. Then, in terminal, type 'kill -QUIT <the process id>'. Stuff should then be printed out in Console. If you can copy that here (or if you want, email to me at sberlin@limepeer.com ), that'd be very helpful.

Thanks.

Since I often download very rare files, I also have very many downloads a lot of times, and when I have more than 200 downloads, computer performance really goes down, so I think it woould be a good Idea to use single threads only for downloads which are either queued or actively downloading (If that is possible).

Humm I did the command on the com.limegroup.gnutella.gui.Main (CVS build) but nothing showed in console. I tried the command on textedit, but no console log too. Here what I typed:

kill -QUIT 4330

Any help appreciated...

Here is the sample I got earlier:

LimeWire handles all inactive downloads with a single thread since LimeWire 4.1.2. Previously, every single download required it's own thread to manage itself. Active downloads, however, require a thread for management and another thread for each source. There's no way around that, just yet.

We're in the process of upgrading the network to Java 1.4 (part of what our new installer is planned to do). Once that happens, we can begin to design using what's called "non-blocking I/O" -- that means we can send & receive information asynchronously -- without having to dedicate a resource just to sending (and waiting till it was sent) & receiving (and waiting till something was received).

We had always intended to add NIO before, but the complexity of having to design for both blocking & non-blocking streams always stopped the project from being finished. Using Java 1.4, we can design strictly for NIO (not to mention use lots of other great Java 1.4 features).

kill -QUIT produces output when used on Java processes. Are you seeing excess threads with the Beta or with CVS? The two are pretty similiar right now, but have very different ways of launching (which might be contributing to problems).

Using CVS from yesterday, LW shows up as com.limegroup.gnutella.gui.Main in process viewer. I used kill -QUIT, but it only made disapeared the LW interface (the menu bar was still there). I really killed the process with the kill -KILL command.

If you're running from CVS, then yes, Process Viewer will show 'com.limegroup.gnutella.gui.Main'. The output also won't go to Console, it will go into the Terminal that you started the CVS version with.

I'd ideally like to see the Console output of running kill -QUIT on a Beta LimeWire version, not LimeWire from CVS. Getting the output from CVS is not the same thing.

I guess I'll have to dl the beta version then :(

et voila -- Did you see the many threads you mentioned earlier while running the CVS version? We like people running from CVS, but it occasionally can be unstable, and we can't control how it runs or what it produces. Information about CVS is best sent to the core or gui dev mailing lists at limewire.org. These forums are best for information about the released betas. We not only change code when releasing, we change our packaging procedures and installers and launchers. When we ask people to test betas, we're looking for the full experience of using LimeWire, which unfortunately does include downloading, installing, and running the installed version.

(oh -- and congratulations to me on my 1000th post as a registered user. :) )

My server is always running a CVS version (because I compile LW to not upload to leech clients). I'll installl the beta onto it and will dl a big popular movie while running UP, I'm sure the problem will pop up ;)

This thread leak problem makes me remember a discussion about the OS X Aqua interface loosing threads with progress bars. Would it be feasible to test this by replacing all progress bars with a simple textual percentage and see if the problem goes away?

There's only one thread with progress bars, the Event Thread (otherwise known as the Swing thread). Not really possible to change that one.

No not that one. I did read in the java dev list that the swing progress bar component does spawn it's own threads for the animation and sometimes does forget to clean up this extra background thread. I thought if one could replace all progress bar components with a simple text label one that only display the percentage text one could check if the progress bar component is the culprit of the memory problem.

Ohhhh --- Yeah, it's definitely possible to do that.

There's only four progressbars that are used anywhere, though. The first is in the splash screen, the second is in the status bar while LimeWire is visible but still loading the core, the third is all uploads/downloads (they use a single JProgressBar) and the fourth is for the progress of search results (they also all use a single JProgressBar).

You can find the first two in com/limegroup/gnutella/gui/StatusComponent. The one in tables is in com/limegroup/gnutella/gui/tables/ProgressBarRenderer. The one for the search results is in the 'macosx' directory of gui, further in com/limegroup/gnutella/gui/AquaTab. (That one is easiest to change in com/limegroup/gnutella/gui/ProgTabUIFactory, though).

Downloaded two 700MB files this night, wasn't able to trigger the thread problems. Maybe a CVS problem... :)

150 threads 1GB VM... might not say a lot of things, but if it helps (yes 4.3.2 beta), here is the kill -QUIT console report.

Is it possible to request a simple "Java version x.x.x_x" display in the Statistics somewhere? I'm wondering if I need to always uninstall the previous version of Sun Java (on both my Win2000 and SuSE boxes) in order to ensure that only the new version of Java is being used.
________________

Also, with LW 4.3.1-Pro-BETA (and with older 4.2.x, too) on Win2000 and JRE 1.5.0, if I had LW up (not minimized) and walked away long enough the screensaver to kick-in, when I returned the LW GUI wasn't repainting. I'd have to adjust the window size to force a redraw.

But doesn't the Bug Report give the exact version of Java being used? Or doesn't it give the exact version as in x_x?

I don't know, maybe it does. But I'm asking for a report of Java version that doesn't require any extra steps to access.

We'll probably add the Java version to the 'about' dialog. I think also a 'support information' dialog would be good -- something a bit less bulky and hard-to-get-to than the bug report, but with all the common information we need to diagnose a problem.

et voila -- looks like you were an Ultrapeer. 150 threads is pretty common for an Ultrapeer. ~64 for peers, ~60 for leaves, and then a few more for uploads, downloads, and other stuff.

Yeah it is pretty normal. It is the CVS version of saturday that got problems, I have 1919 threads open right now by LW! However kill -QUIT doesn't work on it. Anyway, merci for your time Sam.

kill -QUIT will work on a CVS version. The output is printed to the terminal that you started LimeWire with, not the console.

If you're consistently seeing this with CVS, that's a problem also.

Pro Edition beta?
 

Hello guys, i have a question:
where can i download the pro beta?
What is the "personal download page" and where can i find it?

thanx for infos...SpAwn oF Da T.D.F.

PRO users are told the address of a page where they can download their PRO version. That is their "personal download page". At the bottom of that page is a link to PRO betas.

XP Installation Problem
 

I am running XP with SP2 on lots of good hardware. I downloaded 4.3.2 and ran the install as my first. Java went fine and then got a screen saying "finishing install" but there was another screen showing a file called something 200. Everything stalled there and multiple attempts at multiple solutions have not worked. Results are Outlook ceased to work and LimeWire not installed. Installed free version and Outlook is working better but not great. Locks up occasionally now. LM seems fine although slow. I use Norton Corporate antivirus, Spybot and Spyware Blaster. Spybot reported multiple registry changes which I approved. Re-attempts at the beta result in no change other than Outlook fails and no LM. Any ideas?

Thanks.

What you're seeing at the end is the program "unpack200" unpacking LimeWire's jar files. We build the installer with highly compressed files that allow the installer size to be a half of what it used to be. Unpack200 is somewhat resource and CPU intensive, so it may appear as if things have stalled while it is unpacking the files.

If you go to the directory C:\Program Files\LimeWire while LimeWire is installing, you'll see it initially places a bunch of "<name>.jar.gz" files, and during the "Finishing installation" phase, these get erased and turned into "<name>.jar" files.

Does the installer stall for you after all the files have been converted from .gz to .jar, or during that process? Also, does the progressbar in the 'Finishing Installation' ever move forward?

We'd like to solve any problems with the new installer. Thanks very much for letting us know about this. Any help you can give would be great.

I am currently running a modified LimeWire from CVS that uses the basic UI for the progress bars (quite ugly) and I will see if the memory stays constant. With my current downloads.dat I always have seen the memory grow without bounds. I will report what happens.

Well, I did let it run for a while and it still grows. So this guess was false.

Thanks for trying, Jens. Any other ideas?

Well, I am at a loss at the moment.

Maybe this here can help:
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZ
6850 java 1.8% 37:42.59 39 886 358 204M+ 6.71M 195M+ 806M
6839 Acquisitio 6.1% 54:44.87 8 135 318 10.9M 18.7M 18.5M 213

(Yes, I use Acquisition, it is still the most usable program out there, but LimeWire is the one, here I do support - I gave up supporting Acq, because the Programmer doesn't open up his own code and doesn't have that nice a character).

111 inactive downloads and 3 connections.

Isn't there a problem in your custom settings of the JVM for your Mac: it seems that the standard Java garbage collector thread is not running on your host. It may be caused by some tweaks for MacOSX, that are there to preload some Java components and keep them indefinitely in memory, notably the precompiled native code. I'm not an expert at MacOSX tweaking options.

Keeping the native code compiled from classes is interesting only to accelerate parts of the MacOSX GUI (which is based on Java too, and uses a single shared VM for all Java apps, including the desktop interface).

I have been told that some IRC/chat applications for MacOSX do not free up their GUI resources, and cause leakage of resources. May be all these megabytes are not allocated by Limewire itself.

I suggest you try listing the running threads in the main JavaVM. It's possible that the garbage collector is disabled, so Java never frees memory used by dead/unreferenced objects. The Java VM on Mac may contain various platform-specific switches or options to control in which mode the GC runs. One of this mode for example is to not perform incremental garbage collection, but only collection when memory is effectively exhausted. Other options control the maximum memory the VM is allowed to allocate: as long as this threshold is not reached, the GC will not run.

Note that Limewire does not invoke itself the GC to force it to operate. In addition, some VM invokation flags may be incorrectly set in the Acquisition program, or it has a bug that locks the GC indefinitely. So this may be a bug of Acquisition itself. Do you have the same experience with the genuine Limewire for MacOSX?

But it's true that LimeWire's core could be further optimized to reduce the number of temporary it allocates, or to reuse them as much as possible instead of discarding them and reallocating them later (notably the many temporary String or bytes-array instances, created when parsing incoming messages, where this parsing could share the same storage instead of copying temporary fragments). This is lot of code to change in the core, to allow in-place parsing of messages. But it could be progressively improved.

Profiling classes allocating the most important number of objects or Strings or arrays would reveal the most interesting optimization. the JDK includes such a tool that allows tracing all the stack traces where allocation is performed, and the status (active/dead) of these instance. If one trace shows more than 99% of dead objects for a huge total of memory, this is certainly the first class to consider for optimization. Saving a few bytes per class will not be as much useful as true profiling.

My custom settings are in fact quite standard, as recommended by Apple in their documentation. I do not turn off the garbage collector or other strange things, and I do use the standard executable stub to execute the java program (the java or javaw frontend on other platforms).

The shared code preloading mechanism is there, but it is only for the system classes as it is done at system boot, for all the other code the system does the same as on other platforms, namely dynamically compiling code. Indeed the caching of compiled system code appears to be popular lately, Sun did introduce in Java 1.5 the changes Apple did develop.

You are misinformed here, the OS X Gui is not based on Java, it is based on Obejctive C, which is a variant of C with some Smalltalkish extensions for dynamic dispatching and the like.

Also OS X does not use a shared VM for all the system, it starts as on other systems each Java program in it's own process. If the user does not explicetely start a Java program, no VM runs by default.

This means the only thing that is loosing memory in the process is LimeWire. The problem can be in the LimeWire code itself, in the JVM, or in the Swing implementation Apple did for it's Aqua GUI.

As I use the standard stub (the same that LimeWire uses), I do have any special code that would turn off garbage collection or other such ilk. Aquisition is quite different as it is a standalone application that uses a JVM with the LimeWire Java code as subroutine library. This is an entirely different kettle of fish.

I did already already do profiling and listing threads, and the threads do not appear to be special in any way. The memory usage was always enormous, an most of the massive amounts of memory in use did point to the LimeWire connection code. the part responsible for interpreting and processing Gnutella messages.

The problem with this is that it depends on the type of files you search or have incomplete and the clould of the network your are connected to. For example the exact same setup that did grow a few days ago does not grow the last two days.

Unfortunately my OS X machine is a bit slow and underpowered memory wise to do any extensive profiling. I do normaly do my development using Eclipse on a better equipped Windows XP box, but I always run LimeWire on the OS X box.