What is going on with Limewire? More and more features -- worse and worse performance. I get "out of memory" errors quite regularly on my Windows XP machine -- with a GIGABYTE OF RAM! No way should it need close to that much, let alone *more*. Simply leaving it on overnight suffices to ensure at least 3 of the buggers waiting for me in the morning, like christmas presents wrapped by the devil, and probably also a totally dead, hung UI. It was bad in 3.8.5, got a bit better up until 3.8.10 was almost tolerable, and then 4.0. 4.0 apparently demands as much ram as high end CAD and video editing tools, since it reports out of memory on a 1GB machine regularly, hangs a lot, and has every other error imaginable save outright closing itself down. Also, what's with it refusing to resume old downloads more often than not? I thought keeping your downloads across sessions was supposed to have been added as a feature way back in 2.something. I'm still waiting for it. It won't run for more than maybe an hour without becoming slow and unstable. Long freezes occur during which it drops half its connections, the UI won't respond, and task manager shows it gobbling up CPU, hardly touching the NIC, and spawning dozens of new threads, not to mention consuming 100MB+ of RAM (but nowhere near 1GB). These hangs begin to occur if it's left running for very long at all, and become very long and frequent and cause transfer failures and poor search results if it's left to run for more than maybe two hours. If it's left to run overnight, you can forget about it -- it's either hung, or at least in a really wacky and unstable and not properly functional state. (I personally love it when the tables start flickering wildly like a Commodore 64 game during a brownout in the days of yore around 1985 or so, and the "auto-sort table" setting is ignored even if it's checked.) Honestly, there's no reason it should need that much RAM, and still complain there's not enough memory on a 1GB machine, hang and misbehave often, become unstable just from leaving it running with a fixed workload (the same number of shared files, upload slots, and queue slots). It's obviously got a severe object leak inside, one that got abruptly much much worse with 4.0's creeping features adding yet more object churn.

Relevant system specs: Windows XP Home SP1 with all critical updates up-to-date; up to date network, video drivers; cable Internet connection; correct firewall configuration (I can download and upload successfully -- for about one hour, and then Limewire becomes virtually unusable, that is); 1.5GHz Athlon XP 1800+, 1GB RAM, and 3MB/s bandwidth up and down (i.e., may as well have a dual T1 running into this thing, except they'd cost more); and several GB of free disk space. Throw in swap, and there's effectively 1.6GB RAM available, and the system hardly ever gets above the high 700s as indicated by task manager, which eliminates swapping as the cause of the slowdowns, hangs, and errors. Sharing about 10,000 files -- too bad nobody can get the larger ones, since Limewire will have to be shut down long before the transfer completes even at cable speeds, so this isn't a freeloader complaining here. Current version: Limewire (free) 4.0.4 and wishing I had stuck with 3.8.10 which actually worked for four hours straight once without being restarted and once or twice actually remembered my downloads across sessions.

This user isn't buying Pro anytime soon, and isn't buying it ever unless there's an update Real Soon Now that addresses the worst of these performance problems. No filesharing application should need >1GB RAM to function without memory allocation errors. I'm astounded that the minimum system requirements listed include "64MB RAM" when my own machine, with 16 times that much, clearly does not meet Limewire's minimum system requirements -- and Limewire makes sure to remind me hourly of this fact!

If you want people, the vast majority of whom are running Windows XP, to leave it on overnight, it has to actually work when left running for that long, and not lose peoples' data regularly if it's not restarted very frequently. As near as I can tell the rules for keeping the dreaded internal errors and "could not resume old downloads" at bay, not to mention slowups and hangs of the UI, are as follows: Don't queue many downloads at once -- 100 is enough to give it problems right away. Don't let it run for very long. Only perform 1 search per session -- forget about five search tabs at once, though that was quite fine under 3.8.10. Close it the minute it gets slow, even if it means interrupting an incomplete download. Don't share thousands of files. In short, it's better to be a freeloader that hops on to do a quick search and grab a few files than to try to dedicatedly share a load of stuff. This isn't the message I think you want to be sending. Also, bad experiences with hanging, crashing, data loss, and the like with the free version does not make for a very good advertisement for the pro version.


On a side note: why does it seem to be more difficult to get small files than large ones? It's easier to get a 100K chunk of a 100M file than to get a 100K file, it seems -- if I queue a bunch of multi-meg MP3s I'll see a ton of them downloading, often from 5 or 6 hosts apiece, and few to no need more sources or partial downloads. If I queue a bunch of itty bitty jpegs, I'll get two, and the rest will fail, except some 20K file will die at 98% complete. What the hell? How can it fail there? The packet used to send the stupid busy signal could have been used to send the other 2% of the damn file, it's that small. I get the feeling there's an economy of scale that cuts both ways, with overhead dominating actual file data for files under 1M. People do share things other than mp3s you know. Photo albums, for instance. I suggest maybe some small file optimizations are needed in the system as a whole. For instance, when many small files are requested from a host that has them all, they could be sent as one big lump -- tar and untar them on the fly, perhaps? Small files do often occur in batches of related files on a single host. Or some sort of chain-downloading, or just not dividing files smaller than some size into chunks at all -- what's the max size of a network packet? 64K? So break small files into chunks 32K in size, sending files up to 32K in size in one packet. An express line would be useful too, limited to small files and maybe to high-speed (DSL or better) uploaders. Seeing (or being!) a cable user stuck in line behind five slow modem users all requesting multi-meg files blows chunks -- and wastes my upload bandwidth.

Of course, one pain in the network is all the Shareaza (and others, but mostly Shareaza) hosts configured to 0.000001KB/s upload bandwidth by clueless people in the mistaken belief that this helps their download speeds -- on most setups, you get separate bandwidth pools for up and downstream flow, and on 56K dialup, your connections to ultrapeers are probably already reducing your download speed to 28K. Besides, dialup speeds suck too much to suck noticeably more because you actually let people get files from you. Sharing files at 0.00001KB/s is just a way of being a freeloader without showing up as a freeloader on clients that detect them purely by counting files.

And can we please have a "no to all" button on the download overwrite prompt? I'm sick of clicking the plain "no" button 50-odd times when trying to suck up a whole category of search results, such as a big bunch of jpegs, in order to speed their propagation through the network -- having more high-speed sources for files helps everyone, so making it a pain to be such a source does not. Also, I thought I saw a new option in 4.0.2 (though it seems to be gone in 4.0.4) to ban anyone that downloads more than some number (I think the default was 5) of files from you! Needless to say I turned this off -- I want high speed hosts to be able to snarf up large numbers of file, then they become much more available over the network. Preferencing of high speed uploaders makes sense though, especially for a file your host knows of few high speed sources for via the mesh. I hear the term "greedy client" a fair bit lately -- IMO the only "greedy client" is a client that isn't sharing files. A high speed client with large numbers of files should be preferenced and never banned, as uploading a file to such a client aids its propagation through the network greatly. Besides, I don't like the implications such a feature has for rare content: if there are six rare files only to be found on one host, and that host only ever allows a given person to get five files, then they can NEVER HAVE all six rare files, unless someone else gets one and then shares it. Or they cheat and use a free AOL disk to get a temporary account with a different IP address. Speaking of which, banning specific hosts is nearly impossible anyway, since nearly everyone has a dynamic IP address. (The downside is that banning specific *files* -- mutilated files plastered with ads, for instance -- is impossible too. Even if the host polluting us with such files is a dot-com with a fixed IP, while consciencous sharers like me that get such files in the process of trying to build a comprehensive library of one type of content review all new files before sharing them and delete such tripe, plenty of people will have left their download directory shared by default and will also proffer these crooked files. I think maybe there should be a gnutella layer for voting on files -- files get a reputation and clients let you preview new files before sharing them, and delete instead. If the file sucks due to being mutilated with ads, damaged, etc. you can vote it down by deleting it from this preview window, and the information propagates through the mesh and is stored by clients as metadata. Search results indicate the file's quality with a star rating, as well as indicating the file's availability somehow and its speed somehow. The show search results filter options would include filtering by speed, availability, and reputation. If most people who downloaded the file deleted it, it's probably damaged, ad-spammed, or the filename misrepresents the content in some way.

By the way, what doofus registered the name "Unregistered"?

That's 100+ queued, I only set it to allow 20 download connections at once.

a good read--lots to think about. Thanks.

re the crashing---FWIW, I reorganized my shares (4.5 GB; ~1400 files), and then started having start-up problems. Bit the bullet, trashed the fileurns.cache and .bak, waited the 40 mins for them to rehash (thought maybe it would be faster than the 1GB/10 min figure it used to be). The CPU stayed ~35-40 % which is MUCH better than before, and everythings been much quicker since. No data loss, gui slowdowns, etc. Can't say I've seen any error messages though, and it ran for 50 hours this weekend (OSX). So--looks like a new fileurns.cache is good here.

re the 100+ downloads, I can't offer anything similar. Did try 50 plus (small) at a time last week--I guess habits develop because it seemed abusive--but couldn't see any problems other than firewalled (?) hosts that only let one or two at a time through. btw--since the search results now show already downloaded files, I'd forgotten about the old request for the "remember" checkbox.

Sure like your idea of making a block of lots of small files equivalent to a single large file as far assigning upload slots, and preferencing those who request unique files. What about allowing "folder" downloads? The Library can show paths . . . and looks like the Library is on the agenda for the next batch of attention. Yeah! Directory uploads! Should cut the messaging chatter considerably too!

I don't buy your "no Pro" argument though. Sounds more like it should be "Get Pro" so there's more push to get the program developed and fix those bugs--many of which remind me of when Java and OSX were (are) learning to play nicely together. Aren't all of you on XP due for a Java update soon--1.5, isn't it?

cheers

May try that.

The faster you get files, the faster you share them -- I don't see how that can be abusive. As for the new icons showing already-downloaded files, it would help if only the icons were accurate. Unfortunately, they aren't: doing a search often produces results listings with stars by items you already have, and even occasionally a checked paper by something you don't.

An incentive to fix bugs is to make people thing "This thing is great! I'll chip in and get pro." Give them your money before they're fixed, and the incentive disappears. I thought software users had learned that a long time ago, from Microsoft -- once they have your money they don't give two puffs any more, save that more bugs makes it more likely you'll pay to upgrade...

As long as there are serious bugs I keep waiting one more version, one more version to see fixed, I want to keep on the "upgrading is free" side of the divide thank you very much. I might consider paying for a genuinely stable product. Current versions don't approach that by a country mile, especially the 4.0 series...

As for a new version of Java, I hadn't heard. 1.5 sounds like an unstable version though -- wouldn't it likely make things worse? Might be better waiting for 1.6. Also, given that Limewire's performance took a steep nosedive going from late 3.8 to 4.0.2, it seems that major version jumps and the accompanying new feeping creatures tend to be accompanied by sharp drops in performance, only made up gradually over succeeding minor version increments (e.g. the improvement from 3.8.5 to 3.8.10) -- so going from Java 1.4.2 to 1.5.0 will probably mean going from a fairly well tuned VM to one that runs badly. Running an app with performance problems inside a VM with performance problems would compound problems massively.

And none of this addresses the disturbing fact that it regularly complains of being out of memory when run on a 1GB machine...

Uh ... where exactly is the fileurns.cache? It's not under the Limewire directory at all, as far as I can tell -- neither under 4.0.4, nor incomplete, nor lib, nor shared. Maybe it has a different name under Winblows?

Bah...Agent Ransack eventually found it in a hidden directory in a part of the filesystem ten thousand miles away from Limewire itself. It seems to want to save some settings on a per-user basis on multiuser OSes. The location in a hidden directory predictably made the built in Windows search fail to find it. Even with show hidden files etc. turned on in it, in Explorer, and everywhere else I've seen such a setting...

Well, it's using as much ram as it ever did, around 120M, but it's not complaining or slowing down quite as much. What happens to the index file that causes this (or at least, worsens it?) Why isn't it listed as a Known Problem with a Known Workaround in the appropriate section of the user's guide on the Web site? Is there a way to avoid the index file being damaged in this way? Does upgrading cause it, maybe due to a drift in the format of this file which gets markedly worse when it's a major version number increase (e.g. 3.x to 4.0)? If so, why isn't it converted when an upgrade is run for the first time, or at least rebuilt? (ICQ does this with its database files sometimes when you upgrade. Otherwise it's no example to follow: slow, bloated, somewhat buggy, though not as bad as MSN for taking matters into its own hands and deciding you wanted it to disconnect when you told it no such thing. And that silly mouse buttons dialog! Why not just make either mouse button bring up the menu, or make clicking just select a contact, double clicking launch a message window, and right clicking bring up the menu? The latter would fit standard windows UI behavior, and although currently double clicking is supposed to open a message window, half the time it opens the menu instead and sometimes it seems to simply do nothing, or the app hangs...)

Bah. I just found out that Limewire got 32% of a file and then choked.

The file is 12K (yes, you read that right, 12K) long.

Why the foo didn't the remote host send the whole damn thing in one chunk? The maximum size of a network packet is 64K, easily big enough to hold the whole thing plus overhead, for god's sake. I can think of no rational reason for this, save someone wasn't thinking of anything but mp3s when they optimized this sucker. Except I am unsure that qualifies as a rational reason.

On a side note, I see a lot of downloads broken off at suspiciously round numbers. 32 and 33 and 67 and 25 and 50 and 75%, for instance. I can't see why random network outages or people just happening to go offline would disporportionately often happen when a transfer's fraction completed could be expressed in small integers. But human beings have such preferences. Is there a client out there that deliberately serves a fixed, small integer fraction of a file (e.g. a third or a quarter) and then boots a host to the end of the queue, and then forgets them so they end up with "Blah blah ... 32% complete ... Awaiting Sources"? If so, can it be detected and banned with some undocumented config option? (Filtering by vendor/version regex matching seems to be a curiously lacking but desirable feature, given that all client programs are emphatically NOT created equal!) Especially as it obviously cluelessly applies this policy to files large and small, and even small enough that the whole remainder of the file could have been sent in place of the damned busy signal used to terminate the download!

If the intent is to let people requesting small files get them quickly without being stuck interminably behind several multi-meg uploaders, isn't an express lane a superior solution? Especially as interrupting a transfer, in my experience, carries a measurable risk of damaging the file not incurred if it's continued to completion. Also, IMO when an upload fails, for some time the uploader should hold the slot open for resuming the same file. There should be a good faith effort to follow through and complete the transfer "through rain or snow or sleet or gloom of night" -- or routing glitches or one host's dynamic IP changing or one's dialup connection dying and needing redialing. As it stands, it's common for a download to fail partway through and uncommon to ever resume it successfully, at least not without extensive searching and requerying. And limewire makes you restart the client to requery a file again if it doesn't find it the first time...

ARGH.

The internal errors, slowdowns, hangs, etc. are back as bad as ever after letting it run a couple hours and selecting a hundred or so files to queue for downloading eventually. What is wrong with this software? How can it possibly be out of memory when Windows Task Manager shows [/b]less than half[b] the total available virtual memory in use? If it's not, why say that it is and then get unstable? Who designed this thing anyway? :P

Actually, given the stability and slowdown problems, which lead to dropped connections with network events aren't serviced fast enough because it's gone creating dozens of threads that take CPU priority over the event handling thread for some insane reason, maybe a useful idea would be to have reserve connections. These would be reserved spaces on ultrapeers, but without anything much actually happening in the way of traffic; they wouldn't be used to route searches for instance. Like the upload queues, they'd be the next in line, but leaves would have them too -- one at least, and maybe a full four, ready to go live the moment an existing connection dropped. Thing is I'm sick of seeing at least one red bar most of the time on my connection meter. It's not just that it drops connections frequently; it's also slow to reestablish them. (It was slow in 3.8.10; it was really slow in 4.0.2 with locale preferencing, until I turned that off; now it's merely slow again.) If it held one in reserve to switch in as active at a moment's notice it could recover nearly instantly from just one dropped connection. Unlike an active connection to an ultrapeer, a reserve connection would not need to consume much in the way of bandwidth or resources at either end prior to becoming active.

Basically, the idea is to do the work of finding a replacement connection for one that fails *before* it fails, rather than after, but sit on this information until there is at least one new connection needed and use it only then. A form of precomputing in order to optimize recovery from network hiccups.

I suppose that still wouldn't help with search results being poor if a connection or two bomb right after you start a search, which is all too common, leading me to suspect the existence of "fair weather friend" ultrapeers that are quite happy to route searches your way but drop you like a hot potato the minute you send off so much as 1 query yourself... Anything that supports uploading as somehow "better" than downloading hurts the network, since equal amounts of uploads and downloads is what will actually happen barring some kind of multicasting extension, and that means making it a pain to download reduces uploading in equal measure anyway.