The newset beta still hasn't fixed the problems with Limewire freezing for a bit after completing any download and completely locking up if you select some stuff and cancel, or clear inactive ... and now most of my downloads fail with "disk problem" on my less than half full 80 gig drive. What the hell is going on? The number of serious bugs is supposed to go DOWN, not UP!

The technicians are on the job right now investigating your complaints. Remember this is a test, BETA put out there. All the information is being compiled, examined, and beaten to a bloody pulp with a big bat. After the BETA goes to stable status I am sure we will enjoy a much better program. I for one like some of the new innovations that are in the 9 series, but, I, like you do not like the problems, but will wait and see.

The new disk problem thing is glaringly obvious. All they had to do was run the darn thing for about four hours before posting it on their web site and they'd have known it was worse than 4.9.8. Don't they even briefly test it before posting a new beta? I thought even betas were supposed to have had a little in-house testing before being publicly released...and running one copy for four hours on a normal internet connection would have sufficed to uncover this!

If you can't wait, just search in LW: "limewirewin4.9.8.exe" then dl it if you can and install it. Of course you can continue your downloads if you revert to the latest stable release 4.8.1 too.


Ciao

On Linux the same..

I have few downloads, when one is finishing (more or less in 100% of verifying) every other downloads change status at "Disk problem", and I have to cancel all and from Incomplete files resume them all..

I had to back on 4.8.1 ... ;[


And back for tray on Linux..
Is it total impossible for use SWT (like in azureus) for LW ?
If yes then I understand, until tray of JDIC will not work good.. tray on LW will not work too ? ;[

Download an executable from a p2p network and run it? Are you freaking mad?! I'm sorry, but I like not having viruses, trojans, or spyware on my system a little too much to do something like that.

And I've been told that you can NOT go back to 4.8.1 from the betas without losing your incomplete downloads.

Well, can you or can't you? Now I've gotten two contradictory claims.

I see there's a new beta 4.9.10 out (no thanks to your web site -- it was like pulling teeth getting it to actually serve a freaking page instead of some spurious "timeout" error today!).

What I don't see is an entry in the 4.9.10 change list saying "Fixed disk problem bug".

:(

Any ETA on when this will be fixed?

Green check icons still inaccurate 4.9.9
 

I've got the disk problem thing too. Moreover, the green check icons are still broken after all these years. I just had a search come back with 10 results. All showed green checks. Not trusting these, I selected them all and hit download. I got 8 overwrite prompts and zero "continue or cancel" prompts saying I already had files with the same content.

Which means two of the green checked files were neither files whose names already existed at the download destination, nor files whose content already existed in my library, the two things that are supposed to produce a green check...

Can't back to 4.8.1 without losing incomplete downloads ?

I think I did it..

I run 4.8.1 and LW said that, he can't load lod downloads, but I just went to "Incomplete files" checked them all and click "Resume", and all downloads from 4.9.9 back and finished on 4.8.1 :)

That doesn't work for me. The ones that had some progress resume, but most of the rest will end up showing a bogus file size of zero and will not download -- they will "await sources" till the cows come home. So I'd lose every incomplete download that didn't have any progress yet, and have a bazillion searches to do over again to track them all down. And any from host browsing would have to be tracked down twice -- somehow I'd have to re-find the host, and browse it again, then find the file in the host's file list.

Not my idea of a fun time.

After upgrading to 4.9.10, I don't notice the Disk Problem problem any more. But it's not mentioned in the 4.9.10 changelog, and it was only introduced in 4.9.9, so it looks like someone forgot to mention this in the changelog?

Anyway, everyone complaining in this thread about the problem, upgrading to 4.9.10 seems to fix it without breaking anything else, even though the 4.9.10 change list just mentions splash screens and translations.

Normally LW 4.8 should resume 4.9 downloads. Also the disk error prob fix is in the 4.9.9 changelog...
- Reverted change to VerifyingFile.

As for dling .exe, you can, really, if you have a good antivirus or trust the file. I do on my xp box. But yeah I mostly use a Mac, so viruses don't bother me ;)

Here's a bug -- if you select something other than All Types (i.e. videos, music, images, documents, or programs) with the Library tab hidden, then use the view menu to show the library tab, the selection in the search tab moves back to All Types all by itself. It should only move in response to user input.

Also, Limewire 4.9.10 still sometimes randomly drops a connection (goes from all green bars to one or more red bars) while the network connection is stable and it's not starting up or shutting down. Limewire should only drop connections in response to user input.

I confirm the library resetting the file type bug.

Spud Tosser: can you make a stack trace (thread stickied in the beta forum) of LW when it drops connections and post it here?

That could also be due to the other side going offline.

Just wondering, when I am running in leaf mode sometimes Limewire will drop all but 1 connection if I touch the mouse. What apears to be happening is if I am leaving LW idel and it is just UL to others for a while with the connection page open and I come back when I come back I can look at the connections it will show 5 and turbo charged but as soon as I touch the mouse it wil drop 4 and then imedatley re connect to 4 new host. I have not noticed any decline in LW preformance, is this somthing that has been writen into LW so that there ar more ultrappers available for others to use when others have a demand for them and I do not. I have just noticed this in the last few versions currentley running 4.9.10. By the way I was able to make LW freeze 1 time I started 22 DL one right after the other and LW froze but only for about 20 sec. Tried several more times to get it to freeze but could not and not thinking I did'nt have Debug running so no stacktrace.


Latter Grandpa

Another question while running Pro 4.9.10 Leaf mode 5 connections, I had a file than needed more sources but could not find any. I left 4.9.10 running and started 4.9.10 Pro DeBug connected in leaf mode 5 connections so now have 2 versions of LW running the DeBug immedatley found a source for the file and started DL it. I manualy searched for the file on the other verson several times and still need more sources. I am asumeing this is due to the Ultrappers I am connected to but don't all people have acess to the same files.

Latter Grandpa

your two instances had different network horizons, because they were connected to different sets of ultrapeers. Think of the earth's northern hemisphere and the hemisphere east from the greenwich meridian to the date line -- there's a large chunk of overlap, plus some areas in only one hemisphere or the other, plus a chunk in neither. North America and much of the Pacific is in both; Asia is in only one; South America is in the other; Australia isn't in either. Europe and Antarctica are divided east-west, the Atlantic is divided north-south, etc...

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

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

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

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

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

OK, who'se the wise guy that mutilated my previous post? I thought these forums were supposed to show "edited by" if someone alters something, but it doesn't -- yet it definitely was edited, since someone mangled a phrase and inserted an icon in there and it wasn't me. At least, I didn't insert an icon into the text, or an image tag; I'd have remembered doing that.

I suppose the lack of an "edited by..." note means it was the system administrator, or some dumbarse bot with equivalent privileges...

The 4.9 series has a new way of finding out if a host is available or not without actually connecting to them. So even if it did "make an honest attempt to connect" it would still fail.

Then that "new way of finding out if a host is available" obviously is broken. Used to be you'd see a bunch of files you liked, hit to download them, get a few, and the rest would "need more sources". You'd resume them, and get some, and the rest would "await sources". You'd resume them, get some, and a smaller number would "await sources". And so on. Now, however, in the exact same situation you get only a fraction as many of the files, because you get the same number the first time, the same number the second time, and then zero, until you restart Limewire.

This is NOT a change for the better. The same logic that was making it decide a file was "awaiting sources" that was in fact available and would download at the tap of the Resume button is evidently making it give up before it can even try. That logic is in error.

Of course, the real problem is that it prematurely gives up on a file that will actually download given another resume attempt or three. But at least before you could manually resume it when it decided to give up. Now once it decides to give up you have to restart.

it uses udp (a connectionless protocol).. this is also how the FW2FW protocol works. and the first person to respond will be your first download canidate.

It has never been possible to resume a download in the "Need more sources" state. The only thing you could do is press "Find more sources", which would put the download in "Awaiting sources".

Do you mean before you were able to hit resume on a download that was "Awaiting sources" and it would start downloading? I doubt that.

YES. That is exactly what I mean. You'd find a bunch of files you wanted and hit download. You'd get maybe three of them. The rest would "need more sources". You'd hit find sources. It would find a few more (usually three) and download them. The rest would end up "awaiting sources". If you selected them and hit resume, you'd usually get some more -- again, frequently, three. (Three seems to be a common number of upload slots, along with five, for whatever reason.) Wash, rinse, repeat, eventually get them all, or most of them. Now, the later stages of this method for getting the rest of the files Doesn't Work. You have to keep restarting Limewire, which is pointless and which people shouldn't be being encouraged to do, whether explicitly or by the program's behavior.

It is clear from what you say that "awaiting sources" is never supposed to appear for a file with known sources online; it is equally clear from what I have observed that files with known sources do erroneously end up in that state, despite being resumable. Except that in most of the 4.9 betas it doesn't work anymore, and as a result when you find a big cluster of co-hosted files you can only ever get a handful of them without restarting Limewire, which didn't used to be the case if you knew what you were doing. (It worked for some of the betas, around 4.9.10 or maybe 4.9.7, though...)

The proof is in the pudding -- if you find a batch of such files now and get a few and the rest end up awaiting sources, and you restart your client and it promptly downloads some of them (or does so shortly after you do another "find sources"), this is a sure sign that the host with those files never actually went offline, and the supposedly "awaiting sources" files were actually still available and should have shown "waiting for busy hosts".

Let me guess -- your new udp thingie cannot distinguish between an offline host and a busy host, while the old system could? And moreover, once it decides a host is offline it actually forgets about the host entirely, whereas the old system still remembered the potential source and if it became available again then resume would work, but now it won't because even if the source is available again it forgets it ever existed? Considering how common it is for hosts to be intermittently busy, in yo-yo mode, or have flaky connections, this is a recipe for disaster.

We could not reproduce this behavior. Starting several downloads from the same host would result in the first three being started, and the rest would either become waiting for busy or need more sources depending on what the remote host replied (or failed to reply) in response.

The difference is in what happens next. Find more sources would tend to get some more, and the rest would await sources.

In 4.8.1 and some of the 4.9 betas, resuming those would get some more. In 4.9.17 and other 4.9 betas, it has no effect -- it doesn't even show "connecting..." status however briefly. It seems to actually discard its knowledge of the source as soon as that source fails to respond even once -- which is bad, because failure to respond is often intermittent rather than indicating the host has become long-term unavailable.

Are you usually not firewalled when this happens? If so, could you try and reproduce this behavior when firewalled? Let me know if you need help making Limewire think its firewalled.

Ok, the fact that older versions were making an attempt to download the file even while "awaiting for sources" was unintentional and as we changed that code the side effect dissapeared.

However, as it appears to be useful and helpful in getting the downloads done, we're going to restore it explicitly. Will be in the next version.

The email addy for submitting bug reports, bugs@limewire.com doesnt work, i keep getting delivery failed emails back.

I'm very late to report but ... I found i had some of the same issues as some other users who also used Windows.

For LW 4.9.7 I was unable to startup. It would stick at the loading stage. For LW 4.9.11 it starts up well ... but I lost my incompletes! (the 1st time I mean.) I didn't think that would be the case for upgrading.

most likely, this would happen if you removed your .limewire pref directory. i personally dont recall having any problems with it.

I didn't remove the prefs folder after updating from 4.8.1 to 4.9.7 or 4.9.11
I didn't receive any message to say my incompletes were unable to load. I just noticed the downlds window was empty when there should have been a dozen or so items there. I'm not sure it's a major issue but a few other people had complained about the same thing so i guess it depends on one's system & set up. But just something to keep in mind for the devs. It might have been fixed by now anyway with the newer betas.

Come to think of it, I couldn't load 4.9.7 so I had to force quit using control-alt-del so perhaps that's what caused it. Windows is "so" sensitive about such things!!!

But then again i've done this before with 4.8.1 without loss of my incompletes. But prolly the update was the last hay strand it could stand. lol :D

I never have lost my d/l's and never removed my .limewitch folder. Windows is sensitive but so far I have loaded the last 7 or 8 beta's without any trouble. the trouble usually begins with a double click on LimeWitch.

deacon72, if ya dont like the program, then why use it? that just doesnt make sense to me...

i guess not everyone is gifted in the art of configuration.;) :p

:cool:

The problems I have come across have not been a matter of my configuration, as it is the problem of some of these BETA's going from bad to worse. Browsing these forums would convince the most stalwart defender of LimeWire that there is a problem that goes beyond newbies. I put my LimeWire bug reports on "review before sending" and have had several sent by a program recognizing it was in trouble.

As to why I use this program, my opinion was based on the ease of use, variety of files available, and the fact that 4.8.1 seemed a credible program. I thought the BETA's would iron out some of the bugs ie: the bottleneck on download/upload speeds and the CPU overload that was prevalent as far back to '98 with Napster

If criticism and subjective reporting of problems becomes an irritant and unappreciated, a program or any project for that matter, will die as so many other programs have up here. I have seen it happen too often. I've seen Administrators close Forums because they got tired of listening to users complain, those users ranging from the "newbies" who didn't understand their own computers' let alone know how to efficiently install the program to "novice's" who knew what they were doing but were still having trouble to those in the "advanced" catogory who forgot about "their" learning process and rather than help they got irritated. All have different levels of understanding and usefulness.

Never Kick Holes in the lifeboat.

I'm not questionning your LW config, it only happens that LW has a hard time on your setup of internet connection/computer hardware ;) Browsing the forums here for bugs or complaints isn't really reflecting reality since most users only come here when they have issues. Knowing that there are more users of LW at the arrival of 4.9 compared to 4.8, I really think that the newest LW is stable enough. Keep in mind that there are 30 millions users of LW on a regular basis.

Critics are appreciated as long as they are justified. I can certify that we are a tought forum here, we can take a lot of critics or else we would have died long ago. But unjustified critics are sure irritating.

Since your bugs seems specific to you, I'd invite you to try taking contact with Zab in PMs. If I were a dev I would certainly like to experience the bugs on your machine by VNC or remote control. You just have to set a VNC server, send the infos to Zab and he would surely figure out the bugs.

Anyway, even if you are not a dev, you should check the CVS changes so you know what's happening. http://www.limewire.org/fisheye/changelog/limecvs/

Ciao ;)

SEVERE BUG!
 

OK, what is up with this? I've got this file that simply won't download. It's not because there's no source online for it. But it's behaving freaky. Using beta 4.9.22.

First it says waiting in line position 2. Then it says need more sources. Er, what? The guy went offline? ok, find more sources. Hrm -- waiting in line, position 2. And after a while: awaiting sources. What? Now I hit resume and it's back to waiting in line. But does it move up to position 1 and then download? Noooooo ... back to awaiting sources! I've had to hit resume a dozen times so far, and there's no sign that this thing will ever correctly advance in line and then download. I have no trouble connecting to the source and getting slotted into queue, so the source is online and not too busy. So why in Christ's name won't the file DOWNLOAD?!?!?!?! It must be a bug. I want it fixed. I've seen this way too many times now for it to just be a minor hiccup or a one-time fluke. It happens with some file or another every damn day it seems. Why doesn't it stay in line and then download???

See what I mean about nursemaiding? :P

Control-clicking sometimes still deselects everything (e.g. in search results) as if you weren't holding down control. Latest beta (4.9.22)

Hi betatester48486,

I too am seeing this problem, even with 4.9.23. For me, this is only occurring when new search results are coming in at the same time as when I click.

I'm investigating further... in the meantime, please let me know if this is your experience as well.

Justin

Hmmmm, actually might this just be a case of ctrl-click-and-drag?

No, this is with plain control-clicking. Where would I be trying to drag them, anyway? Dragging from Limewire doesn't do anything, after all.

i think he means clicking-and-draging over multiple files to make multiple selections.

Bug in beta 4.9.24
 

Minor (semi-cosmetic) but not unnoticeable: I just had a search where the lime stopped spinning well before all the results were in -- the number in the search result tab kept climbing for quite a while after the search was supposedly finished. It seems to me that that spinning lime indicator has never been 100% accurate though...

Not what I was doing. I control click individual files to add/remove them from the selection. Removing does not work correctly (the file tends to stay selected) and adding also does not work correctly (it's inconsistent, but about 1/3 of the time the file is added to the selection and about 2/3 of the time the file becomes the selection, i.e. everything else is deselected). This behavior is inconsistent with every other gui app with multi-select listboxes I use, and the behavior is even inconsistent over time, since control click adding DOES work correctly SOME times...

It doesn't just send out a query once and wait for responses to trickle in, but does something more active? I always figured the time was based on the HTL times the timeout (likely the HTL in minutes then), at which time the query has propagated to as many hosts as it ever will.

Of course, if that is what's happening and some hosts are slow in responding...but the timeout means a maximum additional minute.

Should I therefore wait 1 minute past when the lime stops spinning to be sure of having received all the results that are going to be received?

Or is it in fact more complex than that?

I do notice that some searches seem to quit unusually early ... which if Limewire does take an active role until that point would be cause for concern, since it means the horizon will effectively be closer for such searches, which will make it harder to find rare content in such cases. Add to that that if a single host has hundreds of matches you only seem to see a couple dozen. And add to that that the frigging ipod spammer's 50-odd bogus results seem to compete with real results for limited bandwidth, causing 50 or so legitimate results to get dropped on the floor...

Any suggestions on how to make results more balanced? I'd rather get one or two sources each for dozens of files (with the remaining sources still discoverable via the mesh, or Find Sources) than results like these, which are all too common:

169 Common File 1.xyz
44 Common File 2.xyz
36 Another Fricking Spam.wmv
12 Another file.xyz
1 Rare File 1.xyz
1 Rare File 2.xyz

and nothing else. :P

Of course if I know of some naming pattern to some of the rare files I can snag a lot of them with a narrower query, but some miscellaneous rare files might potentially elude searches for years, with daily searching!