thanks et voilà --figured the refugee(s) had a lot in common: the fairly literate writing (despite the bitterness) had much the same voice.

Actually, I wondered if "they" were Bearshare and/or Raza refugees, whom I wish well. The deterioration of those groups and their forums is a pretty sad dissipation of much knowledge. "They" make decent beta-testers too since they've found many of the bugs already noted.

Anyway, good to see the changelog trying to keep up the developments: there have been so many changes to the code and the law that I'm pretty impressed with how well LW is coping.

re - Media player enabling and disabling no longer requires restart. Good! that explains why it worked on OS X today.

re License column: some of the older magnetmix tunes still don't show licences: can they be added?

-I'm still having problems with checkmarks not updating in inactive search results or parts of the active search tab's window when it is scrolled elsewhere. Thought it was an OS X problem

-using command-click for discontiguous selections still is a problem if the screen is scrolled.

-Is the update mechanism still a Windows-only feature?

Anyway, thanks for the changelog Sam--it does help focus what to test for.

Cheers all: 2.7.13 was the highest I can recall for a beta: I hope 4.9.14 can break that record and 5.0 will come out on LW's official 5 year annivesary :D

shaisse! I missed it. Did anybody catch the netsize count today (July 12)?

It set a new record :D

Here's something no one else commented on, that started with the beta 4.9.0 and persisted to 4.9.1.

If a lot of files end up "waiting for busy hosts", instead of all sitting showing that (as in every version I ever used before these betas), they keep jumping about between waiting and queued. Five of them seem to be waiting at any given time and the rest queued, but the number seems to sometimes be lower, especially if you have a file actually downloading by some miracle, or something is waiting in line.

Also, waiting in line seems to be a useless distinction from waiting for busy hosts. Maybe if the queue position actually decreased monotonically and then the file actually downloaded, it would be different, but as things stand it means exactly the same thing. The file will download whenever -- or never. It's as likely to go from position 3 to position 7, or to "busy", or even "awaiting sources" as it is to go to position 2 in my experience, just as an example.

The distinction between "need more sources" and "awaiting sources" seems equally meaningless. Both seem to mean the same thing: there's no host on the network right now with the file, at least within your horizon. The only differences whatsoever seem to be that a file you used "find sources" on will show "awaiting sources" but one you didn't will show "need more sources", and files that show "awaiting sources" won't do anything until you restart limewire -- they won't find more sources, they won't resume (sometimes they flicker to queued and then right back to awaiting sources, but that's it), and they won't do anything else either except take up space in the GUI. Why is this? It seems pointless. They should be resumable, or else find-sourcable, without having to restart Limewire first. I thought we were trying to encourage people to leave their clients running for a long time? Yet currently, doing so and continuing to try to get a file you want are mutually exclusive for no reason I can fathom.

As if that wasn't enough, even beta 4.9.1 still hasn't fixed the problem with downloads that hang at 100%, downloads that simply stop, downloads that suddenly change into busy signals instead of finishing, downloads that have insanely low throughputs (a few bits per second, I believe, is the record so far -- the file was less than 100K with an estimated time of arrival in the vicinity of 3 days), and downloads that keep on cycling between downloading, waiting for busy hosts, queued, and downloading, apparently at regular fractions of the file completed (e.g. 33 and then 67%, or 25, 50, and 75, or 20, 40, 60, and 80). What gives with these? The file should download so long as you and the remote host are both still online. And if the file stops downloading, but starts again in a very short time, it's fairly clear the remote host remained online the whole time, but for some reason the download did not continue the whole time.

And of course there are the files that you find, double click, watch download to 66% and then watch "awaiting sources". This shouldn't happen. If it could get two thirds of the file there's no reason it couldn't get the whole file, unless the other side genuinely went offline, which doesn't seem to be the case, since fairly often when I see this happen other files in the same series and presumably hosted on the same machine are busy, waiting in line, or even out-and-out downloading. A related phenomenon seems to be when you see a bunch of files you want that seem to be related, select them all for download, and get exactly three while the rest "need more sources". You find sources, get exactly three, and the rest await sources. Then you restart Limewire, get another three, and the rest "need more sources". And so on. It's as if Limewire decides that if a remote host will only send three files at a time (which is quite common, and Limewire's own default behavior) to the same downloader, that the others aren't busy but in fact have vanished entirely from the network. Searching for them finds them again, but again it gets three and decides the remainder have vanished from the network. It should treat them as busy, not nonexistent, and the paradoxical thing is that sometimes it does treat them as busy. The problem is compounded by the inability to find more sources for "awaiting sources" files, which makes you have to restart limewire every six files in cases like this. You end up spending more time watching limewire start up and watching it shut down than you do watching files actually downloading, and your own shared files become only sporadically available.

So the whole file status thing is basically broken as things currently stand. Waiting in line and busy mean the same thing. Need more sources and awaiting sources mean the same thing, and both mean that while limewire thinks there are no sources inside its horizon with the file, it may have mistakenly classed some as having no sources that actually have (busy) sources, and the file should really be showing the busy status.

I might add that 4.8.1 didn't have the problem of downloads hanging at 100% and that the betas haven't fixed an additional problem -- files sometimes become "busy" and get stuck that way until you resume them manually, instead of retrying automatically after a while, as evidenced when you waiting a few minutes and none of them download, then select them all and hit resume and watch half a dozen of them promptly download.

ive been downloading at speeds over 250 KB/s with 4.8.1... i think your connection just sucks :x

Some CVS console errors i have received (when limewire crashes):

Exception occurred during event dispatching:
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
Exception occurred during event dispatching:
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
Exception occurred during event dispatching:
java.lang.OutOfMemoryError: Java heap space
Exception occurred during event dispatching:
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space

...this error goes on forever...

Ignoring error:
java.lang.OutOfMemoryError: Java heap space
Ignoring error:
java.lang.OutOfMemoryError: Java heap space

---

java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
com.limegroup.gnutella.AssertFailure: trying to release an interval 1553216-1572
863 that wasn't leased verified:[]
partial:[0-98303, 131072-470015, 524288-708607, 786432-1312767, 1572864-1789951,
2097152-2316287, 2621440-2820095, 3670016-3731455]
discarded:[]
pending:[98304-131071, 470016-510387, 708608-786431, 1312768-1554239, 1789952-20
12159, 2316288-2614271, 2820096-2998271, 3145728-3233203, 3731456-4007935]
leased:[510388-524287, 1554240-1572863, 2012160-2097151, 2614272-2621439, 299827
2-3145727, 3233204-3670015, 4007936-4340074]
at com.limegroup.gnutella.Assert.that(Assert.java:30)
at com.limegroup.gnutella.downloader.VerifyingFile.re leaseBlock(Verifyin
gFile.java:302)
at com.limegroup.gnutella.downloader.DownloadWorker.r eleaseRanges(Downlo
adWorker.java:431)
at com.limegroup.gnutella.downloader.DownloadWorker.c onnectAndDownload(D
ownloadWorker.java:372)
at com.limegroup.gnutella.downloader.DownloadWorker.r un(DownloadWorker.j
ava:206)
at java.lang.Thread.run(Unknown Source)
at com.limegroup.gnutella.util.ManagedThread.managedR un(ManagedThread.ja
va:60)
at com.limegroup.gnutella.util.ManagedThread.run(Mana gedThread.java:49)
com.limegroup.gnutella.AssertFailure: trying to release an interval 2970908-3145
727 that wasn't leased verified:[0-1310719, 1572864-1835007, 3145728-3670015, 39
32160-4194303]
partial:[1310720-1562623, 1835008-1983487, 2097152-2235391, 2359296-2398207, 445
6448-4472507, 4718592-4874239, 4980736-5192703, 5767168-5820415]
discarded:[]
pending:[1562624-1572863, 1983488-2097151, 2235392-2359295, 2398208-2564511, 262
1440-2863519, 2883584-2971931, 4472508-4702211, 4874240-4980735, 5192704-5242879
, 5505024-5548031, 5820416-6015219]
leased:[2564512-2621439, 2863520-2883583, 2971932-3145727, 4702212-4718591, 5548
032-5767167, 6015220-6029311, 6291456-6553599]
at com.limegroup.gnutella.Assert.that(Assert.java:30)
at com.limegroup.gnutella.downloader.VerifyingFile.re leaseBlock(Verifyin
gFile.java:302)
at com.limegroup.gnutella.downloader.DownloadWorker.r eleaseRanges(Downlo
adWorker.java:431)
at com.limegroup.gnutella.downloader.DownloadWorker.c onnectAndDownload(D
ownloadWorker.java:372)
at com.limegroup.gnutella.downloader.DownloadWorker.r un(DownloadWorker.j
ava:206)
at java.lang.Thread.run(Unknown Source)
at com.limegroup.gnutella.util.ManagedThread.managedR un(ManagedThread.ja
va:60)
at com.limegroup.gnutella.util.ManagedThread.run(Mana gedThread.java:49)
java.lang.OutOfMemoryError: Java heap space
com.limegroup.gnutella.AssertFailure: trying to release an interval 4185088-4194
303 that wasn't leased verified:[]
partial:[0-80895, 131072-1014631, 1048576-1512447, 1572864-1942527, 2097152-2351
103, 2621440-3108863, 3670016-3909927, 4194304-4565275]
discarded:[]
pending:[80896-131071, 1014632-1048575, 1512448-1572863, 1942528-2097151, 235110
4-2501466, 3108864-3396131, 3909928-4186111, 4565276-4742599]
leased:[2501467-2621439, 3396132-3670015, 4186112-4194303]
at com.limegroup.gnutella.Assert.that(Assert.java:30)
at com.limegroup.gnutella.downloader.VerifyingFile.re leaseBlock(Verifyin
gFile.java:302)
at com.limegroup.gnutella.downloader.DownloadWorker.r eleaseRanges(Downlo
adWorker.java:431)
at com.limegroup.gnutella.downloader.DownloadWorker.c onnectAndDownload(D
ownloadWorker.java:372)
at com.limegroup.gnutella.downloader.DownloadWorker.r un(DownloadWorker.j
ava:206)
at java.lang.Thread.run(Unknown Source)
at com.limegroup.gnutella.util.ManagedThread.managedR un(ManagedThread.ja
va:60)
at com.limegroup.gnutella.util.ManagedThread.run(Mana gedThread.java:49)
java.lang.OutOfMemoryError: Java heap space
com.limegroup.gnutella.AssertFailure: trying to release an interval 2500443-2621
439 that wasn't leased verified:[]
partial:[0-80895, 131072-1014631, 1048576-1512447, 1572864-1942527, 2097152-2351
103, 2621440-3108863, 3670016-3909927, 4194304-4565275]
discarded:[]
pending:[80896-131071, 1014632-1048575, 1512448-1572863, 1942528-2097151, 235110
4-2501466, 3108864-3396131, 3909928-4186111, 4565276-4742599]
leased:[2501467-2621439, 3396132-3670015, 4186112-4194303]
at com.limegroup.gnutella.Assert.that(Assert.java:30)
at com.limegroup.gnutella.downloader.VerifyingFile.re leaseBlock(Verifyin
gFile.java:302)
at com.limegroup.gnutella.downloader.DownloadWorker.r eleaseRanges(Downlo
adWorker.java:431)
at com.limegroup.gnutella.downloader.DownloadWorker.c onnectAndDownload(D
ownloadWorker.java:372)
at com.limegroup.gnutella.downloader.DownloadWorker.r un(DownloadWorker.j
ava:206)
at java.lang.Thread.run(Unknown Source)
at com.limegroup.gnutella.util.ManagedThread.managedR un(ManagedThread.ja
va:60)
at com.limegroup.gnutella.util.ManagedThread.run(Mana gedThread.java:49)
com.limegroup.gnutella.AssertFailure: trying to release an interval 220160-26214
3 that wasn't leased verified:[]
partial:[0-121399]
discarded:[]
pending:[121400-221183, 524288-624619]
leased:[221184-262143, 624620-786431]
at com.limegroup.gnutella.Assert.that(Assert.java:30)
at com.limegroup.gnutella.downloader.VerifyingFile.re leaseBlock(Verifyin
gFile.java:302)
at com.limegroup.gnutella.downloader.DownloadWorker.r eleaseRanges(Downlo
adWorker.java:431)
at com.limegroup.gnutella.downloader.DownloadWorker.c onnectAndDownload(D
ownloadWorker.java:372)
at com.limegroup.gnutella.downloader.DownloadWorker.r un(DownloadWorker.j
ava:206)
at java.lang.Thread.run(Unknown Source)
at com.limegroup.gnutella.util.ManagedThread.managedR un(ManagedThread.ja
va:60)
at com.limegroup.gnutella.util.ManagedThread.run(Mana gedThread.java:49)
com.limegroup.gnutella.AssertFailure: trying to release an interval 4015104-4194
303 that wasn't leased verified:[]
partial:[0-99327, 131072-470015, 524288-708607, 786432-1312767, 1572864-1789951,
2097152-2317311, 2621440-2821119, 3670016-3732479]
discarded:[]
pending:[99328-131071, 470016-518579, 708608-786431, 1312768-1554239, 1789952-20
18303, 2317312-2614271, 2821120-3006463, 3145728-3233203, 3732480-4016127]
leased:[518580-524287, 1554240-1572863, 2018304-2097151, 2614272-2621439, 300646
4-3145727, 3233204-3670015, 4016128-4340074]
at com.limegroup.gnutella.Assert.that(Assert.java:30)
at com.limegroup.gnutella.downloader.VerifyingFile.re leaseBlock(Verifyin
gFile.java:302)
at com.limegroup.gnutella.downloader.DownloadWorker.r eleaseRanges(Downlo
adWorker.java:431)
at com.limegroup.gnutella.downloader.DownloadWorker.c onnectAndDownload(D
ownloadWorker.java:372)
at com.limegroup.gnutella.downloader.DownloadWorker.r un(DownloadWorker.j
ava:206)
at java.lang.Thread.run(Unknown Source)
at com.limegroup.gnutella.util.ManagedThread.managedR un(ManagedThread.ja
va:60)
at com.limegroup.gnutella.util.ManagedThread.run(Mana gedThread.java:49)
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
com.limegroup.gnutella.AssertFailure: trying to release an interval 4158900-4194
303 that wasn't leased verified:[262144-2097151, 2883584-3145727, 3407872-367001
5, 4194304-4456447]
partial:[0-71679, 131072-262143, 2097152-2336374, 2359296-2478799, 2621440-28262
39, 3145728-3239935, 3670016-3730279, 4980736-4983807, 5242880-5336631]
discarded:[]
pending:[71680-80895, 2336375-2359295, 2478800-2621439, 2826240-2883583, 3239936
-3407871, 3730280-3883443, 3932160-4159923, 4456448-4473855, 4718592-4918119, 49
83808-5242879, 5336632-5505023]
leased:[3883444-3932159, 4159924-4194303, 4473856-4718591, 4918120-4980735]
at com.limegroup.gnutella.Assert.that(Assert.java:30)
at com.limegroup.gnutella.downloader.VerifyingFile.re leaseBlock(Verifyin
gFile.java:302)
at com.limegroup.gnutella.downloader.DownloadWorker.r eleaseRanges(Downlo
adWorker.java:431)
at com.limegroup.gnutella.downloader.DownloadWorker.c onnectAndDownload(D
ownloadWorker.java:372)
at com.limegroup.gnutella.downloader.DownloadWorker.r un(DownloadWorker.j
ava:206)
at java.lang.Thread.run(Unknown Source)
at com.limegroup.gnutella.util.ManagedThread.managedR un(ManagedThread.ja
va:60)
at com.limegroup.gnutella.util.ManagedThread.run(Mana gedThread.java:49)
com.limegroup.gnutella.AssertFailure: trying to release an interval 5192704-5242
879 that wasn't leased verified:[0-1835007, 2097152-2359295, 3145728-3407871, 41
94304-4456447]
partial:[1835008-2026171, 2359296-2557951, 2621440-2656803, 2883584-3056923, 340
7872-3529839, 3670016-3887103, 4980736-5038079, 5505024-5547139]
discarded:[]
pending:[2026172-2097151, 2557952-2621439, 2656804-2743731, 3056924-3145727, 352
9840-3670015, 3887104-4042447, 4456448-4471977, 4718592-4878335, 5038080-5193727
, 5242880-5379591, 5547140-5940507]
leased:[2743732-2883583, 4042448-4194303, 4471978-4718591, 4878336-4980735, 5193
728-5242879, 5379592-5505023, 5940508-6053471]
at com.limegroup.gnutella.Assert.that(Assert.java:30)
at com.limegroup.gnutella.downloader.VerifyingFile.re leaseBlock(Verifyin
gFile.java:302)
at com.limegroup.gnutella.downloader.DownloadWorker.r eleaseRanges(Downlo
adWorker.java:431)
at com.limegroup.gnutella.downloader.DownloadWorker.c onnectAndDownload(D
ownloadWorker.java:372)
at com.limegroup.gnutella.downloader.DownloadWorker.r un(DownloadWorker.j
ava:206)
at java.lang.Thread.run(Unknown Source)
at com.limegroup.gnutella.util.ManagedThread.managedR un(ManagedThread.ja
va:60)
at com.limegroup.gnutella.util.ManagedThread.run(Mana gedThread.java:49)
com.limegroup.gnutella.AssertFailure: trying to release an interval 3882420-3932
159 that wasn't leased verified:[262144-2097151, 2883584-3145727, 3407872-367001
5, 4194304-4456447]
partial:[0-71679, 131072-262143, 2097152-2336374, 2359296-2478799, 2621440-28262
39, 3145728-3239935, 3670016-3730279, 4980736-4983807, 5242880-5336631]
discarded:[]
pending:[71680-80895, 2336375-2359295, 2478800-2621439, 2826240-2883583, 3239936
-3407871, 3730280-3883443, 3932160-4159923, 4456448-4473855, 4718592-4918119, 49
83808-5242879, 5336632-5505023]
leased:[3883444-3932159, 4159924-4194303, 4473856-4718591, 4918120-4980735]
at com.limegroup.gnutella.Assert.that(Assert.java:30)
at com.limegroup.gnutella.downloader.VerifyingFile.re leaseBlock(Verifyin
gFile.java:302)
at com.limegroup.gnutella.downloader.DownloadWorker.r eleaseRanges(Downlo
adWorker.java:431)
at com.limegroup.gnutella.downloader.DownloadWorker.c onnectAndDownload(D
ownloadWorker.java:372)
at com.limegroup.gnutella.downloader.DownloadWorker.r un(DownloadWorker.j
ava:206)
at java.lang.Thread.run(Unknown Source)
at com.limegroup.gnutella.util.ManagedThread.managedR un(ManagedThread.ja
va:60)
at com.limegroup.gnutella.util.ManagedThread.run(Mana gedThread.java:49)
com.limegroup.gnutella.AssertFailure: trying to release an interval 6297600-6553
599 that wasn't leased verified:[0-1310719, 1572864-1835007, 3145728-3670015, 39
32160-4194303]
partial:[1310720-1565695, 1835008-1985535, 2097152-2236335, 2359296-2400255, 445
6448-4472507, 4718592-4874239, 4980736-5194751, 5767168-5820415]
discarded:[]
pending:[1565696-1572863, 1985536-2097151, 2236336-2359295, 2400256-2572703, 262
1440-2971931, 4472508-4718591, 4874240-4980735, 5194752-5242879, 5505024-5556223
, 5820416-6015219, 6291456-6298623]
leased:[2572704-2621439, 2971932-3145727, 5556224-5767167, 6015220-6029311, 6298
624-6553599]
at com.limegroup.gnutella.Assert.that(Assert.java:30)
at com.limegroup.gnutella.downloader.VerifyingFile.re leaseBlock(Verifyin
gFile.java:302)
at com.limegroup.gnutella.downloader.DownloadWorker.r eleaseRanges(Downlo
adWorker.java:431)
at com.limegroup.gnutella.downloader.DownloadWorker.c onnectAndDownload(D
ownloadWorker.java:372)
at com.limegroup.gnutella.downloader.DownloadWorker.r un(DownloadWorker.j
ava:206)
at java.lang.Thread.run(Unknown Source)
at com.limegroup.gnutella.util.ManagedThread.managedR un(ManagedThread.ja
va:60)
at com.limegroup.gnutella.util.ManagedThread.run(Mana gedThread.java:49)
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space

---


java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
at java.util.HashMap$KeyIterator.next(Unknown Source)
at com.limegroup.gnutella.FileManager.loadSettingsInt ernal(FileManager.j
ava:700)
at com.limegroup.gnutella.FileManager$4.run(FileManag er.java:575)
at com.limegroup.gnutella.util.ProcessingQueue$Proces sor.run(ProcessingQ
ueue.java:105)
at java.lang.Thread.run(Unknown Source)
at com.limegroup.gnutella.util.ManagedThread.managedR un(ManagedThread.ja
va:60)
at com.limegroup.gnutella.util.ManagedThread.run(Mana gedThread.java:49)
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
at java.util.HashMap$KeyIterator.next(Unknown Source)
at com.limegroup.gnutella.FileManager.loadSettingsInt ernal(FileManager.j
ava:700)
at com.limegroup.gnutella.FileManager$4.run(FileManag er.java:575)
at com.limegroup.gnutella.util.ProcessingQueue$Proces sor.run(ProcessingQ
ueue.java:105)
at java.lang.Thread.run(Unknown Source)
at com.limegroup.gnutella.util.ManagedThread.managedR un(ManagedThread.ja
va:60)
at com.limegroup.gnutella.util.ManagedThread.run(Mana gedThread.java:49)

---

1. Icons in search results still have trouble updating to the correct icon.

2. Alot of the times, LimeWire says it cannot rename a file because it may be in use by another application. although this is false, the file is not being used by another application and is not being uploaded at the moment.

3. request: A right click option to force-start a queued upload.

4. The direct connect text box is limited in length, i dont know why this should be, because dns names can be longer than what is currently allowed.

5. request: limewire should have an option to allow and specify certain files and folders that are allowed to be shared to users that are not sharing (aka freeloaders).

6. Sometimes quiting LimeWire while a download is active will result in that download being corrupted. (this could possibly relate to 100% bug?)

7. Sometimes upon restart, LimeWire shares subfolders of shared folders that i explicitly stopped sharing. This happens frequently with CVS version.

8. I receive this error quite frequently with the cvs version: Sorry, LimeWire was unable to restart your old downloads.

9. request: i dont know if this is feasible, but i think limewire should show how many other users are in a swarm of a particular file being shared to that user in the uploads window.

10. Im reposting this one as it is semi-important: Folders in the library should be sorted first alphabetically, then files next. Intermixing the 2 are just annoying as hell. aswell as non-conventional.

11. The libraries own "Individually Shared Files" are not removed from this group if its containing folder is then shared.

---

also, i have not seen many of my comments, requests and bug reports being taken into consideration, noted or fixed. :(
but thanks anyways!

Yeah, the LimeWire developers are are just plain lazy these days.

regarding the console error, do a cvs update because the problem has been fixed.

SMACK!! :)

We are looking into things Ultracross, and are acutely aware of these issues. All your help and reports are appreciated.

lol. well, actually im always up-to-date on cvs.

i download new commits nightly via cvs on eclipse, compile and run.

btw some more errors:

[Fatal Error] :1:211: An invalid XML character (Unicode: 0x1c) was found in the
value of attribute "year" and element is "audio".
[Fatal Error] :1:211: An invalid XML character (Unicode: 0x1c) was found in the
value of attribute "year" and element is "audio".
[Fatal Error] :1:211: An invalid XML character (Unicode: 0x1c) was found in the
value of attribute "year" and element is "audio".
[Fatal Error] :1:211: An invalid XML character (Unicode: 0x1c) was found in the
value of attribute "year" and element is "audio".
[Fatal Error] :1:211: An invalid XML character (Unicode: 0x1c) was found in the
value of attribute "year" and element is "audio".
[Fatal Error] :1:211: An invalid XML character (Unicode: 0x1c) was found in the
value of attribute "year" and element is "audio".
...
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
com.limegroup.gnutella.AssertFailure: downloaded false worker failed DownloadWor
ker -> <65.28.19.60:6349, /uri-res/n2r?urn:sha1:loozsodnklnq3mv4yd4tgbcs5oxbe3lt
>hashcode 14459492 will release? false interrupted? false active? false initial
reading 0 initial writing 0 amount to read 0 amount read 0 all workers: Download
Worker -> <65.28.19.60:6349, /uri-res/n2r?urn:sha1:loozsodnklnq3mv4yd4tgbcs5oxbe
3lt>hashcode 14459492 will release? false interrupted? false active? false initi
al reading 0 initial writing 0 amount to read 0 amount read 0DownloadWorker -> <
24.150.101.104:6346, /uri-res/n2r?urn:sha1:loozsodnklnq3mv4yd4tgbcs5oxbe3lt>hash
code 6082815 will release? true interrupted? false active? true initial reading
5242880 initial writing 5242880 amount to read 233600 amount read 233600Download
Worker -> <66.177.163.85:6346, /uri-res/n2r?urn:sha1:loozsodnklnq3mv4yd4tgbcs5ox
be3lt>hashcode 12455855 will release? true interrupted? false active? true initi
al reading 6291456 initial writing 6291456 amount to read 262144 amount read 253
400worker not startedworker not startedworker not startedworker not started
at com.limegroup.gnutella.downloader.DownloadWorker.c onnectAndDownload(D
ownloadWorker.java:379)
at com.limegroup.gnutella.downloader.DownloadWorker.r un(DownloadWorker.j
ava:206)
at java.lang.Thread.run(Unknown Source)
at com.limegroup.gnutella.util.ManagedThread.managedR un(ManagedThread.ja
va:60)
at com.limegroup.gnutella.util.ManagedThread.run(Mana gedThread.java:49)
Caused by: com.limegroup.gnutella.AssertFailure: trying to release an interval 4
450304-4456447 that wasn't leased verified:[0-1835007, 2097152-2621439, 2883584-
4194303, 4718592-5242879, 5767168-6291455, 6553600-6815743]
partial:[1835008-2088959, 2621440-2812927, 4194304-4260863, 4456448-4608223, 524
2880-5472255, 5505024-5650059, 6291456-6356439, 6815744-6828863]
discarded:[]
pending:[2088960-2097151, 2812928-2883583, 4260864-4450303, 4608224-4718591, 547
2256-5505023, 5650060-5767167, 6356440-6544855, 6828864-6876715]
leased:[6544856-6553599]
at com.limegroup.gnutella.Assert.that(Assert.java:30)
at com.limegroup.gnutella.downloader.VerifyingFile.re leaseBlock(Verifyin
gFile.java:317)
at com.limegroup.gnutella.downloader.DownloadWorker.r eleaseRanges(Downlo
adWorker.java:440)
at com.limegroup.gnutella.downloader.DownloadWorker.c onnectAndDownload(D
ownloadWorker.java:377)
... 4 more
Terminate batch job (Y/N)? y

This occured while just downloading 3 videos at a time and it kept my cpu usage at 100% so i killed it before it burned up my cpu...

but thanks for keeping us alittle informed that things are being watched around here. i start to feel lonely when the devs are quietly hacking away without posting updates.

Re: Re: Severe bug in beta 4.9.1
 

Limewire proposes to download the file to the default download folder for the mediatype of the file.

Could you please check that the download folder for the mediatype of the file you're trying to download actually points to "C:\Program Files\LimeWire\Shared"?

You can verify this under Options->Saving.

Thanks

What's new in the beta 4.9.3? I noticed it's offered for download but the feature history page only goes up to 4.9.2. Is the current version's changes somewhere else and only previous versions on the history page, or something? If so, where?

I have a download hung at 100% completion right now. I'm using 4.9.2. I thought you said you'd fixed this!! argh

The beta (4.9.2) just died on me. It shows one green and four red bars and this won't change. If I tell it to disconnect it goes to five red bars. If I tell it to connect again only the first bar turns green. Search doesn't work, etc. It's been this way for half an hour now. Other network stuff works fine -- web browser for instance (where dya think this came from?). No firewall, and I didn't change any settings (firewall-related or otherwise) in limewire. It had been downloading merrily, and just became like this sometime while I was working on other things.

Why would it just stop working like that?

This just happened to me using the latest beta 4.9.4 -- Limewire dropped all four connections and refused to regenerate them. Every other network-using application continued to function normally -- web browser, etc -- and there had been no change to firewall/proxy/etc. settings (home broadband, so it wasn't someone else monkeying with the settings and disabling non-HTTP traffic or something). There is no proxy. There is a software firewall but it is instructed to leave limewire's traffic alone, and it hasn't been touched since when 4.9.4 was working normally. This has happened several times with all of the beta 4.9 series -- restarting Limewire seems to be the only recourse once this happens. Since restarting Limewire without touching anything else (firewall, rebooting Windows, whatnot) fixes the problem, it seems to be internal to Limewire.

Stderr console during one such incident with 4.9.4 shows a bunch of lines like this:
This is fairly serious since people having to constantly restart their clients is bad for the network, and likewise people being spuriously disconnected. Please have this fixed in 4.9.5.

What operating system are you using, and how are you starting LimeWire?

Were you using the computer at the time this happened, or did you away and just find limewire without any connections when you returned?

Also, did you try clicking Disconnect and then Connect?

Operating system: XP home.

Starting limewire:

C:\WINDOWS\system32\java.exe -Xmx255m -jar "C:\Program Files\LimeWire\LimeWire.jar"

(It really does seem to work better given that much mem)

Disconnect and then tell it to reconnect: as the other people who reported similar occurrences said, that doesn't seem to work. The connections tab just shows it open a batch of connections that just sit there "connecting" and counting up; then most of them disappear and are replaced; and so on.

I can see a "dud connection checker" killing connections that aren't actually doing anything useful, but why would it then refuse to or be unable to establish replacement connections? Or are the dud connections and the failure to establish new ones both symptoms of an underlying problem? Yet where would that problem be -- the network stack? Any problem outside Limewire would have affected other applications. Web surfing and other activities worked normally. Only the enabling of a firewall that blocked non-surfing traffic, such as the sort often found in workplaces, could be a) external to limewire and b) so thoroughly cripple it while leaving other network apps alone, and nobody could have done that since I'm the one running the home network here.

which version of java are you using? If it is not the latest 1.5.0_04, would mind trying that one?

1.5.0_03 apparently. How does it get updated to 1.5.0_04? The downloads at sun's site don't distinguish any further than "1.5.0", so do I have to wait for 1.5.1 or something?

It is available on "the other" java website:

http://javashoplm.sun.com/ECom/docs/...actionId=noreg

Why is there a second, non-obvious Java download site at sun.com that's needed to stay up to date???

Anyway I'll try it...

Too early to tell yet if the disconnection problem can still occur, but another problem is already apparent: sometimes Limewire hangs for a significant period of time with nearly no CPU use. It never used to freeze without nearly 100% CPU use. :) So it looks like it now hangs temporarily under a whole new set of circumstances using 4.9.4 and Java 1.5.0_04, hangs that didn't happen with 1.5.0_03.

Undownloadable files
 

Since around beta 4.9.1, every search seems to produce a handful of undownloadable results. They show stars or torn paper, and if you select them and hit "download" they don't change to folders, don't actually start downloading or anything, and no prompt pops up either (such as "overwrite this file?").

Also, since installing beta 4.9.4 I'm having odd problems previewing image files I've downloaded. The Windows previewer keeps showing "drawing failed" or getting hung "generating preview..." or "drawing image..." -- the images look fine when opened in a paint program so it's the previewer that's malfunctioning rather than the files being corrupt. (Besides, I have Lime set to automatically abort corrupted downloads.) When I switched to this Web browser window to report these problems, the browser acted funny too! The display only partly redrew, and buttons were missing from the toolbar and the Google search box was missing. This is with a recent version of Firefox. No error messages, just abnormal behavior. Eventually it redrew itself properly and I wrote this.

Nope. Didn't fix it. I went out for dinner, came home, and Limewire showed five red bars and the "you don't have an internet connection" dialog box. Of course, I have an always-on internet connection so this is patently ridiculous. Closing the dialog and telling it to "connect" sufficed to fix it however, without restarting the client. So maybe there's some improvement; although switching to Java 1.5.0_04 didn't stop the problem happening in the first place it may have made it easier to recover from.

(Sanity check: yes I could browse Web sites just fine both before I left and right when I got back. No, I hadn't changed anything -- in fact I wasn't physically present to have changed anything even accidentally, this time.)

Please update to the most recent beta (at this moment 4.9.4) http://www.limewire.com/english/content/beta.shtml

If you still have problems with drops in connections & end up disconnect or of poor connection please see beta 4.9.4 dropping connections

beta bugs
 

Here are some bugs introduced in beta 4.9.0 that are still present in 4.9.4.

• Hitting "resume" on a file "awaiting sources" no longer attempts to connect to known, but busy, sources of the file. Doing this caused Limewire 4.8.1 to make an honest fresh attempt to connect to most files, occasionally resulting in a download. In all of the betas, it does nothing whatsoever.
• Stderr console frequently shows warnings such as "ignoring cancelled key" that did not occur with LW 4.8.1. What impact the cause of these warnings has on the app's functionality is hard to determine but it's doubtful it's any good.
• For some reason, the sort order has been changed so that when downloads are sorted by status, files waiting in line no longer sort last. Busy ones now sort last, and files waiting in line sort second-to-last. This seems to be related to a change in the wording for files with busy sources.

Longest-standing headaches still present in betas that were also present in 4.8.1:

• Sorting by status makes download list items jump around -- which is OK until you try to select a specific item, and it always interprets your mouse click as occurring one jump later than it really did. The real problem is that mouse clicks seem to be ignored for a time, then treated as having just occurred, instead of processed immediately. Fix: Boost the UI event handling thread to highest priority to it preempts all other Limewire threads when a UI event is generated.
• Sorting a large download list by name is slow. What are you using -- bubble sort? Use quicksort -- it comes with the JDK so there's no excuse for using anything quadratic like bubble sort.
• Mem & CPU use are still high, though better in the recent betas.
• The icons on search results still all seem to mean the same thing, that being "It's anyone's guess whether you have the file already or not, and if not whether it's going to download quickly, slowly, never, or it already is". Is it even possible to get it working? The number of failed attempts so far suggests it might not be, in which case replacing them with something actually useful, such as bitzi ratings for the files, might be a better idea than trying to fix the current icon system.
• It still freezes for a short time sometimes when initiating a search, especially after a period of inactivity, and when downloads complete. Clearing a bunch of duds out of the download list with a mass select and cancel download, or with (do not click this button!) clear inactive, causes the UI to hang until you force-quit Limewire.
• There is still no "No to all" on the overwrite prompt, or "remember this decision" check box, or similar feature. It is sorely needed. (Unless by some miracle you get those icons working, especially so that green checks appear beside all and only the files you already have. Given the current track record, this seems unlikely -- all the failed attempts to fix those icons suggest there are deep technical reasons making fixing them lie somewhere between "difficult" and "impossible", whereas adding the requested functionality to the overwrite prompt is probably a two-minute job.)

Firewall detection bug
 

On a Windows XP box with Sygate Personal Firewall. Sygate has been told to let all Limewire traffic by unimpeded. Limewire has been told there's no proxy and no firewall. Beta 4.9.3 added the firewall detection thing in the status line. Beta 4.9.4 promptly broke it -- sometimes it shows "Limewire has detected a firewall" even though that's impossible on my setup. Sygate is configured to be transparent to Limewire, and Limewire has been told not to try to detect a firewall. How can this be happening?

The oddest thing is that despite incorrect firewall detection it actually seems to be downloading things and functioning OK.

Here's a strange one.

With recent betas, run a search for images and the media filter is likely to show "video" or "audio" as well as images as filtering options. Click the oddball media filter and the result list is pared down to ... not even an animated .gif, which might qualify as "video" in a technical sense. Just one or more ordinary jpegs.

But your priority should be getting Limewire 5 to have a user interface that is actually decently responsive. Limewire 4 or 3 anything seem to process input in batches, then store up but otherwise ignore input for a while, then process another batch. For example, trying to scroll through search results with a wheel mouse is an exercise in futility: first it won't budge, then it will start dancing up and down by itself and keep doing so for a while even if you take your hand completely off the mouse. Then when you go to scroll again it just sits wherever it landed ... the interface sometimes becomes almost totally unusable. Responding promptly to user input should take priority over whatever "thinking" an interactive application might do under the hood -- period. This kind of sluggish and frequently uncontrollable behavior is unacceptable, and that it has remained this prone to hangs, slowdowns, and ignoring-everything-you-do-for-five-minutes-then-trying-to-do-it-all-in-the-next-five-seconds through at least two major versions is unconscionable.

For a while now it's been impossible to clear out a large number of downloads without Limewire completely locking up. It's still the case with 4.9.4: the items disappear when you hit cancel or clear inactive, but the interface then stops responding. Task manager shows that Limewire has hung with 100% cpu use. If a stderr console is open it floods with lines like these:

The time given is wrong by exactly an hour -- the system clock when this one appeared was 10:27:34 PM.

Looks like clearing out downloads makes Limewire unload a semiautomatic directly into its own foot, resulting in the observed crash.

We'll try to reproduce this. Let us know:

* The speed of your computer (CPU, RAM, etc)
* Java version
* how many downloads approximately were there you tried to clear them

Couple GHz, 1GB RAM. Not top of the line but hardly pants either. And it's not like I'm trying to run the latest doom 3 expansion pack on it -- just network and productivity stuff mainly.



1.5.0_04 according to java -version. What's the _04 part mean anyway?

I don't know; a couple thousand?

Anyway the firehose stream of console warnings make me think whatever it fired into its foot may have been illegally converted for fully automatic fire. :P

4.9.7 bug
 

Here's a weird one: as of this AM, my 4.9.7 is bugging me to update. I've set it to notify me of any new versions, including betas. At the Web site: nothing. Still 4.8.1 on the main download page, and still 4.9.7 on the beta download page. No newer version than 4.9.7 exists, according to your Web site. Either the Web site is broken, or 4.9.7's update notification is broken. I think it's the latter, since it probably just checks the Web site to see what the latest version is, and wouldn't therefore know of an update if there was a 4.9.8 but the Web site had not been updated to reflect that fact.

Did Limewire open the website when you clicked "update now"?

I didn't click it. I went to the Web site manually in my browser. I don't trust links in apps to launch my choice of browser -- too many times when I have clicked a link like that, it's launched IE despite my system preferences setting, which is to launch Firefox. And given that I got a notice that a popup had been blocked when I went to the Limewire download page, it looks like I was wise indeed to ensure the browser I went there in was Firefox -- these days, just because a site never tried to spam you before is clearly no guarantee it won't suddenly start some day...

Hehe, you are very wise to use Firefox. The link we have at the bottom of LimeWire however should not try to open a browser - instead it should try to update LimeWire automatically. Give it a try and let us know how it goes.

I can tell you without even trying it that it won't work. Since the most recent version is still 4.9.7, it will either do nothing, produce an error message, or reinstall itself. But it won't update.

Unless the web site is for some reason not up to date?

Aborting...not by choice
 

I have always set large files to download overnight, but it seems now that I just upgraded to the latest version, files aborted themselves with no way for me to resume downloading. (ESPECIALLY frustrating when a 700mb file is 87% complete at the point of abort.)

Whats going on with that?

Why don't you give it a try and see?

Re: Aborting...not by choice
 

That will be fixed in the next beta which will be out later today. You may have seen a notification that an update is available - if so you can update to 4.9.8

RubberSideDown I'm just wondering if you one day came across a message saying a file was corrupt & answered no to continuing it & then ticked the option box to always use that answer. If you did, then it will always abort such a downld. The way to undo that would be to go to Tools>Options>View>Popups & tick Revert to Default. But if you are happy with that setting then leave it as is. It was just a thought! :)

You can rest assured that this mechanism is as secure as our website. It is protected by a private key which is just as secure as the server that hosts our website. It would be just as difficult for someone to compromise the viral update mechanism as it would be for them to hack our website and start distributing their trojaned version from there.

New Problem with .8
 

This time, I left it to download overnight and now it gives me internal errors and LimeWire is FROZEN...brrrr...

I can't even read, click or close the errors.

Is there somewhere I can download the OLD version? I never had any problems until i upgraded.

Thanks.

Tray on Linux
 

Hi !

I'm using LW 4.9.9

Tray on Linux works better than 4.8.1 but there are still problems..

Sometimes when I'm closing LW to tray he's still staying on the taskbar..

And when I'm trying maximize it from taskbar (it's still in tray) it looks like LW is death.. :

http://img273.imageshack.us/img273/3750/lw6bn.png

But really everything is ok, I have to only restore it not from taskbar but from tray, then LW is again alive :P

@aabbcc:

Could you get us a stack trace of LimeWire while its "frozen"? Instructions are on the sticky in this forum.

Thanks!

I wanna do this before, but unfortunately there is nothing.. ;[

I\m running LW, I'm minimizing it few times to tray and when it's staying on taskbar and it looks like it's "frozen" I'm restoring it from tray, normally closing and have only this :


and that's all !

Like I said it's not really frozen, it's problem with minimizing to tray..



P.S. I have LW "Other" version, because I don't have rpm-based distro..

What can I do else for help ?

Unfortunately not much.. we rely on a third-party library to provide support for the systray on linux and it acts up sometimes.

If you're interested in helping all java apps have better systray support for linux, the project is called JDIC (Java Desktop Integration Components) and its website is here: https://jdic.dev.java.net/

And azureus ?
He's wrotten in java too, is he using the same trat what LW ?

Azureus is running almost 24h/day at I, and I very often use its tray (some hundreds times/day) still minimizing and restoring and I have never (I'm using azureus over year) problem with azureus' tray..

they use a different library called SWT which we can't use for various reasons, at least not at the moment.

Within hours of updating to 4.9.9 from 4.9.7, several instances of "Disk Problem" have occurred; I had none during several days of using 4.9.7. No changes to settings, including directory permissions and download destination; the filesystem with the destination directory on it has nearly 2GB free, so it isn't a (legitimate) disk full error either.

Beta 4.9.9 still doesn't have accurate icons in search results. (Select a bunch of search results, hit download, and many of them still show stars -- most of which have actually successfully downloaded -- instead of folders or checks. Also, some torn paper items are simply ignored if you tell it to download them, etc.)

Beta 4.9.9 also still doesn't have accurate numbers in the search tabs -- it still seems to count a file again for every new source it finds, instead of once and once only, leading to exciting looking numbers in the mid-double-digits that are just 47 identical probable ipod spams named foo.wmv and obviously too small in size to be legitimate.

Finally -- what's with all the disk problems all of a sudden? Most downloads reach 100% and abort with "Disk Problem" as the status, instead of succeeding, which didn't used to happen, and I have gobs of free space on my hard drive and the files I'm downloading are not very large. So there is room for it to store the files it's downloading. So why is it complaining about a "disk problem"?

http://sales.limewire.com/040903/gc5...imeWireWin.exe

is this beta pro?? or normal says pro? hymm cant i just keep using this y pay dont ge it?