LimeWire 4.9.0 Beta
 

The LimeWire 4.9.0 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.

There are so many changes in this release; it's hard to know where to begin. I'll try listing them by the major components...

Searching:
LimeWire now recognizes more types of licenses in the search results. In addition to Creative Commons licenses, which LimeWire 4.3 added, "Weedshare" licenses and arbitrary licenses in WMA & WMV files are recognized. If you enable the 'License' column you can see if any search result had a license. You can then right-click on the item and choose to 'View License' to verify the information. As if that wasn't enough, you can now right-click on any search result and choose to 'Download As', saving the file to any arbitrary location. You can also choose to search for similiar kinds of results from a new 'Search More' submenu.

Downloading:
In a nutshell, downloads just work better. They're faster, they're smarter, and they use fewer resources. LimeWire now has vastly improved support for large files due to a highly optimized swarming algorithm. These features will continue to speed up downloads even further in the future, as more users upgrade.

Sharing:
We've gone to great lengths to make sure that you don't accidentally share files you didn't mean to. LimeWire will now detect directories that are "sensitive", prompting the user to confirm that they really do want to share them. You can also now choose to stop sharing a single file from a shared folder, or stop sharing a subdirectory of a shared folder. For users who want to share files from arbitrary locations, you can also choose to share any individual file. These files will show in a special 'Individually Shared Files' item in the library. The Library tab has also been revamped to give you more control over what you're sharing while maintaining LimeWire's famous ease-of-use .

Network Messaging:
The entire messaging architecture has been redesigned and rearchitected to use less resources and less memory. Ultrapeers should notice a significant speed and memory improvement when connected to many hosts. In the future this will allow your searches to return results faster and reach more hosts.

We've spent much of the past few months redesiging some key features in LimeWire that will allow us to add more features faster. We owe a huge thanks to the incredible LimeWire open source community. Patches have been sent in by Arne Bab, "heavy_baby", Christopher Johnson, Roger Kapsi, Ryan Keppel, Jens-Uwe Mager, Erik Meade, Chuck McNulty, Marcin Okraszewski, Eugene Romanenko, Gregorio Roper, Philippe Verdy, and Harla Yun. Countless others have recommended features or submitted bug reports.

Thanks,
The LimeWire Team


The nitty gritty on changes:
- Changed Gnutella messaging architecture to be single-threaded (using non-blocking I/O calls).
- Heavily optimized reading & writing of messaging, from TCP, UDP & Multicast.
- Removed many unnecessary threads, allowing LimeWire to use less overall resources.
- Fixed bug where save files for multiple downloaders could conflict. LimeWire will now prompt for a new save location.
- Added many 'Save Location' features for downloads. You can now choose an arbitrary save location for any download, as well as change it at any time during the download.
- LimeWire will now let you know if the file you're downloading matches any file in the library (via a hash lookup). This is in addition to the already-existing checks that prompted you about overwriting a file.
- The library now supports sharing (and not sharing) single files and folders.
- LimeWire now recognizes "sensitive" directories, asking the user whether they really want to share that directory.
- Fixed partial file sharing to only advertise ranges that are verified as valid.
- Fixed alternate locations to be shared among shared files, incomplete files, and downloads, instead of storing duplicate copies for each.
- Optimized Gnutella connections to leaves (or from leaves to Ultrapeers) to not use as much memory, since they require less flow control support.
- Optimized query throttling & QRP tables. When LimeWire becomes busy, it now sends a message telling its Ultrapeer and/or neighbors to stop sending it queries. The Ultrapeer will remove the leaf's QRP information from the combined Ultrapeer QRP tables when sending out combined tables, if the leaf was busy.
- Added many more extensions to the list of shared extensions.
- All message processing and dispatching is now done in a single thread, which will reduce resources and contention for various shared objects.
- Proxies for downloads are now saved with the download so that firewalled hosts can be reused when restarting LimeWire.
- Any host who we succesfully connected to while downloading is saved for the future use if LimeWire restarts.
- Added support for expiring alternation locations after LimeWire sends them out too many times. This ensures that older hosts who may have left the network will fall out of memory after some time.
- Updated the default list of GWebCaches.
- Major magnet upgrades. LimeWire now can handle many more magnet links, as well as automatically opening a search tab for very ambiguous magnets.
- Fixed some errors with inflating & deflating Gnutella message traffic that could have caused the connection to drop.
- Added support for randomly downloading parts of the file when doing a download. Preference is given to the beginning of the file for files that can be previewed. This will ensure that the file is spread to many hosts, removing a single point of failure, while still allowing you to preview files as they download.
- Heavily optimized the entire downloading process, giving downloads a major speed boost.
- Requesting ranges for download from a host can now be done in parallel. Previously, LimeWire would only request one part of a file per time from any given host, reducing the speed of a download to the lowest speed of any connected source.
- Added support for verifying the integrity of a download as the download is progressing. This will fix the problem where many downloads get to 99% and then restart. This will also let you know that a download is getting many corrupt bytes and kill it before it wastes all your bandwidth.
- Fixed the progress-bar in uploads to show the correct progress for swarmed uploads.
- Optimized downloading to prefer partial sources & firewalled sources first, reducing the load on hosts who have the complete file and are not firewalled.
- Fixed many problems where downloads could have disk errors, offering the user to option to download to a new location.
- Optimized downloading to do disk I/O in a different thread than network I/O.
- Heavily optimized downloads by pinging possible sources prior to connecting. LimeWire will connect to hosts who respond to the ping first, as well as learn about other potential sources and whether or not the responding host was available for uploading.
- Added entries to the library's popup menus that easily allow you to stop sharing or start sharing one of the files or folders.
- Added the ability for downloads to be saved to different locations based on the media type of the download.
- Added new 'Saved Folder' entries to the library that show the saved files in the different media type saved folders.
- Added recognition of "Weedshare" licenses. These are WMA/WMV/ASF files that are freely shareable and licensed to allow three free plays, after which you can purchase the file. You'll get a cut of the profit from any other person who purchases a file that you've shared after purchasing it. Enable the 'License' column in search results to see these kinds of files.
- Added recognition of WMA/WMV/ASF files that require license lookups prior to playing. Enable the 'License' column in search results to see these kinds of files.
- Added the ability to parse OGM, AVI, WMA, WMV, ASF and FLAC files for metadata.
- Revised the sizes for Tiger Trees at different file size depths to ensure that validating downloads uses sane block sizes.
- Disallowed a ':' character in search results on OSX.
- Fixed some leaked Sockets if LimeWire was set up to use HTTP or SOCKS proxies.
- Updated the schemas for Audio and Video searches, removing unnecessary fields and improving the order of remaining ones.
- Added the ability to stop sending bugs to LimeWire's bug server for older LimeWire versions.
- Improved the Internal Error dialog.
- Massively improved the autocompletion, using a dropdown box that allows you to choose from any possible completion. You can also delete your autocomplete history at any time, without restarting LimeWire.
- Fixed deadlock in DAAP, for streaming tunes to iTunes.
- Require Java 1.4 for using LimeWire.
- Fixed multi-line labels to expand to the largest unbreakable phrase.
- Added the ability to use installed Java Look & Feels other than LimeWire's Themes or the system Look & Feel.
- Fixed many issues with standard list editor components (lists that can be added or remove to) and allowed more keyboard actions.
- Added the ability to send magnet links of search results or files in the library to the clipboard, for pasting elsewhere.
- Added the ability to start a search for files that are similar to a search result, a file in the library, or an item in a search filter box.
- Cleaned up the Chat window.
- Cleaned up the Connections tab, changing the 'add' feature into a button that prompts for further input, and fixing many spacing issues.
- Added more information to the advanced tooltips in downloads.
- Added many more integrity checks prior to starting a download from a search result, offering the user the option to save to a new file if it is going to overwrite an existing one, as well as many more options.
- Revamped much of the library, making it more intuitive and easier to use.
- Fixed some tray icon bugs on Linux. LimeWire should now show up correctly in the system tray.
- Sped up the 'Options' dialog appearing. Inidividual options items are now lazily loaded as you click on them.
- Added the ability to choose if you want to receive upgrade notices for Major upgrades, Beta upgrades, or Service releases.
- Added tooltips to the main 'Search Types' in the Search tab.

Thanks, thanks, and thanks again.

I'm surprised how quickly the changelog was posted--very nice.

should I just discard all the "java.lang.Error: java.net.SocketException: Connection reset by peer" messages?

Send'm all in. We fix based on what we see. :)

Thank you LimeWire Pro 4.9.0 is fantastic. Running like a champ have already hit d/l speeds of 160 KB/s. This best version yet, and I am extremely pleased with all the new features.

Great job LimeWire Team:D

Edit: My ATI Radion Display adapter is also running D3D with none of the previous problems noted in older versions ;)

1. Does that mean that LW will no longer stop the importation of songs to iTunes if LW is too busy as happens sometimes?

2. Also the early points of changelog, does that mean that OSX version won't suffer from the VM issues it has been struggling with?

3. Magnets: Does that mean the impossible to get magnet links from Bitzi will now be available to LW users?

4. Would using this beta & then reverting back to LW 4.8.1 cause problems. I know I had that issue after the 4.1.6 or thereabouts beta & reverting back to 4.0.4 (though this didn't happen with the 2 previous betas), where LW would refuse to load all incomplete files.

5. The concept of old hosts. If I keep incomplete files for a couple or more years does that mean they will fall by the wayside. Some ... such as some difficult clients & users as Raza are very difficult to get. There's one user I might get one file off once a month despite having many files I want of theirs. So thus a long list of incompletes just from that host.

* Looks very, very good & well worth waiting for. Only just getting it started. So many long awaited additions. Let's use the litmus test on VM. lol (it's a major issue for me!)

* It seemed to load the incomplete & shared files much faster. And settled down faster for self-continuation of downlding of incomplete files. Nice to say the least. Very impressive! :)

Oh & i got an internal error which I sent after about 100 mins of use.

4.8.1 will not be able to resume downloads after the beta has been run. Sorry, we had to change the format.

As with any beta software, backing up your information is always a good idea :)

LOTR, there is no correlation between Digital Audio Access Protocol (DAAP aka iTunes Music Sharing) and LimeWire's iTunes import function. If I say no correlation then I really mean no correlation (I know that b/c I wrote them both).

http://en.wikipedia.org/wiki/ITunes
http://daap.sourceforge.net
http://www.apple.com/support/itunes/...ent102094.html

OK? :)

Anyway, this is a fantastic version and an important step forward. I'm especially looking forward to the upcoming versions -- this is just the beginning! :)

LOTR:

1) See Roger's reply.

2) The VM issues on OSX are purely Apple's problem. We unfortunately can't do anything about it. I hear Tiger may have fixed it.

3) Not sure what you mean by this. Magnet links that only have a SHA1 still will not start downloading automatically, but they will create a download. I think LW now gives a notice that you need to start a search.

4) Yes. As Zlatin mentioned, the 4.9.0's "saved downloads" format is not compatible with prior versions. It can read older ones just fine, but older ones cannot read it.

5) Incomplete files will stay for just as long, or as short, as they used to. I believe that entirely depends on what setting you've put in the options. While the incomplete file is around, though, LW will remember more possible hosts for connecting.

PSes) Yup, loading shared & incomplete files is faster. We optimized a LOT of stuff. :)

The incomplete icon (presently downlding) in the search results seems to show the torn paper icon of the cancelled downlds instead of the open manilla type icon. I initially thought it was due to the files still being queued. But after another browse host (of the one I'm downlding from) I still keep getting the torn paper icon (image A again.) Despite these files are in the downld window. I even tried reselecting to downld but nothing happened. Not even a warning that I was already downlding the file. Could this be a change-over issue b/w the 2 versions or more related to me browsing instead of searching?
Only after I cancelled the downld & reselected from the browse results did the icon change to what it should be (image B.) So at least the old icon is still working sort of.
Oh but after I browsed host again it showed up as torn paper (image A again.) Or could it be related to the host being a single star? :confused:

Another issue I noticed (earlier on) was when after I arranged the files by size & then arranged by Status in the downld window, that some of the files didn't match up with their sizes (some mp3's showing up as 700 MB) This only happened once & I haven't been able to replicate it.

Also the icon for incomplete files folder in my Library window also shows the torn paper. Is that normal?

Late edit: Rebooted but still same issue. And the present downld (just started LW) also has the torn paper icon.

The incomplete icon showing may be a bug, we'll check that out. The sizes not matching up was probably just a repainting issue, in that the size column didn't fully repaint.

Sweeeeeeeet. That's it. I'm taking the plunge. Limewire Pro here I come!!

re icon paintings, if a file is downloaded from a browsed host, discovered through a "What's New" search, the file icon may not update in both seach tabs. This seems to happen when the search result panel was scrolled past the download entry.

Also, scrolling through long lists of a browsed host's files and randomly selecting one or two files from each screenful also seems to be a problem for keeping the icons updated.

speaking of long lists of browsed hosts--they don't seem to be causing the gui locks I saw before. Coincidence? or was that problem fixed too?

for the record, Apple's java in 10.3.9 still runs up the VMem. If I make sure there are no downloads or incomplete files, I can usually flatten the rise and let LW run all night without risking major problems in the morning. (graphs available). I've seen almost no discussion of it on the Apple java dev lists, but I'm losing confidence it is even on their radar any more. I'm beginning to think it's just my set-up.

On the bright side, running as an UP with no downloads keep the thread count at about 30, and the G3 CPU at 20%. So the optimizations have really opened the door for much greater longer uptimes here--thanks.

The bad side ;) is that the downloads are getting easier and quicker, so I'm checking out larger files than before. This means I'll have to get a larger laptop to share the goodies. :p

bug report bug?
 

Is there a 3 bug limit on sending or triggering the bug reports? The console shows 4 of the "java.lang.Error: java.net.SocketException: Connection reset by peer" entries, but only the first three popped up the Review dialog this session (options set to always review).

Yesterday's session was set to "always send", but only three with my client id showed in the bugreports page when I checked today. Console, however, logged over 40 of them.

GNUC results
 

Sheesh. It's been many months since I've seen those lousy results sent by "GNUC," but now they're baaack. I kicked the one GNUC from connections, but that didn't help :mad:

Has something changed to allow those results in again, or was it just my luck to link to some bad vendors?

I've had lousy luck searching for rarer content these past weeks, so I'm beginning to wonder if the code changed to prefer more popular content. (Hope it's not the network getting flooded with spam searches). For now I'll be optimistic that it's the almost two million users that's increased the horizon beyond my reach. ;)

btw--I'm not interested in boxing. cf http://www.gnutellaforums.com/showth...470#post141470 :p

Rare content is of course a problem on gnutella. Try disabling ultapeer mode. Leaves have by far the larger search horizon.

As for the GNUC client, I see those every now and then but not consistently.

Yup, there's a three bug limit in a few places. There's a limit for showing the review dialogs (so they don't keep stacking up forever), and there's a limit on the server side. Once it sees three of any given bug, it tells people to stop sending that particular bug again for quite a while. This prevents occasional situations on one computer from causing huge spikes in reported bugs. So long as the problem is widespread, we'll see lots of reports from different computers.

How are the bugs sent exactly, is it like a magnet link or something. Not that it's important to know just curious.

By clicking 'send' when an Internal Error pops up in the client.

No I meant after you send a report, how is it transfered to LW.

@ trap_jaw. Interesting about the leaf/ultrapeer horizon. . . and a little unsettling. I've been telling others that LW tries to give both UP's and leafs equivalent search and download effetiveness. I hope it's just temporary for this beta. If not, would you mind looking over http://www.gnutellaforums.com/showth...threadid=39641

thanks for the tip. I rely on running as an UP to maintain my 1 GB daily ration of an up/down share ratio at 1:1, but also prefer hunting down rare files from very casual users. I guess I'll have to come up with a different strategy, if leaves are to be better at searching for rare content.

btw---running as a leaf only got more spam for the 4 unique search terms, but that's not surprising. What was surprising was that initial checks of the memory, threads, and CPU% showed little difference. If that continues, the optimizations for Ultrapeers are REALLY amazing!

And to Sam & LOTR, thanks for clarifying the bug sending.

By an HTTP POST.

Splash screen covering initial wizard
 

Ugh. LimeWire 4.9.0 just like 4.8.1 still shows the splash screen on top of the initial wizard on the first load of it in Linux when using java 1.5.0_03 making it impossible to actually see the entire window without having to drag it around the splash screen. Clicking the splash screen doesn't make it go away or anything. I had this issue so far in SuSE linux some time ago and now in Ubuntu Linux both running java 1.5.0_something. The issue doesn't happen if java 1.4.2_something is in use.

We do try to position the wizard ontop of the splash, so it may be a bug with window position on Linux in Java 1.5. We'll try to work around it.

Thanks for looking into it! (And the FAST reply!) :)

It would also be nice if it could choose a better set of "helper apps" in its configuration by default. Such as in Gnome, a program named "gnome-open" can be used that will open a file in an app associated to the file's extension. KDE might have something similar to open files with, but I am not absolutely sure on this.

runLime.sh
 

In the zipped version of LimeWire, a minor addition to "runLime.sh" could allow it to be run via double-clicking it in one's GUI in Linux, after unzipping it, without having to crack open a shell, cd to its dir, and type "./runLime.sh" to run.

Adding:
above the "# try to discover java" line in "runLime.sh" allows the script to discover its own path, assuming the script will always be in the same directory as LimeWire itself.

Thanks a bunch Limenut, this is a real neat thing to have :) Will be in the next beta.

sometimes limewire seems to stick at %100 complete, but is still trying download at 0KB/s

some of those downloads reported to be corrupt, and others are just stuck.

upon restarting limewire, it says that all the files that are stuck are corrupted, and if i want to continue.

is this supposed to happen? cause that didnt happen in 4.8.1

Are the files for which this happens usually small (<100kb) or large ?

nah, just your normal mp3 size, around 3-4 MB

Salut all, great work! The libarry is finally cool and very usefull. I'm actually looking forward some features that have yet to be activated in the current CVS, ie looking forward spam filter ;)

On the friday CVS, I have a problem launching mp3 from the search window (when a dl completes), I can however launch the mp3 from the library, so I'm pretty sure it is bug on LW's part :p.

As I said looking forward 5.0 (is PATRICIA from Roger working in the current beta? -I don't remember seeing it merge in the CVS... advanced users will love that).

Ciao

@ultracross:

one more thing - could you enable the extended tooltips and let us know what a tolltip of a such stuck download shows? More specifically there should be a line saying something like

Chunks: x/y/z 256KB

If you could paste that line here that would also help.

Thanks!

i already have them enabled. i always like knowing whats going on ;)

I should specify that launching downloads in the search window doesn't work with mp3s but work for videos. (just tested on windows with 4.9 beta and it behaves the same). Of course, the LW player is disabled on all my configs ;)

Ciao

Do keywd filters work when browsing? B/c I just browsed & none of the keywd filters worked. Not to mention their ip was all single ones which was odd (except in the results.)

Did you mean the downld window et voilà?

LODR yeah, download an MP3 and try to launch it while dling from LW or simply when the download is complete.

Ciao

RAM (not VM) useage increases a lot when downloading on OSX, uploading or being UP doesn't trigger as much RAM useage. I'm at 135MB right now by only dling some mp3s operating as a leaf. Doesn't seem to happen on windows.

Keyword filters aren't used when doing a browse host.

Apple JVMs have problems with memory. There's nothing we can do about it. Yell at Apple. I hear it's fixed on 10.4, but I wouldn't put money it.

Can you tell if the RAM increase is 1:1 with the amount of data you have downloaded? Also, is the garbage collector hack we did sometime ago enabled?

No the garbage collector isn't enabled nor set up. I'll restart the Lime so I can monitor increase in RAM with downloads.

Ciao

im on winXP sp2 and it seems to eat as much ram as i have (512) cpu usage is still pretty high too (2.1GHz)

all when downloading, or sharing a large library (i have 3300+ files)

Humm, right now the RAM is at 170MB. I can say that LW started using 67MB ram, then with downloads the amount of useage grew up to 105 MB, while downloading much more than 40 MB. I left LW overnight without downloading but uploading and the ram useage is now 170 MB. Usually I leave LW uploading but not dling for days and this is my observation: without dling, LW can stay low in ram useage, but as soon as you dl something this seems to trigger a memory leak that persists even when downloads are done.


Ciao

1. Even with the same file name LimeWire will not ask to overwrite a file if the file does not match case.

2. The Column positions are not saved to the last place it was moved.

3. Seems that alot of files tend to corrupt when heavily downloading. (This could be the servents fault? I dont know.)

4. Overall program repainting seems to be slow at times.

5. The library does not show subfolder contents under saved files.

Thanks a lot ultracross, I may not be able to look into them as soon as I would like, but those files will definitely help us track down what's happening.

Keep up the good work, you guys are the best beta testing community we've seen. Without you LimeWire would be a lot buggier (and we've done our part (unintentionally) making it buggy, believe me ;) )

I can confirm that the mem leak happens when and continue AFTER downloads are made. When I finished dls, LW was using 100 megs, a day after it was using 220MB only uploading. I started LW again and after 24 hour, the mem usage is still at 80MB. Of course this is on osx.... with all Apple VMs problems.

Ciao

Salut et voilà

I've been trying to confirm, but it's not happening with Jaguar and my G3. The resident memory goes up for a bit, but then is recovered.

Salut Stief, maybe it is specific to java 1.4.2 on Tiger 10.4. I know Apple modified the JVM for Tiger over Panther.... Didn't try 1.5. I'm beginning to think Sun should do the Java for Macs too. I wonder what the apple java folks are doing :rolleyes:

Great :rolleyes: Apple seems to fix the Vmem problem on Tiger, then gives you a real memory problem.

As for what Apple is doing--not much that I can see. I browse http://lists.apple.com/archives/java-dev/2005 almost daily, and "memory" just doesn't seem to be on their radar.

Sigh.

Anyway, I'll keep watching the memory use charts (I try to save them after each session).

I also noticed something like this, limewire sometimes does not switch from a manilla folder to a green check mark after completeing the download.

-- listing session information --
Current thread: AWT-EventQueue-0
Active Threads: 24
Uptime: 0:57
Is Connected: true
Number of Ultrapeer -> Ultrapeer Connections: 0
Number of Ultrapeer -> Leaf Connections: 0
Number of Leaf -> Ultrapeer Connections: 7
Number of Old Connections: 0
Acting as Ultrapeer: false
Acting as Shielded Leaf: true
Number of Active Uploads: 7
Number of Queued Uploads: 0
Number of Active Managed Downloads: 0
Number of Active HTTP Downloaders: 0
Number of Waiting Downloads: 40
Received incoming this session: true
Number of Shared Files: 4148
Guess Capable: true
Received Solicited UDP: true
SIMPP version: 7
Port Stable: true
FWT Capable: true
Last Reported Port: 6346
External Port: 6346
IP Pongs Received: 0


Its been happening quite frequently upon limewire startup that i will get 7 ultrapeer connections, and then as time goes on, it comes back down to 5. does this have anything to do with how many files i share? or is this not supposed to happen?