IIRC, that's a race condition that settles down after a while. Actually, Sam just posted on something similar at http://limewire.org/fisheye/changelo...20050626153915

LImeWire Update 4.9
 

My personal PRO download page states 4.8.1 where do i go from here? thanx IRH

refresh the page and scroll down to the bottom

you should see the link as:

"**NEW BETA AVAILABLE** New beta version of LimeWire PRO now available!"

LM 4.9
 

thanks a lot for your direction Stief.sorted now .cheers. IRH

Limewire 4.9 works fantastically for me. I've had only two issues with it, both minor:

1. This "bug" has been present since 4.8, when Limewire starts up, it is not fully maximized as it was upon closeout. It leaves a little space at the bottom. In case it's relevant, I run at 1280x1024 and I'm running SuSE 9.3. This issue is present in both installation formats.

2. I am not sure how to reproduce this one intentionally, but periodically when downloading a handfull of larger files (5-6 files, 80MB or larger each) I periodically get pop-up errors stating that Limewire was unable to access a necessary file and may behave strangely. File permissions seem fine as far as I can tell. Nothing seems to be effected by this error.

Like I said, both pretty minor, just annoying really. Great work so far, a vast improvement.

Thanks,

Dr SuSE

limewire seems not to detect weedshare license's in search window. and it wont return any search results when searching for the license type WeedShare. although i can find weed files if i search with string "weed wma", limewire still does not see the license. but it does detect the WeedShare license's in the library.

limewire is also not reporting the metadata and bitrate [of weedshare files] in the search results.

creative common license seem to work perfectly fine.

weedshare licenses will only work properly if the remote host that is sharing the weed file is already recognizing the license - which means that it has to run the latest LimeWire beta.

I downlded a magnet link & my dashed LW 4.8.1 opened instead of LW 4.9.0 so you can imagine what happened. It refused to load the incompletes. I then opened 4.9 & resumed them from the Library. The only plus side for me was that some files that had been sitting around for many mths started downlding. That was certainly a good sign. (I immediately trashed 4.8.1 after converting to sitx compressed format.) As a side comment, it seemed to load only about 70-80% of the shared files until I went for the LW prefs after which it loaded the rest ... a temp break from loading i guess.)

limewire has inadvertently stopped sharing all my shared folders except my weedshare folder. which has 560+ files. im without knowing the cause as to why it did this (although i did just download the java sdk standard edition and install).

upon restarting limewire, it still will not share those folders. limewire has removed the shared folders from the library without cause even though they are listed in my sharing prefs.

all combined, my total library is:

84 GB
7062 Files

my weedshare directory is located in C:\downloads\weedshare

while the rest of my library is located in D:\peer2peer\shared
which contains:

D:\peer2peer\shared\audio (unshared)
D:\peer2peer\shared\audio1 (shared)
D:\peer2peer\shared\audio2 (shared)
D:\peer2peer\shared\audio3 (shared)
D:\peer2peer\shared\audio4 (shared)
D:\peer2peer\shared\documents (shared)
D:\peer2peer\shared\images (shared)
D:\peer2peer\shared\other (share)
D:\peer2peer\shared\programs (shared)
D:\peer2peer\shared\video (shared)

i have yet to unshare and the reshare the folders because there might be an important bug that needs to be disovered.

screenshots:
http://rootproject.servehttp.com/alk...snapshot08.jpg http://rootproject.servehttp.com/alk...snapshot09.jpg

another weird thing i noticed in the library is that i have a folder located in:

D:\peer2peer\shared\other\my themes

when i click on the "Saved Files" the "My Themes" folder, for some reason, shows up 'inside' the library as a folder, this started happening after i made the folder to begin with and before limewire stopped sharing my other folders though... when i double-click this folder, it basically opens up an explorer window.
screenshot:
http://rootproject.servehttp.com/alk...snapshot07.jpg

if there is anymore information that i can provide for you, just ask.

the first person who sees the problem here wins a prize!!

http://rootproject.servehttp.com/alk...napshot010.jpg

Seen it alot that problem, but Sam fixed it on june 26 http://www.limewire.org/fisheye/chan...20050626153915

Anyway, devs should respond to many of your probs on monday, you are a great beta tester to find those issues ;)

PS 4.9.1 is available but the changelog is not yet updated http://www.limewire.com/english/content/beta.shtml

Launching MP3 from the download window doesn't still work when the media player is disabled.

Monday is July 4th.. so that would make it Tuesday the earliest. Keep up the good work guys, all these reports are appreciated.

just installed 491, now i see a few things coming together alittle better.

files are being shared again. i didnt do anything, i just installed it, ran it, and it started hashing and indexing the files like it should.

but one thing i noticed that it did was reset my my "Media Type" saving locations to my default save location "D:\peer2peer\shared\other"

btw, i have a small request about the save folder browse routine, begin the browse at "My Computer" OR "My Documents" instead of c:\program files\limewire... it just seems more appealing that way since the limewire folder is irrelevent to the save location. and you wouldnt want anyone to screw that up, and you wouldnt want anyone to save there files there either.

hmm, i should start signing my name since everyone else does..

ultracross ;)

well even in 4.9.1 the issue has not been corrected:
http://rootproject.servehttp.com/alk...napshot014.png

btw, this is occuring VERY frequently.

Yes but we don't know what has been going in 4.9.1 for instance, LW has now a new status bar, very cool when you'll see it :), but is not in 4.9.1 either....

We'll see this tuesday when the changelog will be available and devs come here to see you many bug reports ;)

I don't know if this is beta related, but I had an audio downld reach 100% & stop. I tried resuming it but it's been queued ever since (about 6 hrs.) Still using LW 4.9.0

Just an update on memory & vm use. This was yesterday (see image) & at present after a restart (after LW crashed), it's 403 MB & 1.67 GB respectively. I know ... mac java! lol

Another 1st is this downld message. The file was really only about 1% downlded when this happened. Thus I would equate it to corrupt I guess.

Dare I reiterate. But the same thing happened as with the earlier file. It reached 100% & stopped. I cancelled & redownlded but just went to queued. Even after researching, no matter which moment of the search I repeated the procedure it went to queued (53 sources.) Likewise for resumed. After restarting LW, it came up with a corrupt message. As it did previous file I mentioned. I accept that perhaps this file was corrupt but I've the behaviour seemed abnormal. (This dmg didn't mount 1st time due to checksum error but I managed to mount it otherwise.) BTW there was another identical file of same size but name was different (much longer, etc.) but it showed up as the file I was downlding.

same thing happens when i cancel and try to restart them. this has to be dominatley a limewire problem. 481 actually doesnt do this. or atleast i have never noticed it. but most of my shared files (roughly ~3000+) were downloaded with 481, and i dont think i ever had that problem. but with the beta versions, ive downloaded around another ~3000 files, and it occurs about every 20th download. that is QUITE frequent for my downloading habits.

It's late Tuesday evening now (eastern time) and the changelog still terminates at version 4.9.0.

You see, sometimes I'm wrong ;) seems Sam Berlin, the main changelog writer is away; so be patient. Anyway 4.9.1 seems very little different from 4.9.0, 4.9.2 however, should be interesting...

Ciao

A little annoyance, I know I'm 100% of the time unfirewalled, but LW tells me via the status bar that I'm not firewalled, the firewalled, then unfirewalled, then fiewalled (got the pattern?). I think this is related to the testing of the firewall with new UP connections when running as a leaf, but maybe there is a bug hidden somewhere ;) I know this isn't happening with the Bearshare firewall detection logic.

Ciao

did the devs want console errors from the cvs version?

Was limewire running when you attempted to mount it the first time? How exactly did you manage to mount it afterwards?

Also, please enable the extended tooltips and let us know the Chunk count when you see such file next time (both when it hangs and after a restart).

Thanks!

absolutely! :)

(make sure you protect your private information should there be any)

some console errors for cvs:

[Fatal Error] :7:12: Content is not allowed in trailing section.
[Fatal Error] :7:12: Content is not allowed in trailing section.
[Fatal Error] :7:12: Content is not allowed in trailing section.

------

[Fatal Error] :1:200: An invalid XML character (Unicode: 0x8) was found in the v
alue of attribute "artist" and element is "audio".
[Fatal Error] :1:145: An invalid XML character (Unicode: 0x1) was found in the v
alue of attribute "artist" and element is "audio".
[Fatal Error] :1:733: An invalid XML character (Unicode: 0x3) was found in the v
alue of attribute "album" and element is "audio".

------

1. On Download and Uploads panes, when the extended tooltips are enabled, limewire should also show the name of the file in the tooltip for atleast names that are truncated.
2. Add an Edit Menu in the "download as" and "change file location" dialogs. aswell as an option in the right-click menu on these dialogs to delete files/folders.
3. (cvs) when doing a direct connect to browse myself (loopback), it says that my speed is modem, even though i have set it to a T1.
4. (cvs) When Sorting results by bitrate. it sorts by first number instead of sorting numerically.

ie:

128
32
320
64
80
96
...etc

The things that begin with [fatal error] are just invalid XML on the network. I couldn't figure out a way to have the SAX parser supress printing out to stderr.

On this occasion a simple solution. Just dragged & dropped the dmg onto disk copy. I have the preferences set to no verification. For some reason double-clicking the dmg seems to over-ride this setting. I can't recall whether LW was running at this time (possibly or likely!) But I didn't mount it thru LW!!!
Will do as suggested next time! Cheers! :)

In case nobody noticed, it's now nearly Friday and still no updated changelog...

Odd behaviour when previewing an audio file on mac using beta 4.9.1 See http://www.gnutellaforums.com/showth...674#post144674 rather than me double-post. lol :D

With stderr captured, I've noticed huge numbers of "CancelledKeyException" messages that started when I installed beta 4.9.0, and persisted with the update to 4.9.1. Is this normal or a sign of problems with the beta? Should I go back to 4.8.1?

The snapshot below shows the chunk count. After re-opening LW it verifies the file & then a corrupt messag asking whether to continue. It happened a little too fast for me to get the chunk count the 2nd time. Once the message window comes up & press yes, it drops off the downld window list.

BTW the 2nd example I gave earlier with the disk error was a different type of error to the others (& I cancelled it off the list.) The others have been identical in their behaviour. I had also earlier disabled sharing from finished downld Files.

Lord Of The Rings...
I've only seen this for very fast downloads (>1MB/s). Was anything putting any heavier load on your hard drive while you were downloading?

Weird hang
 

Beta 4.9.1 just locked up. Zero cpu use at normal priority, and nothing is preempting it. The UI is dead. There's a console open and the odd IO exception message appears, but there's no functioning user interface and, apparently, no network activity.

All I did was start it up, sort the downloads by Status, select the final queued item, and then surf elsewhere; when I came back to it it was like this.

What gives?

The LW UI going dead is not unusual; its going dead without 100% CPU activity is.

Here's a simpler way to improve search results at the ultrapeer level. Just make it prefer dropping sources for files with many sources in the results to dropping the only source for a file in the results. So if it would produce

63 foo.mp3
22 bar.mp3
1 baz.mp3

it should start by dropping some of the foo.mp3 results, and avoid dropping the sole baz.mp3 result.

The spoofed results come in big batches (40+) so they'll tend to be sacrificed first on the altar of bandwidth. And a legit file with many sources will have an active mesh. Even if a given client only gets told of one of the sources because all the others get dropped along the way, from that one source it should learn of the others anyway, if an attempt is made to get that particular file.

I was also downlding other material at high speeds (total of 27 KB/s on a 256 kbps service.) I haven't used video processing over the past 4 days whilst this was happening. I have had other graphic manipulation programs running but they arguably don't demand that much of the cpu, or HDD. The corruption has occured to both (2x) dmg's & (3x) mp3's including 2 smallish (5-10 MB mp3 file.) I don't normally get corrupt downlds. And for this to happen over just 3-4 days it's a concern, but might just be the particular selected files.

re: the one file that came up with a disk error within LW. Not sure whether that was me or them at fault. Doesn't sound healthy. Certainly hope my HDD wasn't at fault. My graphic programs do use scratch disks allocated to various partitions. But for graphic man. the one LW downlds to is the last (4rth) on the list. Likewise for video it's about 3rd on list. I only sometimes do heavy video processing whilst LW is open. Otherwise for rendering & conversion it takes twice as long!

Sklenarikova there's a New Features Request section more appropriate for your post!

Here's a more serious problem. After I killed the hung limewire process earlier and reran it ... nothing. As in, no downloads. No message saying it couldn't restart them either. Closing and restarting didn't fix it, despite the half a meg downloads.dat in the incomplete directory and the downloads.bak for it to fall back upon.

Losing the downloads that resulted from searches isn't a big deal, since they'll turn up again eventually with the same searches. But ones that resulted from host browsing may be difficult to find again indeed.

This needs to stop happening. Limewire hasn't been reliable about preserving your downloads across sessions since version 2.something. The 3.somethings were especially bad for losing data in this manner, but the 4.somethings are only somewhat better...

Schweitzer, you have too many downloads in your queue. That causes your downloads.dat file to become corrupted very frequently.

LOTR, I do have a patch that solved the problem for me. I'm going to send it to LimeWire...

Well, if the downloads would download instead of stopping at 47% and "awaiting sources" all the bloody time maybe I'd have less of them in my queue. In any case, Limewire writing invalid data to the downloads.dat file is a bug any way you slice it. It simply shouldn't, and it shouldn't care how big the thing is as long as there's sufficient disk space either. What ever happened to scalability?

Keep Moore's Law in mind -- people are downloading hundreds or even thousands of files a day and are storing tens of thousands. By 2010, they'll be downloading thousands and storing hundreds of thousands.

Will Limewire scale to function well for these people, granted that they will have 5 and 6 GHz CPUs and several GB of RAM and a TB or more of hard drive space at that point? If it won't, everyone currently using Limewire will switch to something else by 2010.

music
 

give me thumbs up

I would like to think that by 2010, LimeWire will have continued to evolve to fit the needs of a 2010 computer. As it stands, it isn't 2010, so there's no reason to fit the needs of a hypothetical future.

You're welcome to contribute futuristic code, though. Take a look at www.limewire.org .

It's now been more than a week since the Tuesday the changelog was supposed to be updated. I still don't see any sign of an update.

Won't downld after selecting
 

Weird hang with beta 4.9.1
 

This morning I restarted limewire and let it settle down, then attempted to do some searches.

I put in one search term, hit enter, and my leaf promptly dropped one of its ultrapeer connections and then locked up. After several minutes, it recovered -- UI responsive again, etc. -- and I aborted the search (it had found nothing, unsurprising since it got launched with less than all green bars). I went to run the search again once LW recovered its missing connection, and LW froze again, but only for ~20 seconds this time. When it recovered it still showed all green bars, so I launched a couple more searches. After the second there was another pause, closer to 30 seconds; it still had all green connection bars at this point, so I launched a third. This time it seized for well over a minute. When it recovered, still all green bars, but the first search was well over half done and the second was approaching half, and none of the three had found a single file. And this was with queries that normally return 100+ each.

I contemplated aborting the searches, convinced that something had gone badly wrong somewhere, but before I actually touched the Limewire UI again, it dropped every single connection -- all of them, simultaneously as near as I could tell.

Needless to say I aborted all three searches.

It took nearly 5 minutes for it to recover to a status of all green bars. When I then went to relaunch the searches, there was a brief pause after launching the first, maybe 20 seconds in duration, but everything worked normally. The searches generated results, but maybe a quarter as many as expected for each. A repeat of the searches after harvesting the files I wanted that showed up in the first batch of results produced completely normal sized result sets.

What the hell is going on under the hood here guys? What caused this ... crash, or whatever it was? Why did it apparently not forward my searches to any ultrapeers initially -- and then later, drop all of its connections without my say-so? It had to be a problem at my end, since otherwise there had to be independent, simultaneous failures at each of several remote machines. But it wasn't a network problem -- and here's the evidence.

• It didn't simply show "disconnected" the whole time. It would have if there'd been no functioning network connectiom.
• Other network-utilizing apps, such as my Web browser, were functioning normally.
• I had some old downloads waiting in line or for busy hosts, which wouldn't be possible with no functioning network connection. They'd have shown "need more sources".

So it wasn't the network, from the API between Limewire and the OS on down to my ISP's gateway. It wasn't the remote hosts. That only leaves the Limewire. And it is a beta. Obviously, what we have here is a bug. Unfortunately, it may prove elusive and difficult to reproduce.

Also, I'm experiencing a weird problem with this BB site and Firefox 1.0.4. If I post, or even preview or something and then decide not to, that Firefox window will no longer load anything from gnutellaforums.com -- it will just spin, or pop up a timeout error, or otherwise behave incorrectly instead. If I close the affected window, open a new one, and navigate to the site again, it works fine again -- until the next time I submit or preview a reply, and then it does the same thing again. This started this AM sometime -- everything worked normally yesterday. Clearing the cache doesn't help. Restarting the window or the entire browser process does. Other sites, including very similar looking forum sites, are not affected. I haven't changed anything at my end. I think this is at your end, and suspect a cookie handling problem.

Severe bug in beta 4.9.1
 

Here's a doozy. "Error: Filesystem error. Could not set file location due to an error in the filesystem." Windows XP home SP2, filesystem is working perfectly as far as any other applications are concerned, gigs of free disk space and the file I went to download was only tens or hundreds of K ... in short, there's no rational explanation for this error.

This never happened before and I've used limewire for years. It must be the beta.

On top of that, there's another serious bug that completely prevents me from downloading these files even using an alternate name -- the file browser will not navigate to subfolders of Limewire's own folder. It comes up in My Documents instead of the download directory, and when I try to navigate to the latter, I get to Program Files, double click Limewire, and it consistently just redraws the list of folders in Program Files. There's no way to get to Limewire\Shared! It simply isn't possible!

I know this is a beta, but don't they at least do some alpha testing to eliminate blatant showstoppers like this before releasing a beta? Sheesh!

dialogs
 

RETRY -- it seemed to post OK, but when I refreshed the thread page a bit later, my reply didn't appear -- Severance's post still showed as the newest (and no page 9 had appeared either)...
See dialogs Problems (click on link)

CROSSPOSTING
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Edited to comply with the House Rules.
Multiple copies of the same post will not be tolerated. Forum Rules (click here)

Re: Severe bug in beta 4.9.1
 

A filesystem error can also occur when the filename of the file to download is invalid with regard to your filesystem, e.g. a filename such as "../text.txt" exposes such an error.

When you choose to download a file by clicking the "Download As..." menu item, a filechooser pops up, proposing to save the file in the download folder for its mediatype or the default download folder.

I tried reproducing your actions and had no problems navigating into the C:\Program Files\LimeWire\ folder.

Please make sure the LimeWire folder is readable and accessible and also writable in case you want to download files to it.

Eh -- a filename with slashes? Shouldn't occur.

Anyway, it should just block out any characters that were acceptable on the source filesystem but aren't on the destination one, replacing them with something standard, perhaps a dot or a dash or an underscore automatically, instead of making you go to the bother of trying to navigate to the shared dir from My Documents only to then NOT BLOODY WORK ANYWAY. :P

It is. And when I navigated there with the file chooser from My Documents, I got to Program Files, double-clicked the Limewire folder, and the following occurred -- the directory name above the file list changed to say Limewire and the file list redrew itself and returned to the upper left corner from having been scrolled some distance to the right, but it still showed the contents of the Program Files directory.

While I may have been able to save to C:\Program Files\Limewire if I'd then hit Save (depending on whether the file got saved to where the file list showed, or to the directory named above that area, which had become inconsistent with each other due to this bug), I would not have been able to save to C:\Program Files\Limewire\Shared. I could not navigate to the Shared folder to double click it, because the file list still showed the subfolders of Program Files. And I very much doubt typing "Shared" in the filename box and hitting enter would have worked. Most likely I'd have ended up with a file named "Shared" in C:\Program Files for my effort, or else a complaint that the file name was already in use ...

LOTR: I think what's happened between you and Murderous Rage is a colossal misunderstanding. I see you've edited some posts, but he was probably expecting to see a new post with anything you had to say to him. Seeing nothing new after the "system was down earlier" post would drive me nuts if I kept trying to post new stuff and nothing appeared, neither my own nor an explanation why, below the last posting in the thread. I think it would be best if you unbanned him (if you banned him in the first place) and deleted anything nasty you said about him anywhere, put his posting replying to me here in this thread where it belongs, and deleted the duplicate. And yes, investigating how the original posting got mislaid would probably be a good idea too. Obviously, there are still residual problems after the morning's downtime, and it really is not fair to blame one of the glitch's unfortunate victims, if that is indeed what has happened here. I've arrived a little late to have seen whatever messages he posted that are gone, but the original posting seems to be perfectly innocuous to me, and I doubt he had any ill intent, or indeed any intent except to see that posting appear beneath mine in this thread, and to see it stay there. There really is no reason it can't be the other copy that gets trashed, is there? Of course it's probably too late anyway -- if it were me, and I posted and everything kept disappearing, I'd give up and surf elsewhere and not come back, but there's no harm trying.

--magnets incorrectly format with the internal IP when on a LAN.

--UPnP doesn't allow direct connect, even though the proper port was forwarded, "received incoming this session =TRUE" and no firewall was being used on a wireless (Airport) network. workaround was to set LW firewall prefs to manual.

btw--the firewall indicator in 4.9.2 Pro correctly responded when the Airport opened or closed the port. :)