i would like to be able to burn cds on llime wirs library instead of draging it to windows media, or roxio or any other device that your able to burn cds, (audio, mp3s etc.)Now that would be even faster to make your cds and youll be able to keep searching whatever it is that your searching for.

Burning CDs while running something CPU-intensive is likely to result in coasters. Limewire is very CPU-intensive.

Here's a feature request: Limewire doesn't write unmovable files.

Every batch of downloads seems to contain a subset that Explorer won't let me move or organize -- trying to produces a message saying the file name is "too long or invalid", which is nonsense since if the file name was really too long or invalid it couldn't have ended up with that name in the first place -- Limewire would have been unable to save the file with that name in the first place.

Nonetheless, there's something Explorer (but not the underlying filesystem) finds objectionable about a certain percentage of Limewire-originated files -- and no other files. I've never seen this happen with a file created by myself, installed from a disk, or downloaded via anything else -- only with files downloaded via Limewire.

Whatever it is, presumably Limewire is responsible. (Odd file permissions? Something of the sort?) And therefore, presumably a future version can avoid doing it. Files downloaded in the Firefox Web browser never exhibit this problem, so it's clearly possible to make an application that downloads files and avoids leaving them in a state where they can't be moved.

The funny thing is that renaming them in Explorer does make the files movable. It seems there's some weird length limit that applies to moving files but not to creating them in the first place, not that that makes any sense, but since when does anything that came from Microsoft make sense? If that is indeed the case, the solution is just to truncate names at, say, 60 characters -- all the files exhibiting the problem have had names considerably longer than that. (It still begs the question of why the OS would permit the files to be given such a name in the first place but then refuse to allow them to be moved...)

There's indeed a path length limit (MAX_PATH C macro, on most modern systems 1024 byte/char).

That doesn't explain why the length limit stops a file that exceeds it being moved, but doesn't stop the file being created with the long name in the first place -- shouldn't Limewire get an exception thrown or something?

The JVM throws on Mac OS X a "FileNotFoundException: <very long path> (File name too long)" exception. The Finder on the other hand seems to use relative paths in one direction (I can create paths beyond 1024 byte and I can copy files into such directories) but as soon as I try to copy/move a File back to the Desktop it refuses the operation (i.e. relative destination path and absolute source path).

Btw, MAX_PATH is 260 chars on Windows XP (modern system -- so much for that). Check if your file's path is >=260 chars...!?

A more advanced Magnet "creator".

So I can set like fallback URL (&xs=http://server.to/file.zip),
define a download name (&dn=What+ever+I+want.smile),

...and so one...

Would be REALL neat if LimeWire could add urn:kzhash in addition to urn:sha1...

Limewire currently hangs a lot. It recovers -- usually -- but frequently the UI completely stops responding, sometimes for minutes at a time.

When a file completes downloading or if you select some downloads and cancel them or "clear inactive" downloads, Limewire hangs with 100% CPU use, often for a substantial amount of time and interfering with using other applications on your computer with the excessive CPU use. Clearing inactive downloads makes it hang potentially for half an hour or more -- but it slows down and becomes unstable if you don't every so often, so you're stuck between a rock and a hard place there.

SOMETIMES when you launch a search or change tabs in the search area, but not always, it hangs for about half a minute with zero CPU use. This seems to be a different type of hang. I think this hang is caused by the displaying of a new/different search tab causing it to "think" an inordinate amount and in the main event handling thread to boot -- but since there's no cpu use, it looks like it's blocking on I/O or something in this case. The other, more severe hangs seem caused by the removal, either via completion or cancellation, of items from the download list. It seems to last a time proportional to the number of items removed. In this case it's apparently pure number crunching in the main event handling thread, rather than waiting for some disk or network event in that thread.

Slow sort algorithms perhaps?

Here's a feature request for you: please remove the popup from the Limewire Web site and promise not to try to spam me, or anyone else, again.

Thank God I never go anywhere with IE but Winblows Update, and use Firefox for everything else...

Seeing as there is no popup on our website, I would have to presume that you have some form of spyware or bundled software running on your computer. They like to pop ads when they detect a browser navigation to sites like ours.