LimeWire 4.1.4 Beta
 

The LimeWire 4.1.4 beta has been released. Pro users can download it from their personal download page. The free version is available at the LimeWire Beta Page.

There are two major additions in LimeWire 4.1.4. These are iTunes integration on Windows and support for firewall-to-firewall transfers.

iTunes support uses the Digital Audio Access Protocol (DAAP), and was contributed by Roger Kapsi. This allows LimeWire to advertise its shared music as a playlist in iTunes. Recently downloaded files will appear as a sub-playlist titled "What's New". The master playlist's name can be changed (just like your shared playlist in iTunes can be changed) by going to Options (or Preferences on OSX) and choosing iTunes -> DAAP. You can also choose to turn this feature off (in the same options area) if you prefer not to share a playlist on iTunes. Note that this works on all operating systems.

Firewall to Firewall transfers allows two people behind firewalls to connect directly to each other and transfer data. This makes use of UDP, and a third party to coordinate the initial messaging. This is a huge increase in the efficiency of the network, because more than 60% of users are firewalled. Normally, firewalled users would only be able to download from other hosts who are not firewalled, which is of course severely limited. With firewall to firewall transfers, firewalled users can now access the full 100% of hosts. The benefits of this will become more visible as more users upgrade to the newer versions of LimeWire.

LimeWire 4.1.4 also included various minor bug fixes, such as:
- A fix to not always have an extra locale preferenced connection, if it wasn't needed.
- A fix for a potential deadlock when fetching GWebCaches.
- A fix to not construct illegal queries when resuming old downloads.
- A fix to allow OSX's FileChooser to select Files instead of just directories.
- Better handling of cases where Windows cannot load the required libraries for using the system tray or browser.
- Better handling of reading an empty m3u file.
- Support for allowing OSX with Java 1.4.2_05 to drag multiple files.

Thanks very much for your help in testing the betas! LimeWire 4.2 is very close, and we're positive that it will be a huge leap forward for file-sharing!

Thanks,
- The LimeWire Team

wow
 

wow i can't beleive you guys pulled of firewall to firewall transfers already!

At last! Firewall to firewall transfers.

Ivan
In the dark we make a brighter light

Great Work!

Does the Playlist get shared via Rendevouz (everybody in the network can see and stream my shared files)?

The name of the playlist naturally changed quickly. Now they are called "freeflying songs" :-)

And f2f-support is as great as could be!

Do I remember correctly, that you have an"always proxy my uploads" option somwhere up your sleeves?
Only this and encryption for transfers and general communication still missing to become somewhat anonymous and safe.

yes, daap is done via Rendezvous.

f2f is not done via proxies, so there can't be any option to proxy your uploads.

I've made this comment elsewhere but I really think that two important changes need to made to the interface, both for the same reason. I think that "incoming Searches" and "What's New" should be either eliminated outright or that an option should be added to remove them from view. I love using LimeWire, and I think it's far and away the best all around file sharing app, but I'm just not going to install it on my parnets and friends of parents computer when it puts the seedy underside of gnutella so close to their fingertips. I know there's porn out there, you know there's porn out there, but my Mom doesn't know that, and believe me she would freak if she saw what searches were going through her computer.

Besides both of these "features" seem predicated on the notion that people just don't have enough to search for. Where did you get that idea? Are people really sitting in front of their computer at a loss for things they can download? I find it hard to believe.

-C

Salut Sam, looking good! Do you know why the HTML Page Stuff in messagebundle can't be translated or modified? (I sent to translate lists an updated French translation current with CVS but without updating the HTML page).
Other questions:
1)will the web page for downloads be updated for foreign caracters (ie èàç)?
2)will a search lan only implementation likely to be included in 4.2? (I posted a JIRA issue on this one)

Also, if I leave unattended my computer with LW uploading large files, the computer is almost at frozen state when I use it again. It seems to be related to the huge amount of virtual memory LW is using on osx (sometimes more than 500megs). Or it could also be because LW is using more computer ressources when it detects it is idle. This is under Osx 10.3.5 with java 1.4.2.05 and 512 meg ram (450 mhz G3).

Merci

Suggestion: right now I'm downloading a mac app and LW redownloads constantly the last 2% when it is verifying the hash of the file (98% of the file is ok). Problem is that one host (a Gnucleus 2.0.1, an app that isn't running on os x yet it shares os x apps...) is the cause of that garbage and LW retry to dl from it each time. I'm in a loop of corruption. LW "SHOULD" remember hosts giving garbage for a limited time and try other so downloads finish... This is a great optimisation against hostile companies (or corrupted servents) that try to corrupt downloads.

Please take that suggestion into the download code of LW ;) It will benifit user tremendously.

Ciao

Update with corruption: I've downloaded a packet sniffer and I identified the Gnucleus host IP. Problem is that LW in -options-filter-host with that IP entered still downloads from that corrupted host. This is a bug and LW should not download from banned hosts.

Just a question: does that happen also if you turn off ultrapeer capabilities? I did run LimeWire with that function disabled for a long time and only recently turned ultrapeer on and only since then I am seing the same problem.

I would assume that there is a memory leak somehow if ultrapeer is turned on.

Sorry Jum, I should have told that no, I am not running as UP. In fact, this problem happened since I "updated to java 1.4.2-05 developper preview 3". (biggest mistake I've done, that java was really poor performing). I downloaded the updated version of last week and the problem is less obvious. But I think this is something about the new apple java. This morning LW was using over 200 meg ram and 700 meg of virtual memory!!! It took 30 seconds before the dock showed (autohide is on).

Ciao

I do not think that it is related to the Java VM version, as I tried it under Windows as well as OS X and the same things happen. I did run it under XP and I get the same problem although the way the system tells me that I am out of memory is a bit differently under OS X than under XP.

So it might be related to the idle code in LW? I don't know, that code (idle) was merged 9 months ago.

Sam, any idea?

Ciao ;)

It's likely not related to any idle code -- that code doesn't store anything in memory, it just looks at a single value. Out of memory problems tend to arise after a long delay because it is only after a long period of time that enough items can accumulate to cause a memory problem.

Perhaps it is related to Sun caching all IPs in memory forever. We'll experiment with changing that setting (if it is changable?) and see how that helps.

Of course, we're always on the lookout for memory leaks.

Regarding corruption detection -- right now the download code is not structured in a way that we can easily determine which host caused corruption. This will be done at some point, but for now LimeWire just tries to download six times, and if it's still corrupted after the sixth attempt it will give up.

Salut Sam, could it simply be that LW is not flushing upload buffers (from the hard disk to ram then virtual memory) ?? It happens often when having simultaneous uploads of a single 700 meg files and no other computer activity. It could happen also for downloads, but I'm mostly uploading.

About the corruption here is what I think LW should do: LW should remember the swarming hosts and put them in quarantine when there are more sources to try. If there are no more sources it should split sources in two, and try half of them, if still corruption, try the other half.

Ciao

Hmm -- I don't think there's any flushing of buffers that could cause memory problems. However, there could be things related to uploads. If you can recall any other things of interest that are happening before memory is gobbled up, it'd be very helpful.

Splitting the sources into two is a great idea, but one that is hard to implement in practice. If you have four sources and try two of them, what happens if you succeeded a bit with them and then they went offline? Do you fallback to the other two? If so, and corruption is noticed after it's over, which sources do you retry? It would be much simpler to just do it the way it's supposed to be done -- verify as it's downloaded, but it's not possible to do that right now. It _will_ be done that way at some point, though.

I'm not sure about what you mean here. :confused: LW isn't checking downloads against the tiger tree before the final hashing? (well it looks that way as of now) Even with LW verifying a tiger tree chunk that is corrupted while downloaded, you'll have to quarantine hostile clients to finish the download. The yesterdays gnucleus hosts was only 1 of 75 sources, but it always had open uploads slots with great speed -- seems to be intentional to me---. LW gotta protect downloads from those hostiles.

An optimisation would be LW asking sub tiger trees for a often corrupted chunk and disable swarming for those small chunks so LW indentifies the corrupted host. But LW would have to ask the sub tiger trees to a trusty host: that seems difficult, except if you are a Bearshare (read- non hijackable because close source).

Ciao ;)

Edit: concerning memory leaks in uploads: I see magnetmix has america's army ready to download. Suggestion, set a LW with AA shared and monitor memory consomption after idle time and concurrent uploads. I do not have a console in LW to help you debug!

I'm already doing it for my bittorrent downloads - last time I tried doing it with HTTP downloads didn't really work out but the infrastructure is basically there and designed to be used by HTTP downloads as well.

I have noted that there seems to be some correlation between the amount of file corruption and the number of GnucDNA based clients you download from. I couldn't verify it yet because the GnucDNA source code isn't very readable - plus the source code doesn't seem to be available via sourceforge's cvs anymore (although that might just be some temporary server failure).

I have also been working on an improved security feature allowing to ban hostile vendors a little easier, if it makes its way in the mainline you could simply edit your limewire.props file to ban them instead of editing the sources.

Facilities "Lost" in 4.1.x
 

FYI

I've recently downloaded the Beta versions 4.1.3 and 4.1.4

However, I find that I can now longer perform the following from the Library:

1. Edit file names;

2. Drag files into sub-folders.

In both cases I have to use the Explore button and do it in the Apple Finder :confused:

I'm using a Mac G4, OSX 10.2.8

From the code in the Sun InetAddress class I would say that networkaddress.cache.ttl is the property to set. I just started a LimeWire with this property set to 300 seconds, I will report if this makes any difference.

I think it good, that filenames can't be edited that simple anymore. I always did it unintentionally, even for the folders...

It did not make a difference, LimeWire still grows in memory usage while running. So it is not the address cache.

>Edit file names;

This was done purposely. Too many people were accidentally changing the names of files/folders. It will be re-added if we can make the editor act in an expected manner, rather than going into editing mode at strange and confusing times.

>Drag files into sub-folders.

This was also removed purposely, as the entire Drag & Drop system is being redesigned to use Java's built-in system instead of our hand-crafted one. Dropping will (hopefully) be re-added before 4.2 is released.

I am on mandrake 10 Official and upon first run, I was told that DAAP for sharing in iTunes was unable to start and would be disabled.

I have not used juk, but I don't believe it has iTunes sharing. If this is the case, you can probably just skip this prompt if OS=linux.

Not a big deal, but I figured I'd point it ouf just in case it was an oversight.

The DAAP error on Linux is already fixed for the next beta, with much thanks to Roger Kapsi. Not sure what 'juk' is though.

Well I've investigated the memory problem a little bit more... Uploads of simultaneous 700 megs files for ten hours computer unattended without downloads resulted in 22(!!!) megs RAM and 800 megs of virtual memory. LW was in idle state (1 UP connection). Now that I use the computer LW mem usage grew to 53 megs ram and 800 megs virtual memory. So 2 more connections = 31 megs RAM (???) As for the 200 megs ram I reported earlier, the same uploads were coupled with 1 download (a 200 meg file). Could there be a memory leak in the download code (a big one) and in connections (a smaller one)?

Ciao :p

Which tool do you use to gather the numbers? I suppose "top" and you're referring the VSIZE column?

:D Process viewer, of course :p

Strange, - I don't see LimeWire ever use that much memory...

That is not very professional. :D

Ok, what Process Viewer (Activity Viewer) is showing as Virtual Memory is VSIZE in "top".

Virtual means in this case really virtual and has nothing to do with the virtual memory known from Mac OS Classic! On OSX can each process allocate up to 4GB (G5s can 8 or 16GB) of memory and as long as they do not use the memory it's only virtually allocated.

A memory leak (memory consuption AND the the loss of the ability to free it) as such is anyway not possible in Java. As long as RSIZE (Real Memory; the total amount of physical memory used by the process) is much lower than VSIZE and as long as it doesn't grow constantly over the process lifetime everything is fine (a Java memory consuption bug would manifest itself in a growing RSIZE).

http://arstechnica.com/reviews/01q4/...sx-10.1-7.html

cu
Roger

:) I save 0.8 secs using Process viewer instead of Top on my configuration...

I think (am sure?) there is a correlation between slowdowns and vsize on my machine, bu maybe that's just me. I couldn't correlate rsize and slowdowns... (except of course if LW is taking all the ram available).

Thanks for the info, I already knew that vsize was kind of weird, storing gigs in a few 53 megs page files....

Ciao

allo et voilà

I see changes in mem usage from last month too--but are you seeing more hangs? My G3 was getting sluggish, the HD thrashing: 3 LW hangs on a 24hr session.

Salut Stief :p 1.1 gigs of VM? :D My iMac would have hung for minutes... The hangs seem related to uploads, but the increase of RAM usage is definitly caused by downloads. I can't get over 100megs RAM with uploading and running as UP. However ONE huge download and running as leaf is enough to get near 200meg RAM usage. The various memory optimisations in CVS LW made thursay and friday did help a little, but the real problems are in downloads.

Ciao

Thanks for this diagnosis, et voila (and stief for posting the screenshot). We'll take a closer look into downloads. Unfortunately, it seems like 80/90MB footprint when running as an ultrapeer is going to stay for a bit... I believe the problem ultimately stems from QRP tables taking up too much memory. There doesn't seem to be any efficient sparse bitset representations for java, and making one is a very difficult (and time-consuming) task. Even sparse matrixes seem too heavyweight.

Yes--the screenshot reflects running as an UP (with no downloads), and just under 3 GB [edit] of HTTP uploads in that 24 hr period.

UP Gnutella traffic was higher than I recall too--averaging 6.9 kB/s down; 9.2 kB/s up.

Sorry if I missed a discussion of the traffic increase (not enough UP's for the great netsize growth?)--I'm catching up, and still can't get trap_jaw's BT enabled LW to connect.

Is http://www.limewire.org/jira still the place to watch for bug reports? I haven't been able to access it.

JIRA's been down for a bit. We'll get it back up at some point.

Salut Sam, I tried to get up to 200megs RAM by usual means, but couldn't :) I could with CVS of thursday, but not with the CVS of friday (friday's optimisations helped?!). I got up to 160 though. I have here infos (sreens + bug exemple and threads) available @ http://cmt.homeip.net/documents/lwinfos.zip
Process viewer analysis tool can be very helful :) On the screens you see that I have 148 megs RAM usage and 100 threads open (seem a lot for running as a leaf). I had 4 uploads and 1 dl going. The infos were taken after 20 hours of LW use. I recommend you to see the samples of com.limegroup.gnutella.gui.main and some stats at the end of that file. Tell me those stats are helpful for debugging.

All for now,
Ciao

PS: Sam. you badly need to enable PMs as this message was better suited for that, and it wouldn't clutter the thread.

Thanks very much, et voila. I notice that you have automatic reporting of bugs turned on -- could you possibly turn that off (so it shows you an error every time)? It'd be nice to see if there's an internal error prompting any of these bugs.

The only odd thing I can notice with the example bug report is that the number of "DownloadWorker" threads is 64, yet you only had 1 managed download and 1 individual worker active.

That would be consistent with your other findings that downloading is causing errors. I've been unable to reproduce this myself, so perhaps there is something unique with OSX. Do you happen to have a Windows machine, or an older OSX box to run with?

PMs would become too confusing. I've already got enough places to check for messages. ;) Besides... I'm not the only person who finds this info useful.

I have a windows xp box running 4.1.4 as a leaf on java 1.5 beta for 24 hours and memory usage is 45 megs ram and 80 megs vmem with 4 downloads active and 2 uploads active (10 waiting). It does seem normal.

Another thing: LW seems very slow at trying alternate sources from results on my mac. I tried the same search on mac and windows and the same download with a similar number of sources. The 4.1.4 version of xp was fast while the CVS os x version was dling from one host and it took a long time before trying the 10 other sources available (still downloads from one host...). It looks as if LW on my mac was having it's max simulatenous dl connexions so it avoids trying other sources. I repeated the test with other searches and same results. BTW I'm now at 121 threads with the same amount of dls and uploads as my previous report.

Here is an updated report after 43 hours.
LW is using 230 megs ram, 806 megs VM, 130 (!!) threads with 1 download and 5 uploads. The threads sample is delayed by 1 minute of the other stats and LW might be in verifying state of the downloaded file at that moment.
http://cmt.homeip.net/documents/limeinfos2.zip

No bug report window poped up in 20 hours.

Ciao

red locations?
 

what are the red locations for? They are in the "location" field on the search screen, so far it has only shown up as a single user- one IP address. Does this mean the user has nothing but corrupt files?
Alright, I think I figured it out- sort of. It is only IP addresses starting with 192. or 10.
So just cause they have a hidden IP it appears red? I dont get.

Limewire Pro Beta & Original
 

[empty]

Oops
 

[empty]