Couple more known bugs:
A file will show up in search results as presently downloading despite never having chosen that file to download (no such incomplete file.) I notice this now & again. Thus unable to download that file anyway. lol Even seen it with files I'd never choose to download anyway. lol (the files were not spam files AFAIK!) I realise for video files at least, this can depend on hash I guess, the hash can be identical but just a different video file-name.

Not sure anybody else has noticed this, a file that is downloading goes into Waiting mode. If I pause and unpause it goes back into Waiting mode. Yet if I download another file from same host, that file downloads fine. That means there was an upload slot available. I've repeated same thing with several new downloads from same host, each time the file waiting was unable to continue. Not until ages later did the file continue. I've seen this behaviour very frequently.

All LimeWire 5 versions including LPE delete the gnutella.net connection file whilst the program is opening if this connection file's last modification date 30 days or more. This was fine whilst the LW company had a bootstrap server to assist everyone get connected, & whilst connected LW could find other hosts. But since that insurance has gone, the way LW 5 works with the connection file is not good. Even if the user has a 'good' connection file, LW will delete it if it is dated 30+ days ago.

As discussed previously in this thread: errors for persons attempting to download from you with messages like: "Invalid Request", even for files you're sharing, not only incomplete files. This is obviously a bug of some kind. (Discussed in posts 107 to 112 Invalid Request bug.) It may be somehow related to a host not yet having downloaded the hash of the file and LPE misidentifies them.

Below, example of 'Invalid Request' for queued file waiting to upload.

Below, upload speeds drop as hash is downloaded. One file fails to download the hash within time thus, 'Invalid Request'

Below, combination of 'Invalid Request' for queued files and, 'Upload limit reached'. It is a total mess when you see it in action.


The total of upload bandwidth at times either leaks or giving incorrect figures. Whether running as UP or leaf, sometimes the upload bandwidth shows as using up 25-50 KB/s more than those downloading from me are actually using. Thus the downloader's may begin to struggle, even lose their slot due to upload bandwidth leaking somewhere else. I would point to this as a major bug. It happens reasonably often for me.
(example GiF of wasted upload bandwidth; 2 uploading, two waiting) Another example: - In this example, those 3 uploads at 0 KB/s stopped and became "Unable to upload:invalid request". Had been uploading fine both before and again some minutes later. But note the upload bandwidth at 65 KB/s yet only 25 KB/s was being used. This is a severe bug hampering uploads.
Here is another example of the buggy LW5/LPE upload technology, many people trying to download 2 video files but unable despite I had 8 upload slots (I even tried increasing to 16 upload slots.) The bandwidth shows 56 KB/s but nobody was uploading from me, this also shows the previous bug mentioned re: upload slot handling, the upload bandwidth was like this for about 12 hours and has happened far too many times for my liking:


Uploaders occasionally get an error message and unable to upload from me. For example, one person was trying to download a single large music video from me, the error message was "Unable to upload: upload limit reached" despite nobody else was uploading from me at the time and the downloader only wanted the one file. I had 5 upload slots available. I restarted LW, same thing happened immediately and this person was the first to attempt to download from me after the restart with several minutes break between closing & restarting. I've seen this happen with several persons. This is a bug of some kind. Great, a 1 GB video half-way through and they are unable to continue due to this bug.

The same issue of first host in queue gets priority, so is the file in question. Thus if several people are wanting to download the same file from you, this file gets priority over all others in the upload queue. But if too many want it, then the error of upload limit reached issue applies. It's odd technology but I see what the LW devs were trying to do. It's just somewhat buggy.

For those of you who had not yet discovered, LW 5's upload technology is figured around the number of upload slots and speed set. I've found if I have too many upload slots open, this reduces the speed of the overall uploads. As soon as I reduce the upload slots, the upload speeds increase. Odd huh?

LimeWire 5/LPE never corrected memory use-age & management. The program limits RAM use-age. Even Virtual Memory is limited. Unlike LW 4 which might have used lots of VM when needed. Instead the program starts to lag before eventually crashing.
I am astounded when LW runs out of memory when I have 16 GB RAM & 4 x 1 TB drives, yet LW only utilises about 350-395 MB RAM (2.2 to 2.5% of my total system RAM) & less than double that as VM. The program's internal settings for Java memory use-age are set far too low. This (mentions my gripes with LW about this concept.) And in this thread, LPE memory issues. I also mention about this lower down in this post about Java.lang.OutOfMemoryError: PermGen space. I have tried a different set of shares preferences, with no banned ip's, half the library count, half the shares, yet still same problem. I found one major contribution seems to be a download folder with a very large number of files. This seems to add lag to the program. Reducing the download folder's file-count improved things dramatically. Also downloading different media types to different folders helps in same way.

For MacOSX, only OSX 10.5 and above can use LW 5/LPE due to the Java version required. I highly doubt any mac computers running 10.5 or higher would have 1 GB or less of RAM. Heck, I've had a computer running 1.5 GB of RAM since 10 years ago and my 4 year old intel Mac has 16 GB of RAM. LPE for OSX is only set to use around 350-395 MB of RAM (less than 2.5% of my RAM capability.), far too low. You cannot even buy a Mac computer with less than 2 GB RAM (Mac Mini) and most have 4 GB or more minimum (including the Macbooks.) Both Safari and Firefox (with plug-ins) might use up to twice as much RAM as LPE.

The 'Library' concept introduced with LW 5 appears to do little except be a major memory lag. The older LW 4 seemed to handle things better. The LW 5 Library records every single file in a similar way to shared & incomplete files. This is really unnecessary information & a waste of memory. A Library with a very large number of files can contribute to out of memory crashes. For those of you who do not know, LW records the Library files in identical fashion to the files you are sharing, thus .. if you are sharing 1,000 files and your Library has 20,000 files, then it has the same effect on LW as having an overall sharing total of 21,000 files. Now you might begin to get the picture of why the Library concept was poorly thought out. My Library reached 30,000 at one point, and sharing lots more, you can imagine the effect.

Limewire 5.5/5.6/LPE is probably the only gnutella client I've ever come across that does not tell you which gnutella client & version you are downloading from or uploading to or identify which clients show up in search results. (exception of client that I have tried was FilesWire, a browser client which was a freeloader client; ie: a gnutella file downloader only, similar to how the earlier flashdownloader & a few others which are torrent downloaders only.) Only way to check the client & version of uploaders is via the Get Info for the uploaded file at bottom of the Transfers tab window. I think it was LW 5.4 & earlier did give more information.

The removal of the upload slots per person for LW 5 means the only option for handling some greedy clients is either to reduce overall bandwidth or slots or both, and has resulted in unnecessary bannings. I personally dislike persons browsing me, then hammering the heck out of my upload slots. If it were music they chose I wouldn't care. My upload slots are too busy to allow one person to get greedy with them. Last year, discussions with LW devs didn't seem to get far on this topic, yapping to closed ears lol. What the heck does one have to do to prevent someone attempting to download 5-15 videos at once, thus plugging up all my upload slots for several days on end. It does make me feel suspicious at times, I've heard anti-P2P'er organisations sponsored by the RIAA will do this to prevent files being shared to the public. It annoys the heck out of me when people try download 3 or more videos each at once. ******, what am I, the video store. I find it is mostly Japanese Cabos users who try to fill all my upload slots for days on end downloading endless albums and becomes obvious when they later choose totally unrelated music or just choose all types of music at once with 100+ download requests. Well, one of the Sony directors is a director for the RIAA, so of course they have their own anti-file-sharing companies over there.

The Queuing function for uploads/downloads works differently in LW5/LPE compared to LW4. LW 5 gives favoritism to first host in queue, not first file in the queue unlike all other gnutella clients. Thus, the anti-file-sharing groups can fill up all your upload slots for days on end and they do this I can confirm. If someone has been constantly downloading multiples files, their new downloads will surpass others whom have been waiting in queue. In LW 4, it was first come first served. Depending on who arrived first in the queue. LW 5's queueing works somewhat differently. If someone has been previously downloading, they appear to get preference over someone who has been in the queue for a while. I see both good and bad points about this approach. (the Morpheus v.4 client used to be a queue jumper, pushing those above them out of the queue until they reached the top very quickly. Not sure what effect they would have with LW 5/LPE. But then, I suspect Morpheus is banned from connecting to LW.) The queuing function and upload slots handling is very buggy. I've seen people half-way through downloading multiple files stopped and the message says upload limit reached and seems to ban them. As mentioned earlier, these functions are quite buggy and unreliable. The queuing function in LW 5 is totally screwy. There are not enough wait slots compared to upload slots. Thus people get thrown off the queue with message, 'Unable to Upload: upload limit reached'.

Search results do not supply the full list of available peers with a particular file. Classic or List view seems to make no difference. Perhaps LPE is not updating the figures as it finds them. I know Library & Shared windows can be slow to update sometimes for uploads (hits seems fine.) (Clicking or getting info on the file in library helps.) But for number of peers in search results, LW 4 would update as it finds them when late-coming ones arrive, LW 5 only seems to post/list the initial find. For example, try a Find More Results and LPE will not update the figures with more peers it finds. LW 4 always did. I suspect this is more of a LW 5.5 bug. I vaguely recall (I might be wrong) the updating of figures of peers found worked a little more efficiently in earlier LW 5 versions.

Search results - Word Filter - I have T-10 to T-99 filtered out so I do not receive incomplete files in my search results. However I still do receive them. I am guessing either the word filter no longer works with the dash "-" character or the LW devs changed the word filter to only work with specific words, and no longer filters out partial words. Does filtering out T-19 or similar work for anybody else? Example, T-1921831592-[AV]……avi still shows for me. Of course it's pointless downloading someone's incomplete file they have shared accidentally. lol Sample image below:
Attachment 5673

Files you share in Search Results do not necessarily show as having previously downloaded them. I have found files I put up for share (& even created) & found them in search results. It should show that I already have those files, but does not always show that. Quite often not. Just a good example when it's my own files that are not being recognised as already having them in search results. Of course, found same issue with some other files I had previously downloaded. This has happened with different kinds of media files, not only music or video. I do not think LW 4 would make that same error so often.

Opening the View File Info ... window frequently seems to add considerably to the memory drag/lag that eventually climbs up, again due to Java memory issues. This same issue applies to using the "View File Info..." on uploaded/uploading files / downloading files / Library or Shared files. The window eventually becomes very slow to open, and may be white for a while before showing the actual details. I find this is often the catalyst for JavaOutOfMemory errors. (Browsing host is another major catalyst, especially if you actually succeed in the browse & the host has lots of files.)

Custom File Descriptions for Shared files seems to vanish by itself after a few weeks or a couple months. And I mean custom descriptions given for all types of files. LW seems to struggle to maintain this information. It's a PITA having to repeatedly re-add the year, rating and genre of all my videos and other files.

Extended Tooltips in the Advanced Tools does not work. Seems to be broken, on the Mac version LPE at least.

In comparison to LW 4, there's no Chat function, no Direct Connect (unless friends function), less abilities to add descriptions to shared files & no option to add description to video files, .mv4 files are not considered as video files when this is the default format for iPod, iPhone, iPad, iTV & is a video file extension that has existed since several years before LW 5. LW5/LPE has no extended tooltips, no option to see details simply by hovering cursor over the file in search results. Cannot see ip details of users (one of a very few gnutella programs that limits this). Less window formatting options compared to LW4. No ability to change skins like LW 4 had.

LW never was one of the best Gnutella clients for Browsing another host's files from what I've noticed with using other clients. LW's browse from upload window is somewhat incompetent & highly unreliable. Browsing seems to use up a lot of the LW resources. Too many browses and the JavaOutOfMemory error beckons closer. Browse someone who is sharing more than 2,000 files & there is a high risk of a crash due to the way the information over-loads Java in the way this information is processed. Sometimes it is not possible to browse someone you are downloading from because LW decides it does not know who it is .. "unknown" message. Since when does a gnutella client not know who it is downloading from. sighs lol duh

I've noticed LW seems a little overcome with its memory handling. Here's an example: highly greedy host, ban them, they continue downloading, more & more. Reduce upload slots .. no difference .. reduce upload slots to zero, no difference, they continue downloading more files after the others have finished, as though my change made no difference after several minutes and many downloads. Manually add their ip address to the ban list, no difference. lol Only thing that made a difference was reducing upload bandwidth. And a few times I've seen the same banned host return another day in another session the following day despite being supposedly banned. I guess the limewire.props file gets too big for LW to search & write to. ie: my suggestion in a phex thread about how certain information should be separated into different preference lists. Because programs can have difficulty searching lines of text if there are a large number of lines or/and very large paragraphs. I do not believe Java does a very good job at it, but not only java for that matter.

(And reducing bandwidth can take a while to take effect sometimes. .. this gets back to my gripes about the loss of the upload slots per person which LW 4 had. I should not need to reduce overall upload slots or bandwidth, that's a ridiculous desperate step to take. (But I do find it has an effect on the greedy because they tend to be impatient for fast multiple downloads.) And as for the banned hosts not being banned, in any case, I do rather commonly ban only for that session & remove manually the following day. This is coincidentally an option Phex has to ban only for the session .. which is Phex's default.)

Not sure if this is related to the poor memory handling errors I get reasonably often. Such as .. "Java.lang.OutOfMemoryError: PermGen space" logged in my console over and over so many times since start of year, just before LPE crashes. Java programmers know how to fix this, as I researched the answer from multiple places including the Java site. duh lol Get n do it team! Console report: [0x0-0x82082].com.limegroup.gnutella[966] Caused by: java.lang.OutOfMemoryError: PermGen space

The HIDE command on OSX seems unreliable with LPE. It often just jumps back into view, repeatedly. Not sure I've ever had an OSX application that's behaved repeatedly like that before. Though may have suffered similar with earlier LW 5 versions, memory avoids me at moment.

Ultrapeer mode once in a while breaks in dramatically, dropping too many peers (down to one or two) so connection goes haywire for 2-4 minutes, thus all activity of uploads & downloads & searches is affected / broken. (Each occasion making me think my router had crashed, until I checked my browser and the LPE connections window.)

On the topic of Ultrapeer mode, on some occasions I connect with LPE & it tells me I'm a leaf but behind a firewall. I restart LPE & I am an ultrapeer not behind a firewall. On odd occasions if LPE has been running for a very long time, it says I'm behind a firewall & connected to 22 peers. None of my other Mac p2p programs tell me I'm behind a firewall & this includes, Vuse, Transmission, GTK-Gnutella & Phex. I could always blame my router but why is it only LW that has this issue. I'd say overload in Java messages through the system at a guess so UPnP communication between LW & the router stumbles & stutters. See more about that below.

LW's Virus Definition Service - malware.VirusDefinitionManagerImpl.debug via file hash hammers the heck out of my OSX console. Useless piece of garbage if I am allowed to comment. lol Everyone get an anti-virus checker & not expect p2p developers to make one for you. sighs. And I use a Mac, I don't need that Anti-virus rubbish. As I said, at various times, this information 'floods' my console so much that my console limits the information because of the hammering per second. It also stops console reporting other things on the computer that are happening (such as the firewall.) This is a good thing? Hardly adding security of any nature thank you, to the contrary. I've also often seen this messaging not long before LW crashed. I know something is amiss when the firewall is unable to report to the console due to LW's massive amounts of messages it spams through the system & console at times.
OH and there's nothing like downloading a video file over 1 GB in size & having LW delete it because it thought it was dangerous. Very funny. Previewed fine for the 95+% done as the last time I checked it. Now makes me wonder about av false positives originally falsely reported to the LW team. Example: [0x0-0x72072].com.limegroup.gnutella[665] 1378292 DEBUG [Library Disk I/O Thread] malware.FileExtensionChecker.debug - Unknown mime type posted 55 times in a second to my console every session (actually it's many more sometimes .. so many console caps it.) Duh, LPE does not know the mime type. Didn't they include all kinds of mime types before implementing? I suspect this might be one area the file-checker is making errors on valid files. [0x0-0x8f88f8].com.limegroup.gnutella[12808] 10281238 DEBUG [ManagedDownload] malware.FileExtensionChecker.debug - Unknown mime type
(LW cannot detect all the information on all kinds of video which is obvious via the lack of information it gives. Example: not being able to detect duration or video dimensions on some file types.)

Oh, and had a 1.8 GB video file deleted at 99.9% the other day because it said it was corrupted. Played fine again all way up to that point. Many gnutella apps have a specific corrupted files folder. From memory, LW 4 did not delete so-called corrupt files. After re-attempting to download the corrupted part a few times LW 4 would simply give up on it but not delete it. LW 4 would then mark the file name with [corrupt] at the beginning or end of the filename & leave it in the incomplete folder. I did not see LPE making any attempt to re-download the so-called corrupted portion, instead it simply deleted the 1.8 GB file. Nice huh.

As I was told by one of the LW staff 20 months ago, they were trying to appease the 'newbies', their quick buyers who know nothing. An easy-to-use interface. (I did understand their approach, they just lacked an understanding of their long-term users & what they enjoyed and desired.) Thus we end up with a basic program with little options. LW 4 loved by so many but forgotten by the LW devs. lol If there were no option for a Classic View mode, I suspect a greater number of persons would have reverted back to LW 4. LW has always had one of the easiest to understand interfaces of all the gnutella client programs, even since LW 2 (& presumably earlier.)

Edit: Ok maybe I should not continue on this. Seems to me the best thing to do would be to start from scratch. Too many broken or inefficient things in LW 5. Does not really matter what my thoughts are where to work on since I'm not a programmer in any of the java languages. But I do think some things should be removed such as the so-called file-checker. And the Java memory stamp increased, daily javaoutofmemory errors are a PITA & makes me wonder why I use it. Or is everyone supposed to only have 50 or less files to share or be a freeloader to escape the memory issues. LW 4 is looking merrier for a return. Now 12 months full-time on LPE. sighs. You'd need to look back at LW 5.4 & 5.3 to pick out / regain some of the things the LW team partly took out to appease the RIAA, etc. And prior to 5.3 LW was basically a skeleton. I have doubts anybody will read this so it's all irrelevant. lol :P Where's all the Java programmers gone? Nobody seems interested. Building more & more clones? sighs I'd never write a p2p app in java.

LW 5 was a really poorly thought out, planned and executed part of the LW's existence. LW 5 should never have been released to the public before version 5.3 at the very least. If they wanted to release a simplified program for no-brainers, they only had to look at Cabos which is as simple as it gets and uses the LW code. LW 5 is a highly frustrating program for anybody who ever used LW 4 which had advanced tools. 2-3 months after I joined the forum in 2004 I requested a size-filter for search results (as did many others around the time). Other clients already had a size filter at the time as it happened. But it took LW over 5 years to introduce one and it never made it into LW 4 which was a pity. It's one of the few improvements LW 5 had over LW 4. lol

LW 4 was put together over time by a combination of LW devs and code contributors from the community. A very large percentage of LW 4 was developed via the community at large. LW 5 on the other hand was the LW devs alone trying to re-write the program. Seems they became lost at kindergarten stage. lol Thanks for all the bugs. (And lack of tools.)

Yes, a dedicated LW user of many years showing their frustration in my tone in this post, I do apologise for the rant. This post should have sounded impartial. I started using LW with version 2 in 2002.