Gnutella Forums - LimeWire 4.10.7 Beta

Gnutella Forums (https://www.gnutellaforums.com/)

- LimeWire Beta Archives (https://www.gnutellaforums.com/limewire-beta-archives/)

- - LimeWire 4.10.7 Beta (https://www.gnutellaforums.com/limewire-beta-archives/52960-limewire-4-10-7-beta.html)

I can confirm a spike in the verification process. As I already told Roger Kapsi, it would probably reduce a huge bottleneck if the verification of chunks while downloading would be verified in memory instead of writing to the disk, then verifying it. Verifying it in memory cuts the read/write process in half since you download it, verify it in memory then write it to disk instead of downloading it, writing it to disk, then verifying it. Make sense? This could also potentially speed up the downloading process as a whole. I just know that its killing my disk with amount of read/writes its doing.

Or maybe a hyrbrid combination if the user doesn't have enough RAM?

Quote:

I didn't get around to trying 4.10.7, but just trying 4.10.8 now. I notice my pre-4.9 incompletes refused to load. lol :D Anyway more to today's issues, I've been finding some odd behaviour. Tiger 10.4.4 with Java 1.5; Audio downlds are seeming to freeze LW during verification (just small files) but the downld & importation into iTunes still continues. I was surprised to see my search & verfication freeze (at 90%) but then iTunes open & import. Similar for the next file. A total freeze of LW except for prefs. 3rd downld the same, froze at 93% verification but iTunes still imported it. The freeze seems to last for a reasonable time after iTunes has imported it. There doesn't appear to be any jump in VM or ram during that time but cpu does jump up.

Making sure we understand correctly a during the verification process the entire LW application freezes, but an import into iTunes succeeds, and eventually LW recovers from the freeze? If so, does this happen only with audio files of certain size? Does it also happen with video files (those should be shared with iTunes), and any other type of file?

What exactly do you mean by "A total freeze of LW except for prefs." Are you able to open and use the LW preferences? Do they get saved properly if modified?

Could you please try to compare whether the cpu and disk activity of 4.10.5 during the verification phase with that of .6, .7 or .8. Also, if you could get a stack trace during the freeze it would help us a ton.

The same issues haven't been evident. So despite using the console to make reports, there's nothing to report. :D I wonder if it was initial taking over of older version preferences. So I haven't had the same problems reported earlier. No freezing for verification or canceling downlds.

Videos appear in iTunes playlist if that's what you wanted to know. Are you intending to leave as an option in the LW preferences for potential future auto-importing of videos to iTunes on OSX?

After 12 hrs of leaving LW static (but uplding), VM was around 750 MB & after 4 hrs of searching & downlding it finished at just over 900 MB. Closing off windows, searches & console reduced it by perhaps 8 MB. :D

Edit: I will add though that LW just crashed whilst running in the background. It hasn't done that since I updated to Java 1.5 a couple of weeks ago.

Beta 4.10.9 is out. It reverts some of the changes that went into the last three betas and should use less cpu and cause less disk activity. Unfortunately, LAN transfers may be slower. Please give it a try and let us know how it goes.

Best,
LW dev team

Nothing special to report, other than after about 18 hours of use, all of a sudden both RAM & VM are suddenly on the increase whilst LW is not downlding (is uplding.) Have downlded large files over this time. Have 6 search tabs still up. I did a search just 5 mins before the 1st snapshot image below.

There's 3 mins between no. #1 & 2, 10 mins between no. 5 & 6, 22 mins between 1 & 6. It seems LW or Java has reached that point it just collapses in handling LW. Using Java 1.5, OS 10.4.4, LW 4.10.9
At this moment, 10 mins after the last snapshot, the ram is 348 MB, VM=2.04 GB, & 2,181 threads.

I can presume that LW will crash within the next half an hr. I presume this is OSX Java right & not LW's fault. :confused:

I decided to open the console before it crashed & save a report covering a few mins. Do you want to see any of it & if so, how much of it?

LW is now extremely sluggish, getting spinning beach ball trying to change view mode or other things for eg.

At present:
Threads=2,364 (increasing sharply!)
RAM=538 MB
VM=2.14 GB

Edit: I just got a couple of internal errors. Lost connection ... error of Potential dud connection in console report.
Ram=525
T=2,451
VM=2.18

Doesn't seem to be able to reconnect! Trying for several mins.

I gave up, LW refused to reconnect. It had used 2.20 GB VM.
I noticed there were around 1,500 listed as Upload capacity reached in my monitor window & the usual queued & uplder at 0. lol :D Was able to reconnect after re-opening.

So I guess LW reaches a point of no return re: Java on OSX.

BTW whatever happened to the days of files continuing on their own (find their own sources after LW starts)?

Quote:

Originally posted by Lord of the Rings
ram is 348 MB, VM=2.04 GB, & 2,181 threads.

Memory doesn't surprise me, but 2000 threads???! Never seen that so far.

CPU% is much better with 4.10.9

I downloaded a couple of 600+MB files and I get like 80MB RAM and 490MB of VM between 28 and 80 threads, CPU usage is between 4-9% on 1.2Ghz iBook, Osx 10.4.5 java 1.5.0-5 with LW 4.10.9 as a leaf.

Very good so far, no easy bug or whatsoever to bitch about....

In fact I like 4.10.9, IMO downloads and uploads should be NIO to decrease, but... ;)

Ciao

Uploads & downoads (downloads first, probably) will be using NIO eventually.