| |||
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 |
| |||
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. |
| |||
Quote:
|
| |||
Quote:
regarding the console error, do a cvs update because the problem has been fixed. |
| |||
Quote:
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. Last edited by ultracross; July 13th, 2005 at 07:24 AM. |
| |||
Re: Re: Severe bug in beta 4.9.1 Quote:
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 |
| |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
When i Leave Limewire Beta, it automatically re-opens Limewire | MPielichowski | Connection Problems | 1 | February 16th, 2007 08:16 PM |
LimeWire 4.1.2 Beta | sberlin | LimeWire Beta Archives | 10 | August 2nd, 2004 10:49 AM |
LimeWire 3.9.5 Beta | sberlin | LimeWire Beta Archives | 38 | April 27th, 2004 11:32 AM |
LimeWire 3.9.4 Beta | sberlin | LimeWire Beta Archives | 7 | April 23rd, 2004 01:59 PM |
LimeWire 1.7 beta available | crohrs | LimeWire Beta Archives | 35 | October 25th, 2001 03:49 PM |