Well if et voilà & Stief leave their system running 24+ hrs after downlding large & small files, ... then after a break do more searches .. perhaps some more junk filtering also ... & don't suffer the same java breakdown then it must be just my system. I thought I was doing well with Java 1.5 with an older LW version, but come 4.10 it seems a different story. Like the one I knew before the OSX upgrade if not worse. I didn't suffer internal errors before. Let alone inability to reconnect.

I guess I could trial out 4.10.0 again to see how Java 1.5 handles it compared to 1.4.2 in Panther. As documented in Jum's thread.

I don't run an imac. Is that the difference or is it the processor or general overall different mapology of newer G5's?

I don't mind beta testing if it's of any constructiveness for the proggies. But if I have a query, it would be helpful to me if I could get some type of answer. I don't know whether my reporting is constructive or just an ink blot on the page.

Ok perhaps I should delete my LW prefs, & change downld location to give it a total fresh approach. BTW how do we separate the section icons & figs at the bottom of the interface so we can know exactly how many files we're sharing? All I get is an ... as the sample image shows ... is that 37 tens or 3.7 thousands (or 370 k files)?

Attached Thumbnails

 

lotr
rather than changing location, etc, just install in a new admin account (then you don't have to worry about old prefs, etc).

I can run LW for about three days (as an UP), but when the system gets sluggish and the beachball starts working, then I know it's time to shutdown for two minutes to clear the VM. I also keep the incomplete folder purged as much as possible, and hide LW overnight. This really didn't change much whether it was with a G3, G4 and all the various OS X flavours.

re feedback in the beta threads: feedback is rare, but sure is nice when it shows. I think of the feedback as a bulletin board rather than a conversation.

More than fair enough comments! I'm a person who normally runs with a high no. of incompletes which no doubt contributed to my previous success of LW restarting incompletes without assistance.

What I had started to do just now would in effect start a new, fresh downld account if you like. But you're probably right, a new account will be without the intrusion of other program prefs, background running, etc. I will do this ... just the pia of relogging, blah blah .... When it shuts down all other operations.

If you hover over the number of shared files it should show a tooltip with the right number.

If you see a high # of threads again, could you get a full stack trace from the console log? You have to be running Java 1.5 to get it, so if that's possible that'd be good.

I did save 2-3 stack traces afaik if I did it right (6 altogether), reports of several mins of running last time. If you want to see them just ask. But I'll check in a new account & see how things go & see if it happens again. It will be a virgin downld space except for shares

I 1st need to finish using another app before I can log out though.

' "Full" stack traces ', what do you mean by full. I'd have thought about 20 hrs of running with stack trace on all the time would be somewhat over-sized. Yesterday I saved reports at intervals (1st two 9 & 10 hrs before) notably over the last period; 4 over 25 mins with each the equivalent of 15-16 A4 pages in Word (just to get a measure of the size.) The last 2 LW was not connected. I think the loss of connection happened during the 2nd last one (I'm not sure.) How to send them?

By full, I mean the ones from the console tab when choosing 'save' if you're running Java 1.5 or higher. The resulting file should include stack traces of every thread the program knows about. For now, just a single one of those when the program has this high number of threads should be fine. You're welcome to post it here as an attachment or mail it to this username @limepeer.com.

I'm not so much interested in the loss of connections right now as I am the 2000+ threads. The stack traces won't be too helpful to me for the loss of connections.

As a furter data point to the memory consumption on OS X: if you do not have any search tabs open and do just your queued downloads and uploads as searches come in everything is fine. As soon as I have a search tab open (even if it is not searching any more) the mem consumption goes up all the time and LimeWire will eventually crash due to the machine going out of memory.

well well well! Thanks for the tip--I'll give that a try this weekend. Might this then be "fixable" without Apple's help?

Possible problematic points:

search panel on the left
filter boxes on the left
search results table
downloads table

any chance you could muck around and see which one of those is causing the problems?

thanks.