Very slow opening share library
 

Both my library list and my list of shares seem very very slow to open up.

I just upgraded to 2.5.5, and had been running 2.3.2.

Under 2.3.2, it found all 600-odd files in a second or two, and all of them showed up in the library.

Under 2.5.5, it shows only 1 or 2 to start, and adds another every few seconds. (It's not a constant length of time between changes.)

The system has basically no load except LimeWire and KDE. CPU usage is < 2%.

System is a 1.2 GHz Athlon, with 1 GB of ram.

I had downloaded the latest Sun JRE, 1.4.0_01. I had JRE 1.4.0 before. I tried 2.5.5 with both, and it didn't make any difference.

Tried firing up 2.3.2 again, and it runs fine.

Wanted to check here before I reported it as a bug.

Anybody know of a fix?

As designed
 

See this thread.

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

Re: Very slow opening share library
 

First see the link - the short answer is this version of Limewire employs hashing... this takes a couple of seconds for each file you are sharing (to create the hash).. it only has to do it once so this will clear up after all the files are hashed...

Just so you don't get thrown off: While it might take a few seconds for an mp3, jpg or text file - it might take 10 to 15 minutes for larger files. For example, I have archives of an old Linux user forum available and they took a significant amount of time to complete the hash. I imagine movies would also take quite a while.

Also, make sure your permissions are correct, or you might end up going through the hashing more than once. Note that improper permissions can happen without you knowing it - for example, if you reinstall your system, your permissions might change without you even knowing it since the directory names remain the same. However, your ID might have been 503 in the last installation, but is 500 now.

Thanks to all, that does indeed seem to be the problem.

(For the benefit of anyone seeing this problem first in this thread, you have make sure the directory LimeWire is installed in allows the userid you're running under to create a file called "fileurns.cache".

If you installed LimeWire as root (or even as any id other than the one you're using now, you may have to diddle the permissions on the install directory.

What's happening (very very slowly) is that the system is computing a hash for each file.

That means it has to read and number-crunch each and every file in your share library (-ies), and worse, it will not let you or anybody else see those files until they've been hashed. And if you haven't changed the permissions on that directory by the time you exit LimeWire, you'll lose it all and have to start over.

Hopefully, whoever implemented this functionality has heard about the flaws in it and is working on a better version.

My two cents worth:

Show the files, both as shares and as files in the library whether they have a hash or not. _THEN_ if you want to compute them (very slowly) in the background, OK.

In any case, if you can't store the computed hashes in the default directory, store them in the user's home directory. If you can't put it anywhere else, put it in /tmp.

Let the user know some of this is going on. If having the hash right this second is optional, you can write to your desired directory, and the system doesn't seem too loaded, then it might be ok to just do it without informing the user.

Doing it WITHOUT telling me, in such a fashion that it seriously cripples my usage (and then throws it all away!!!) is NOT the way to make friends and influence people (not in any direction you _want_ them to go, at least.)

Thanks much to all those who helped get me out. Here's hoping 2.5.5 is as much of an improvement over 2.3.2 as 2.3.2 was over the original. (Minor little glitches like not being able to play your own library for 5 hours notwithstanding... <g>)

CHL