I discovered why the bitrate column and extra search fields were all missing.

LimeWire wants write permission in its application directory. It'll happily run without this level of access, but not everything will work as expected. For example, the bitrate column will be missing.

Apparently, LimeWire creates a few files in its application directory on first run. If it is unable to create these files, some features will be unavailable.

To duplicate this problem, trash the LimeWire application directory and then perform an installation. Before running it, adjust the permissions. For example:

sudo chown -Rh root:admin /Applications/LimeWire
sudo chmod -R a+rX /Applications/LimeWire
sudo chmod -R go-w /Applications/LimeWire

Now start LimeWire, and notice that the bitrate column is missing. If you click on "Audio" to search for audio, the additional fields will also be missing.

This is a problem on Mac OS X and probably other Unix variants, because there is no guarantee that the user running an application has write permission on it. In fact, it is good practice to prevent unauthorized users from creating and modifying applications and support files shared by all users of the system. LimeWire should be restructured so that memory can be used in these cases instead of the disk, or if things must be stored on disk, they should be stored in ~/Library/Preferences/LimeWire, along with limewire.props.

Some of the files LimeWire creates on first run include Display.props and lib/xml. More can be found with intelligent use of "find -newer".

Mark

LimeWire 2.7.5
Mac OS X 10.2.2

You're exactly correct about this, Mark. We'll soon store everything in the user's home directory, as you suggested. 2.7.6 does this for limewire.props, fileurns.cache, and gnutella.net (the most important ones), but we'll do it for everything soon.

Adam-

Thanks for the quick confirmation.

Having figured that out, I looked at another problem I had been having. When LimeWire couldn't write to its application directory, I found that it wasn't reading or sharing any file metadata, like bitrates and ID3 tags. Now that I've allowed LimeWire write access (my workaround until everything moves to the home directory), I'm finding that it shares some of this metadata, but not always all of it.

I notice that each time I quit and start LimeWire, the /Applications/LimeWire/lib/xml/data/audio.sxml is rewritten. However, its size fluctuates. If the onlly thing I do is quit and start LimeWire, making no changes to any settings or shared files, the size changes after each run. For example, I just ran LimeWire four times, and wound up with sizes 176053, 48792, and 23147, and 34821. On another computer, I ran it twice, and had 91256 and 176946. Both computers are sharing the same set of files. When audio.sxml is smaller, and I browse from another computer, I find that fewer shared files have bitrate and ID3 metadata available. No matter how long I let LimeWire run, this doesn't change - the only solution is to quit and restart.

Any ideas on that one?

Mark

Alright, folks, I finally tracked down the root cause of this issue. The problem I fixed for 2.7.6 solved one serious problem that was affecting 10.2 users. Today, however, I found the more serious problem that is the primary cause of these issues. It was a bug in the installer code that did, in fact, create a directory called "limewire.props" that it should not have created. I just fixed this issue in LimeWire 2.7.7, so 2.7.7 should fix this problem for everyone. The first time you run it, you will need to enter your preferences, but they should save fine after that.

Let me know if anyone has problems with it, and thanks for everyone's help. This also fixes the issue of settings not being saved across LimeWire installs (so it solves both the saving between sessions issue and the saving between installs issue).

Thanks again.

adam,

do you have any solution to this problem?

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

2.7.7 looks good. Thanks, Adam.

This begs the question: why is an installer required for the OS X version anyway?

The metadata bug (my second post above) is still present. And uploads still make near-zero progress.

Mark

Where can we get a hold of 2.7.7?

I followed the usual link and the version I downloaded for OS X seems to be version 2.7.6 using the Limewire->About Limewire... menu command. The installer I downloaded was dated November 15 10:55.

?

Try http://www.versiontracker.com/morei...id=10275&db=mac
for the latest version. Even though the link says 2.7.6, the version downloaded and installed is 2.7.7.

mdouma46, I am sorry to say this but the link you gave us does not work. Here is the one that does. http://www.versiontracker.com/dyn/moreinfo/macosx/10275

Adam, I am not sure what version of LimeWire I am using. When I try to open it. I get the same error that is said on this post: http://www.gnutellaforums.com/showth...threadid=16918


I downloaded LimeWire off of the LimeWire website and I am not sure if I got v2.7.7 or v2.7.6 where can we find the latest version?

2.7.8 fixes the problem that Mac OS 9.x and below users have been having started the program. Apologies for the frustration.