Recent betas have a troubling regression: once again, "resume" is useless as Limewire refuses to connect to known sources for a file. In 4.8.1, for most files hitting "resume" produced an honest attempt to connect to the file's sources; in early 4.9 betas it did nothing. In later 4.9 betas (around 4.9.10) it worked again, and in 4.9.14 it's broken again.

On top of that, it is becoming increasingly obvious that it is becoming increasingly urgent that ways be found of identifying and dynamically working around "bad actors" on the network. The ipod spammer, for example, but the ipod spammer is only the tip of the iceberg. There are a lot of just plain broken clients out there -- "indian giver" clients that result in things like "downloading 1% ... 2% ... 3% ... 4% ... 5% ... Waiting for busy hosts" and then it just sits there forever saying it's busy and won't resume, and similar clients that offer juicy search results but then refuse to actually upload them to anybody (you know the type -- usually they come in bunches, and every one of them immediately "needs more sources" so, of course, you hit "find sources" and now mysteriously the files are suddenly impossible to find judging by Limewire's complete failure to find any more sources...even though they were easy enough to find when you initially did a search...) ... and then there's the broken Shareaza versions that will give six different uploads queue position 1, and then refuse to serve any of them; the downloaders just see, alternately, "Shareaza -- waiting in line, position 1" and "waiting for busy hosts" and, of course, never "downloading".

All of these misbehaving clients need to be routed around, ostracised from the network; if the people running these rudely-behaving and broken clients can't find or download anything they will switch to clients that work properly, or upgrade to versions that have fixed the bugs, or whatever. Currently users don't have any incentive to upgrade to fix bugs with *uploading*, and such bugs have proliferated in several popular network clients until just seeing their names in the Vendor/Version comment makes me sigh and give up on any likelihood of ever downloading the file. So let's give them one, and also weed out the spammers and spoofers while we're at it.

By the way, Limewire is still prone to be schizophrenic about whether a given host is online or not. Often a batch of co-hosted files will end up in a mixture of states that includes several or even all of "waiting in line", "waiting for busy hosts", "downloading", "connecting", and "awaiting sources". The last one doesn't belong -- if a source for the file is online the file should be at worst "waiting for busy hosts". "Awaiting sources" means -- or is *supposed* to mean, anyway -- that there are no known sources for the file currently connected to the network. The list of known sources is a bunch of iport pairs all of which have nothing listening at the other end at the time, in other words. If any of them respond, even with a busy signal or some other such "buzz off" message, it should show "busy hosts" and periodically retry until the host is not busy (or does go offline).

(And with "resume" no longer working, hosts in yo-yo mode are also a massive pain to download from. The downloads all end up "awaiting sources" and in 4.8.1 you'd just hit "resume" and half of them would start downloading. Now if the source has a flaky network connection or keeps rebooting or restarting their client, they all end up "awaiting sources" and you have to ... keep restarting your client! And that, of course, makes a bunch of people uploading off you with a Limewire beta restart theirs, and so on, and so on, in a chain reaction. I thought we were supposed to be encouraged to keep our clients running 24/7, not shut them down when not in use or frequently restart them, but the gone-again, back-again "resume not working" problem encourages the latter and the continuing bloat problem -- not even just ram use, but it's a CPU hog too, and that's damned strange for an event-driven application -- encourages the former.)