Running LimeWire 2.7.13 under OS 10.2.1 on a G4/400MHz

Now that CptChipJew has found a work around for the CPU hogging bug, I set myself up to start sharing/downloading files in earnest.

I moved my Shared and Incomplete folders off the system disk to a partition with more room and organized all my large .avi and .mpg files all into one place.

Relaunched LimeWire from the Terminal Window, and . . . disaster

-- Window Manager claims 98% of the CPU for 10/15 minutes at a stretch, then disappears totally, only to return again at 60/70/80%
-- LimeWire takes 1:15 (yes, 75 minutes) to recognize 23 of my 25 shared files [2GB]
-- any other non-LimeWire operation like double click to open a folder takes minutes.
-- and, before anyone asks, no I was to performing large searches, no I was not an Ultrapeer.

If simply moving the shared files out of the partition containing LimeWire creates such a major problem, then the bugs in this system are far worse than I thought.

I don't think a simple work around will fix this.

The problem is that LimeWire will recreate the SHA1 hash of a file, if it is moved or renamed (even in the library tab).

That's obsurd!

What possible reason could LimeWire have for reacting to the fact that I've moved the Shared Folder from one partition to another? For that matter, how would the system know? I changed the location of the shared files in Preferences.

If there's no way around this, I will be unable to share files -- I don't have 2GB free space on my System partition.

it's not obsurd at all. the only way a program can distinguish files (excluding hashes, because that's what we're calculating here) is by the full pathname of the file. otherwise, something like:

/vacations/jamaica/flower.jpg
and
/vacations/hawaii/flower.jpg

would could be considered the same if the sizes were the same.

when LimeWire starts up it checks to see if the files you're sharing match any recorded pathname, and gets the existing hash. if it doesn't match, it recalculates the hash and stores it, purging info that no longer exists in the filesystem.

i really don't see what the large problem is. when you move files, it'll rehash the first time it encounters the new path.

OK, I was wrong about the hashing -- I hadn't realized that it was a one time only process.

BUT

I am not wrong about Window Manager hogging the CPU.

I am now at the point that Window Manager claims 97% of the CPU whether I launch from the application or from the Terminal Window. Since the only thing I've changed is moving my Shared Folder from the Systems partition to my data partition, I have to assume the problem is yet another LimWire/java/OS X incompatibility.

I wasted the entire evening chasing this down, and now I'm out of ideas.

try 2.8.0, jannuss. it has some small optimizations in the display so that tables are only updated if they're showing. (i don't think this was in 2.7). i have no clue if it'll help, but someone else mentioned that 2.8 has used a little less cpu time for osx. wish i could help more, but i don't own a mac.

I tend to avoid Betas. Is 2.8.0 stable enough to rely on?

2.8.1 [when/if] should fix the few problems that people found... but i think overall, 2.8.0 is very stable.

2.8.0 installed and no joy.

If I launch the application normally, the system stalls so thoroughly that the only option is Forced Quit -- if fact it takes so long to get the Forced Quit menu to respond that the first time I tried it I actually switched off the power!

Launching from the Terminal Window is better. Window Manager starts out at 70% and more. Eventually, it settles down and seems to run OK. I haven't had to time to test it properly.

Clearly there's still a bug and clearly it hasn't been fixed in this Beta.

Should I start a new post on this?

Did you try editing the runLime script?