LimeWire 2.2.0 beta is has just been posted to the LimeWire web site at http://www.limewire.com/index.jsp/download_beta.

This version includes a number of new features and fixes, including:

<ul>
<li> Elegant metadata display. No more "change view" button; you just turn columns on and off. You can also view the metadata for a file if its available simply by mousing over that search result.
<li> Automatic requering. When a download fails, a new search for that same file is automatically launched, and the download is automatically attempted again.
<li> Menus appear in Mac menu bar on OS X, with "Quit," "About LimeWire...," and "Preferences..." options meeting the OS X look and feel guidelines.
<li> Reduced number of inter-ultrapeer connections to conserve bandwidth for UltraPeers.
<li> Added loading information to splash screen.
<li> Splash screen had a new edgy, "extreme sports" kind of look instead of the former "file sharing for Marth Stewart lovers" feel -- our shameless attempt to appeal to the rising generation.
</ul>

Other changes that will remain largely invisible to most users include:

<ul>
<li> Dynamically sized "route tables" -- generally bigger for ultrapeers, smaller for leaves. Performance increases in many situations, though slightly worse in others. Overall, this will bring an excellent improvement to the network.
<li> Eliminated "TTL boost" between leaves and ultrapeers to reduce bandwidth consumption for messaging, leaving more bandwidth for downloading files.
<li> Connection authentication support.
<li> HTTP 1.1 upload support.
<li> URL decoding support on uploads.
<li> Send bitrates for all audio, even if missing ID3 tags.
<li> Uses TTL of 1 for "watchdog" pings.
<li> Bugfix: uploads handle "Range" requests properly.
<li> Bugfix: "N'th child of root bug" from repeating search is fixed.
<li> Bugfix: "ConcurrentModificationException" from XML/QRP is fixed.
<li> Bugfix: "FileNotFoundException" for "ads.props" is fixed.
</ul>

We hope everyone likes the new version. You will also notice that the free version of LimeWire no longer bundles Gator.<p>

__________________
Adam Fisk
LimeWire Developer

Thanx again for your hardwork and awesome client. However, I have one question that remains unanswered. How come my user connections usually tops out at around 3000 users. Is this due to a limitation in the ultrapeer technology or just due to the restructuring of the network? I ve noticed Fasttrack s superpeer technology has allowed for connections of around 500,000 users. Do u guys have the ame prospects for ultrapeer technology? Thanx again. BTW...the new metadate update is awesome! Perhaps u could incorporate CDDB metadata retrieval in the future.

very nice changes, but i don't really like the new splash screen, any chance of a different one (with the loading progress text)?

The metadata and requerying is great.

The number of users (also called horizon statistics or number of hosts) can not and has not been accurate for a long time. There are many more users than these numbers would lead you to believe. This is all based on the amount of "pong" traffic and LimeWire and BearShare have been restricting pong traffic for a long time now because it wasted bandwidth. There are 50 to 75 leaf users connected to each UltraPeer and you do not get pongs from them so whatever number you see could be off by a factor of * 50 or more. If you look at the Connection tab, this is why we put ? in the host column. It might be fair to say multiply the statistics view number by 50.

The same is true of the Gnutella statistics on LimeWire.com. We don't crawl leaf nodes (although I believe we started indicating them again with this release) so those numbers also undercount the network. One of the items on our todo list is to report better network statistics but it comes second after better overall functionality.

Thanks
-greg

adam, is there any chance you implement HUGE in the near future?

HUGE is very high on our list of priorities, and will be one of the next big features in LimeWire. I can't tell you precisely when it will be implemented but it shouldn't be too long.

On the splash screen, I've found that changes such as this often take a little while to get used to.

Whats up everyone!? Sorry that I've been away for a while. It looks like its been slow anyways. So I guess I havnt missed anything. I feel really bad that I didnt send in my resume for the LimeWire Customer Support Intern. But I'm already do busy as it is so I dont think I would of been able to do my best work. Hopefully things will start picking up here, hence the upcoming new release of LimeWire. Anyways 2.2.0 looks great, I actually like the new splash screen. Its brighter and more colorful. As always LimeWire kicks ***!

__________________
anti-bearshare aka scud
http://www.scudhacks.com

I am wondering if you could change the the right click button in the OS X version to control-click instead of apple-click because that is what Apple has set as the right click and it would make it alot easier on use with 2 buttoned mice that can't right click in LimeWire.

Hello.

I know I should post this problem in the downoad\upload problems forum, but nobody cares.

Many users have a problem with resuming downloads, for more info go to:

resuming download

(it's two pages)



and please at least reply. It's really annoying.

Thank you for your attention.

__________________
Dima

fix the internal player

Thanks for all of the comments. Our apologies for not responding to some of the threads -- we really do have limited resources and have to make a tradeoff between working on the program and answering people's questions or responding to their comments. As you probably know, I and the other LimeWire people who post here are the developers who actually write the software (and there are only five of us!), so it's just a constant battle to try to get to everything!

We are working on the resuming issue in various ways. Actually, we're really tackling it by just improving the general architecture of the network so that resuming will improve along with a bunch of other things. The changes will really be on two fronts: 1) HUGE (Hash/URN Gnutella Extension), as mentioned above, will introduce a really nice scheme for efficiently finding duplicate of file on the network in a really robust way, which will improve resumes when you need to resume from another host and 2) Far better swarmed downloading using HTTP 1.1, which will make resuming an issue less often. This change will significantly improve download speeds.

So, we have at least a couple a neat features coming along in LimeWire 2.3.0 fairly soon. We will also be updating the integrated player at least on OS X to use the native QuickTime API, so you'll get the best sound available on any system, at least on OS X. We may integrate this as an optional download on other platforms as well.

I think 2.2.1 for Linux has a memory leak. Java is using like 20-60 cpu usage on average. Sometimes it gets higher than that when I search. 2.2.0 did not do that, it was a lot faster. Thats the only thing I've noticed with the new version.

__________________
anti-bearshare aka scud
http://www.scudhacks.com

Also when I leave 2.2.1 running overnight when I wake up the next morning its gone, core dumped. I get a lot of of console messages while it is running also. This are some of the last messages before it pooped out.


"Thread-1" (0x8c7ce10)
java.lang.Object@28D27108/296C5A90: <unowned>
Waiting to be notified:
"Thread-1289" (0x8f48830)
com.limegroup.gnutella.downloader.ManagedDownloade r$RequeryLock@28D9FAB8/29694F20: <unowned>
Waiting to be notified:
"Thread-140" (0x8e1d5e8)
com.limegroup.gnutella.downloader.ManagedDownloade r$RequeryLock@28E60520/296A6848: <unowned>
Waiting to be notified:
"Thread-184" (0x8ee1658)
com.limegroup.gnutella.downloader.ManagedDownloade r$RequeryLock@28D9CB18/296A1368: <unowned>
Waiting to be notified:
"Thread-144" (0x8ea9ce0)
java.lang.Object@28D280B0/296C26F0: <unowned>
Waiting to be notified:
"Thread-1285" (0x8f44780)
com.limegroup.gnutella.downloader.ManagedDownloade r$RequeryLock@28E5C7E0/296A6D88: <unowned>
Waiting to be notified:
"Thread-185" (0x8ec7718)

Thats everything that was in the buffer. Hope it helps.

__________________
anti-bearshare aka scud
http://www.scudhacks.com

I have great respect for what you guys have accomplished, and I am very grateful, but I don't really understand this idea that resumes will naturally get better as the infrastructure is improved. Sure, if Limewire supported hashing, etc., then resuming downloads could be more robust -- assuming they worked at all. But it seems to me that they DON'T work at all, ever, and the real problem is not architectural but just that there are *specific bugs* in the resume implementation that prevent it from working. (e.g., when Limewire resumes a download, even automatically, it usually restarts it at the beginning in another file with a different name, or restarts at the beginning of an already partially downloaded file, overwriting what was already saved.)

So you can improve the architecture as much as you want but it seems to me that this won't be of any use unless the bugs are fixed. Example: requerying was introduced in 2.2 and unfortunately this feature is essentially worthless because when a partially downloaded file is automatically requeried and restarted, it doesn't resume properly. I don't see what the point is of adding features that can't be of any use until more fundamental bugs are fixed.

If you are gonna use Quicktime on Mac OS for the player .
Consider using DirectSound (Directx sound module) on the Windows version .

For one it doesn't hog that much resources as Quicktime .
Most people have Quicktime itself set to use DirectSound on Windows .
So if you use Quicktime , lot's of systems will load both Quicktime and Directx .
A waste of CPU time if you can pass the sound on to DirectSound in the first place .