2.9.2 Alpha Now Available
 

We have fixed a bunch of 2.9 problems with no doubt a lot more to go. There was a massive amount of code change in 2.9 and once it is out for about a month and we fix all bugs, we are going to hopefully see major improvements and a new paradigm shift in the Gnutella world.

The Mac classic version is still totally untested. Check out magnets in the PC and Mac OSX version:
http://www.limewire.com/magnet/pure-magnet.html

Thanks
-greg

thanks greg
Could you add a link to a changelog? It would help troubleshooting if we knew what to ignore or watch.

Let's see ... the changes between 2.9.0 and 2.9.2 are:

- Fixed issue with sharing the installer if no directories are shared.
- Fixed magnet requests so they'll work better if LimeWire isn't already running.
- Fixed statistics so that bandwidth data is counted even if the user hasn't checked to use advanced statistics.
- Fixed some internationalization problems.
- Fixed a problem with not adding a query string to magnet requests.
- Fixed a potential problem with parsing XML schemas that could cause LimeWire not to start.

And there might be a few more that I'm missing.

Hi Greg and Sam, this week, java 1.4.1 has been released on osX. However, java 1.3 is still default for applications that do not specify to use 1.4. I want to know if you could add code to choose 1.4 over 1.3 when it is installed on the machine? AcquisitionX is doing it, and I think it would be benifical to LW (scolling support wohoo!).
Thanks

Thanks for the changes, Sam (is there a link I should be checking?)
Wow--if this alpha works this well now, then I'm quite enthused. First impressions are very positive. Searches were zippy, Tool tips work, sorting/scrolling works properly, saw way faster downloads, and the magnets were amazing--25-80KB/s speeds noted.

This was the nicest surprise: I did a quick try first thing this AM. All seemed to work well. Then put the laptop to sleep, took it to work, changed my location setting to the work LAN, and Limewire responded without a hiccup, resuming the downloads at even better speeds! Came home, switched back to my home NAT, and Limewire again continued beautifully. I'd fully expected problems (Limewire was running the whole time), but was able pick right up. Nice work all.

LW did freeze my connection for a bit (tried to go into Ultrapeer from leaf), but I just checked Disable Ultrapeer, and the connections settled right down; internet access resumed nicely. Kill/resume doesn't seem to help requeries, so I'm glad not to feel the need to babysit downloads.

Maybe the great results are really due to the Apple Java Update . . . :p (but I think you're right et voilà; LW looks to be using 1.3.1)

2.9.3 alpha out
 

We have fixed some problems in ultrapeer mode. Forwarding of QRP tables was taking too long to process and this activity was tying up the message queues. We reworked some of the QRP table interaction and offloaded the QRP forwarding code to a new thread which has solved part of the problem. There still appears to be high ultrapeer CPU usage on occasion. Expect a few more alpha versions.

Thanks
-greg

Hé Greg! The two alphas I tested (2.9.3 included) seem to have localisation bugs. For instance I always specify to the installer to set the default as french, but then LW starts in english....

I second that. I'd like Limewire to support Java 1.4.1 on OSX!!

Why?

Making LimeWire run under 1.4.1 on Mac OS X is not something that can be done trivially. Much of the OS-integration code needs to be changed to support the new JVM-on-Cocoa environment. The media player won't work at all, because QuickTime for Java is not yet available for the new JVM. And, finally, using 1.4.1 would provide only marginal interface benefits over 1.3.1. Most of the FUD surrounding this issue seems to suggest, unfoundedly, that 1.4.1 would provide a performance and stability boost. There would be no perceptible performance improvements, and testing with earlier DPs of 1.4.1 indicated that stability would suffer, although hopefully Apple has worked those kinks out.

I'd like to see LimeWire run on 1.4.1 on Mac OS X too, but I don't see it as a pressing priority. You wanna write the code? (I've thought about it, but I wouldn't be able to get around to it 'til the Gnutella network is actually usable again. :) )

Mark
@version@/10.2.4

sorry--FUD? (Fear, Uncertainty, Doubt? F'n User Dumbness?) just curious.

Mark, thanks for the explanation about 1.4.1. I wondered if I'd missed an install step.

I thought Acq worked out how to use 1.4.1 and Dave released some code the opensoucers would integrate. I'm not surprised its far less simple than that: Darn!

oh--would you or anyone tell me why or why not to delete that .com.zerog.registry file before each new install?

That error bitmap doesn't make any sense unless the user is using an aol browser to download the installer.

Thanks
-greg

All I do is use the path to the 1.4.1 java vm and run it. Trivially easy. And probably not even necessary.

One of those. Pick!

The LimeWire core, which Acquisition embeds, doesn't contain anything that would really prevent it from running under 1.4.1 on Mac OS X. The OS-integration stuff is what currently depends on the JVM-on-Carbon implementation not available after 1.3.1, and that stuff is in the gui.

Mark
@version@/10.2.4

LimeWire Alpha Version 2.9.4
 

We rolled out another alpha version on Friday (need to upload the PRO beta on Monday - accidentially uploaded the free version twice).

This version fixed one massive bug in our search results. We have been misparsing BearShare (and some Morpheus) results in such a way that they show up as one star results. This has been true since June 2002. Results seem to be a little better overall.

A few other exceptions were fixed as well so we are getting a little closer to stability.

Thanks
-greg

Greg, I would like to know if a classic version of LimeWire 2.9.x will be released sometime soon.

I'm not sure if it's the right version but trusting that LimeWire's build process is driven by scripts (and they did not bother NOT to create the Mac installers), - you might try these:

http://www9.limewire.com/beta/LimeWireMac.bin
http://www9.limewire.com/beta/LimeWireMacNoVM.bin

Those installers have not been tested yet and I don't know for sure which version it is (I assume it's 2.9.4 however).

I am anticipating 3.0

Norm

Trap_jaw, I don't understand what you meant by this: "and they did not bother NOT to create the Mac installers." Could you explain this please?

He means - they are there. Try them.

Thanks
-greg

Greg, I noticed no big change in the classic version of 2.9.4. It looks very similar to LimeWire 2.8.6. Adam said that a lot has been changed like a new look for LmeWire 2.9x. It still has the same look as 2.8.6.

There is a lot of themes changes that we are going to turn on for 3.0 I guess. These are like lightweight skins.

The real changes are invisible and mostly on the Ultrapeer (i.e. Dynamic Querying, Ultrapeer Query Routing on the last hop, Higher outdegree/lower TTL). These are what we are really trying to beta right now and fix (no doubt) lots of problems with. This is our big shot at changing the way Gnutella works by making it much more efficient (100x) and less resource consuming for messaging (selective broadcasts rather than pure broadcasts). Until these changes fully take hold, we need to work to tone down the messaging rate of the existing network. Thus, we need to make some of these changes (outdegree vs TTL) in stages.

Thanks
-greg

Strange Process user on OSX
 

There is a root level process which at least involves the write_store and lsregister files (part of the LaunchServices.framework) showing up as unknown user or even “Zombie” (?) processes. Can’t be killed as usual admin user.

This may not be related to LW, but last week trying 2.9.0 I noticed unknown and oddly named (symbol font?) by user “???” processes triggering Console entries like “ Process Viewer[406] enumerateProcessesAndFetch couldn't scan time.” Tried as root user today to isolate it/them and now know it’s independent of LW and an internet connection. One such process led to a link with the write_store & lsregister files

After usual maintenance, including root user completely uninstalling any p2p stuff, replacing the write_store, LSRecentTool & lsregister files from the original OS 10.2 CD, deep cleaning caches by JCC (long overdue), I’ve only since seen one more ??? process.

The original CD write _store file does includes something about a corrupt write/time:

dyld_mod_term_funcs __dyld_make_delayed_module_initializer_calls The kernel support for the dynamic linker is not present to run this program.
usage: store_write <store-name> <path>
d_corrupt .24s : Wrote corrupt store file %.4096s
/var/tmp/csstore.log

Don’t know that it affects LW, but hope this saves someone troubleshooting time.

Oh, I didn't realize that the Mac Classic download links had been commented out. Those are back on the free beta page. I'm uploading the PRO beta now.

Thanks
-greg

2.9.4 PRO alpha is good to go. Mac Classic versions are back on the beta pages.

Thanks
-greg

The file size on the OSX beta needs an update.

Greg,

This might be a bug. In the download section of LimeWire, I have the chat column removed. I quit the program. When I open the application again the chat column is still there. I'm using version 2.9.4 of LimeWire.

LimeWire is not saving changes to the columns of the download table (yet).