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*

:D --I understand why changelog is such a miserable chore!

You've got a great set-up--can you see what eats up your CPU as shown in Process Viewer?

I just started up Limewire, and weird...

[I'm also running the LW 3.5.2jum206. Stief told me that the jum verisons would not be updated for a while, however, this one came out Sept 2, so I felt I could use it and still reliably report.]

During the loading process, where it refreshes the library, my CPU processor usage for LW jumped above 100%!

Strange. Setting a refresh rate of 1 second on the process viewer, the % usage jumps from 3%-110% and everything inbetween.

[Note, everything above is before I've reached the 4k user network limit]

Just a note, I'm just running LW, Safari, and the Carracho Server and browser. Also, I'm sharing 3200 files.

Alright, after I reached the 4k user limit LW stayed at around 5-8% CPU usage. It would hit a high of around 15% and a low of .7(!)%. Every once in a while, it would jump to the high 20s, and ever once in a great while, maybe to the high 50s.

Aha! I found something. Before this point, I had been running with advanced statistics off. Once I turned it on, my average cpu usage was around 25-35%.

I tried looking at the QRP Sent thing. It *seemed* that maybe when those peaked, I had higher usage, but to be honest, I really couldn't tell. It could've easily been something else that I wasn't aware of.

I hope this is helpful to people. If not, tell me what I'm doing wrong, and I'll try to do it right. It's about midnight now *chuckles*, so I ought to turn in. Night all.

I've got 3.5.2 beta on a 1.7GHz/1GB WinXP box which seems stable with 14000 files. Mean CPU usage is < 20%. Prior to 3.5, more than 8000 files caused the app to crash after a few hours on the same system at > 50% CPU usage, but that could have been a local problem.

Update on my test:

After some 5, 6 odd hours running, when everything is minimized, my results are these:

It seems that it "wants" (however you phrase) to stay at around 6%, however, it jumps up to the fifteen and 20s (maybe once every 20 seconds). I'm refreshing at one sec in the process viewer. Also, more rarely It jumps to the 50s-80s. Can't examine anything more closely, cuz school calls, but later I shall.

FYI
With both 3.5.1-Pro and 3.5.2-Pro, I uncheck the option for "Load LW with Windows" in the installer, but a new LW icon still ends-up in the Startup folder.

ff
 

how to uninstall in winxp pro

Thanks for the head's up on the startup issue. This was working at one point, but subsequent changes I made appear to have broken it. I've just fixed it here, and the fix should go out with the next beta release.

Thanks again.

Thanks for everyone's help regarding performance issues as well. We didn't really make any performance improvements in the 3.5.x series, but we certainly did not intentionally do anything that could have had a negative performance impact. I'm glad to hear that users are able to share as many as 14000 files without a significant impact on performance, though.

That's really interesting that you see difference Window redraw rates with LW versus the JUM version. Do you have the stats open in both cases? Is it possible that you're simply looking more closely at this data than before?? We continually profile the application, so we'll continue profiling to make sure we haven't introduced any new issues. We may also be able to improve performance more for big sharers down the road.

As far as how many files is too many to share, this depends on a couple of factors, including the popularity of the keywords in your files and the capabilities of your machine. 14000 honestly seems a bit high to me, but the only potential problem would be using up too much of your CPU. So, what you're happy with in terms of CPU use is the ultimate benchmark -- I would recommend sharing up to the limit of how much CPU you would like to devote to LimeWire. If that gets too high, don't share quite so many files.

Thanks again for everyone's help.