When loading a large video file Limewire reached 100% then went into file verification, normally. But when it reached 99% verified it got lost in internal processing for nearly ten minutes. The other files that were concurrently downloading no longer had their time and bitrate updated, and while I could switch to another program, any attempt to do something on Limewire, like looking at the upload monitor or library resulted only in the spinning "wait" icon. Finally, the freezup cleared but the file in question was back to downloading, with 96% complete showing. This continued to cycle that way five times before I gave up and canceled the download.

I can understand that there was a problem with the file, and the drop-back was necessary, but Limewire should not lose control of the graphic interface while it recovers from a verification problem. If you can't handle the task as background a message of some sort might be nice. And giving up (or asking) after five or six repeats with no progress might also be the Mac-like response.

Likewise I've suffered a similar issue. But not with your particular example. I've found LW being very slow to bring up a stable option/pop-up window. It beach balls whilst I'm trying to click the option for yes/no or Apply/OK, etc. I've had this issue over several areas of LW when option/pop-up windows appear. I wondered whether it was semi related to me having such a large burdon on the program with a large incomplete folder & larger amount of shared files. LW for mac has long had an issue with Java & also memory. The most recent version is supposed to help overcome some of those issues. It certainly does use less ram than the 4.0 or 4.1 beta series used. But it's still an issue. And not just with popup windows.

As far as your problem with the re-trying to verify & complete the dwnld, LW is supposed to give up after a certain no. of attempts. I think it's 6 attempts.
May I suggest you update to LW 4.2.4

I re-tried the download and this time I let it go to see if LW would ever be satisfied. I didn't count the number of attempts because I let it run in background while I played a game. Over the next hour game response slowed until it was unplayable, so I quit and checked on LW. The file in question had vanished from both the in-progress list and the incomplete folder, with no user-notification. I have no idea of what LW was doing, as a result, but though the file had vanished, and operation LOOKED normal, machine speed was at a crawl for all programs. Only a restart normal restored system operation.

And as in the previous version the LW memory leak is in operation. Available free space on the primary disk dropped from 1.5 gig to 400 meg in under three hours, though it seemed to remain stable at that figure for several hours until the lockup.

I hope this helps

Jay

Which OSX version are you using. If you can, update your version of Java for that OSX version. I know with 10.3 there was a Java update a month ago that was supposed to fix some of these problems. Though if it did it was only marginal.

1.5 GB is not a lot of space to work with! Do you have your HDD partitioned. In OSX all applications use Virtual Memory. Which of course means taking up HDD space. So your game would do that & OSX also needs space. In fact I just checked mine & OSX alone is using 1.1 GB VM.

How much ram do you have?

May I ask how many incomplete & shared files you have? You can round it off if you like. Just an approx but reasonably accurate figure.

Do you ever use the Resume function? If yes, do you do it on many files over the period of a day/session?

<<Which OSX version are you using>>

10.3.6

<<If you can, update your version of Java for that OSX version>>

If it's available through Apple I have it, because my updates are set to autodownload and install.

<<1.5 GB is not a lot of space to work with!>>

True, but my secondary disk, where the download and incompletes go has far more room. Unfortunately, it's too fast to use as the system disk (with a G3 @ 500mhz there is an occasional problem on bootup).

<<Do you have your HDD partitioned. In OSX all applications use Virtual Memory. Which of course means taking up HDD space. So your game would do that & OSX also needs space. In fact I just checked mine & OSX alone is using 1.1 GB VM>>

No partitioning. And agreed the system, and other programs, use HD space, but LW, if run alone, steadily decreases available HD space, as though it's allocating space then neglecting to deallocate it before requesting more. In the previous version this would continue until response became so sluggish I had to cut system power to recover (took at least 24 hours to reach that point). Now, the HD space seems to bottom out at 400 meg in less time, but then stay there. It was there before I let it run and rerun the file verification, and seemed unchanged when I went beck to check. That's not a very scientific study, though, and I wouldn't take any bets on it being accurate.

<<How much ram do you have?>>

640 meg

<<May I ask how many incomplete & shared files you have? You can round it off if you like. Just an approx. but reasonably accurate figure.>>

Incomplete = 6 gig, thirty files.
Shared = 13 gig, 1425 files

<<Do you ever use the Resume function? If yes, do you do it on many files over the period of a day/session?>>

Now and then, but in this case I hadn't used it since I logged on and banged on the Find More Sources function when the list of old searches showed as needing it.

Hope this helps

Jay

A few of us have been trying to help the developers find out precisely what triggers this VM rise on OS X

http://www.gnutellaforums.com/showth...threadid=29871

It's been around for a while, and looks like it could be an Apple VM problem, but so far has been very hard to pinpoint.

In the meantime . . . you'll need to anticipate that you should have 3.5 GB free HD space before starting LW, to allow for the rise and regular VM use.

As soon as OS X get under 1 GB of free space, the system becomes very very sluggish. The newer LW 4.2.4 has helped *some*, but not enough.

Hiding/not Hiding LW has helped arrest VM growth. Keep Activity Monitor running to help see when to hide/not hide LW. This is a lousy workaround, but the only one I know of so far that lets LW run for more than a few days under heavy load.

Thank you for the information.

<<It's been around for a while, and looks like it could be an Apple VM problem, but so far has been very hard to pinpoint.>>

If it was an Apple VM problem lots of other Java apps would be reporting it, too. Agreed, it's probably something Apple is contributing to, but...

I'm going out on a limb here, because I have no idea of the LW programming environment, but it seems like something that would have taken the old time programmers, who were forced to work intimately with the hardware, only a short time to find, what with breakpoints and such. In a modern multi-tasking operating system environment those tools are not as readily available. And the programmers, too, look at things differently. They work at a much higher level, using compilers that are virtually machine independent (the word "virtually" seems to be what's biting us, here). In fact, many of them have no idea of what's actually going on inside the machine because to them it's a black box that gets the job done. And there's nothing wrong with that.

But that being said, it would seem fairly straightforward to cause breaks in operation at critical points, like requesting and deallocating VM, then checking to see if it actually happened, before going on.

Jay

In case anyone is interested, since installing this version of LW I have downloaded four video files, each greater than 500 meg. Not one has completed the download without going back to the net to pick up additional information, once dropping the file and the other three times finally resolving whatever problem was detected. In all cases, the file verification reached 99% then hung, locking up all functions of LW for an extended time, often as long as ten minutes, before dropping back to "Awaiting Sources" for the file in question and going back to updating the screen.

Kind of sounds like the LRC check, etc., on segments is not being properly done while the download is in progress. Whatever the cause, the process that recovers from that problem needs to learn not to hog all the processing time.

Yes, that was my mistake, I didn't want to rely on TigerTree hashes during the download and do the TigerTree hashes only if LimeWire detected a corruption. But I must admit, it was not a good idea at all. There is a patch for that problem but it did not make it into LimeWire 4.2. You may expect that to be fixed in one of the 4.3 betas.