LimeWire 3.5.2 Beta
 

We've just posted the LimeWire 3.5.2 Beta on both the free download page and the pro download page. The pro download is available from your pro download page, and the free download is available at:

http://www.limewire.com/english/content/beta.shtml

3.5.2 is mainly a maintenance release, fixing a few issues that were found in 3.5.1.

The 3.5 series includes the following changes:
- iTunes integration on OSX. When an audio download finishes, it will automatically be added to a 'LimeWire' playlist in iTunes.
- Easier bug reporting. You can now help us debug by simply clicking 'Send' when an internal error occurs. You still have the option to review the information before it is sent.
- Better validation on extra download sources, ultimately saving bandwidth and improving download success rates.
- Stalled downloads will now correctly die, allowing other sources to finish the download.
- More sources in search results.
- More aggressive download behaviour. LimeWire will now always attempt to find an active downloader, even if you're waiting in line from some hosts.
- More options for search results, downloads, uploads, connections and the library. By right-clicking (or control-click on macs) on the column headers of tables, you can choose to whether or not you want to display tooltips or row stripes, or if you want that table to be sorted automatically (automatic sorting is currently not available in search results).
- Windows users (using the English version) now have the option to start LimeWire on system startup. This will significantly help the network, as well as improve the speed with which LimeWire starts when you want to use it -- it will pop up immediately and be ready for searching.
- Upload queueing logic is improved. LimeWire will now allow an upload if it notices that enough upload slots are available for a particular queued upload AND all of the uploads that are before it. This will reduce the amount of time that downloaders will have to 'wait in line' for a file, as well as increase the speed with which files can spread throughout the network.

As always, thanks very much for everyone's help testing the betas!

-The LimeWire Team

This isn't a bug with all the recent beta, but the past couple or so, I notice that if I check the "Put harddisk to sleep" option in Energy Saver in OS X, Limewire will freeze upon wakeup. Just thought you guys should be aware.

bug
 

Bonjour les dévs de LW,
It happened that all my files under the libary are showing 1 source more than they should (i.e. files that haven't been transferred show 1 source). This sounds like a minor bug though.

greetings all

3.5.2 looks to be very stable. I'm curious what leaf guidance means (trying to read the stats) if anyone would be so kind to explain.

Noticed also some unusual peaks >1mbps in the upload stats (ran three sessions to check) while on a direct 128kbps connection. CPU usage is up here on the G3 Mac, and the loading of already hashed 9708 shared files takes ~4 mins.

CPU usage is higher than I've seen for months--often hitting greater than 89% (G3 384 Ram), even with LW 3.5.2 Beta hidden. Still, no crashes when switching panes, though the beach ball will often spin. All else seems fine.
Anyone else seeing this?

Been hoping also to hear how iTunes support is doing (Roger Kapsi, right?).

iTunes support is in all 3.5.x versions. New downloads should automatically open iTunes when your download completes to make sure that iTunes is aware of your new file.

As far as the upload bandwidth goes, it is strange that you're seeing such large jumps. It's more likely due to your computer being generally overloaded in those moments, so what looks like a lot of bandwidth is really the CPU being so busy that it's unable to take the measurement accurately. We'll keep an eye on this.

On the CPU use, are you sharing a similar number of files as you would before? Among the changes we made, I can't think of any that are candidates for increasing CPU use. Are you sure that your Ultrapeers status was the same with this version as opposed to previous versions??

Hi Adam. Thanks for the remarks.

The bandwidth jumps were happening with little else running (no more than the OSX mail and Safari).

I am sharing significantly more files, UP status is as before (or better) with this ISP.

I'll reduce the file numbers.

Just an idle question while we have adam here: I know that, theoretically speaking, there is no maximum for the number of files that can be shared, but at a realistic level, how much would you say is too much? Once your individual CPU usage gets too high? Or does sharing many files affect something else that might kick in sooner?

I'm sharing around 3200 right now, and I don't seem to have any problems.

Number of Ultrapeer -> Ultrapeer Connections: 32
Number of Ultrapeer -> Leaf Connections: 30; hosts reach the 4000 limit in stats quite smoothly in about 10 minutes--pretty typical of what I've seen with this ISP (128kbps DSL)
unsharing a folder containing~8500 items/ .5GB helped the CPU usage, but less than I'd expected (still 40-60%), and window redraws were still unusually slow. Switched to LimeWire version 3.5.1jum205 (uses Apple's dp Java version 1.4.1_01)--CPU looked ~10% less, but similar. Reshared the folder (nice--no rehash required!), and CPU was generally up in the 50-88% range. Key difference noted was window redraws were quick--no spinning beachball.

Switched back to LW Pro 3.5.2 Beta (after a shutdown of machine and 128k modem)--saw beach ball between window redraws at first/less later. Tried running more apps--mail, safari; downloaded some music and watched the iTunes fire up and start playing smoothly (nice feature!), but the only stat which seemed to reflect the CPU jumping up over 90% was the QRP->Sent, often when the Unsent jumped over 300 (max 1268 messages per sec).

Does dropping queries require a lot of processing power?

Sorry again for the length and mumbo jumbo numbo's, but my trial with this ISP ends tonight. Thanks for reading: I don't know how you gurus filter so much information into sensible sentences.

Wait a sec, you say the gurus filter the data into sensible sentences?!

;)

*chuckles*