We've just posted the LimeWire 3.5.4 beta. This version includes several minor bug fixes as well as a new .dmg installer for OS X, which is almost identical to the JUM installer. The LimeWire team owes a big thanks to Jens for contributing the scripts to create this new installer, as well as for all of his other fantastic work on the project. We'd also like to send out a big thanks to Roger Kapsi for contributing the iTunes libraries and code on OS X for automatically bringing up iTunes when downloads complete -- the feature that was added in 3.5.2.

That's pretty much it for 3.5.4. We're hoping this will be the final beta release -- this should become the official release version very shortly.

Thanks for everyone's assistance testing the betas.

-LimeWire Team

Nice to see that this work goes mainstream. One question though - the GURL Library is still the old one so magnet links do not work, do I see that right? In the version of the scripts I send in I used Roger's newer GURL jni implementation that should work under both JVMs.

We're trying to be as cautious as possible with the changes. It'd be very difficult to find the cause of a problem if one package has a different implementation than another package. When we merge the new GURL implementation in, it'll be for all the releases.

Sam--are magnets supposed to work with the official beta 3.5.4 release?

btw--I'm really impressed with LW's cooperative efforts. It just keeps getting better and better.

greetings all. Is this a queuing oddity? I watched a BS 4.2.9 uploading some 2meg jpg's. "His" speed was good (~30KB/s) and is the only uploader shown in the uploads list. As soon as one ended, the next began--I expected to see him queued even though I set for 1 dl/person.

btw, reverting to the Dec firmware update for the Linksys router looks to explain some upload jerkiness, but I have to leave IP unforced to use two machines on my LAN.

I might just not understand what you're explaining, but I'm not sure why you'd expect to see the uploader queued. If it was the only one uploading, when it finishes an upload, why would it not immediately allow another one?

LOL--I reread my post, and I don't understand what I was saying . . .

He asked for 7 files and one spot was available. The other six didn't show as queued. Should they have, even though my prefs only allowed one download at a time?

Oh, that makes a bit more sense then.

Per-host limits take precedence before queueing. So, if your preferences are set for 1 upload per host, then future responses will be marked as 'busy' instead of 'queued'. This is done so that a single host can't take up all your queue slots, preventing other hosts from retrieving files.

Hmm. That's good that a single client can't tie up all the slots. Still, since I had open ul slots ready for anyone else, he was welcome to queue for that one slot and get a queued message rather than the frustrating busy message.
Might queues for each slot be more efficient and user-friendly?
Thanks for reading and understanding--sorry for the fuzzy thinking.

I've noticed this also .. BearShare does seem to be the most polite client out there. Just from observation of uploads, it seems to quickly figure out how many slots it can grab and queues requests at *its* end. Hence as soon as one upload completes, the next starts (or joins the server-side queue).

LimeWire's not as friendly - if some smart alec requests a hundred downloads at once, it can fairly hammer away at it's target server.

Morpheus seems to be the worst - I've noticed morpheus clients requesting each of 50 or so files once every 5 seconds. Ikky bandwidth drain.