LimeWire 4.1.1 Beta
 

The LimeWire 4.1.1 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 is no Mac Classic release for LimeWire 4.1.

LimeWire 4.1.1 is the first of a series of betas that will build up to the release of LimeWire 4.2. LimeWire 4.1.1 includes only the first batch of many changes that will be included in LimeWire 4.2.

LimeWire 4.1.1 includes:

- A new 'Direct Connect' search that allows you to browse a host directly.
- A brand new "file view" that allows you to easily share files with friends, by giving them a simple URL. Friends can choose to download either via the web or within LimeWire itself. You can access this by selecting a bunch of files in the library, right-clicking and choosing 'Web Page for Files". The option will only be available if LimeWire detects that friends will be able to make a connection to your computer. All access is controlled by a password that is generated each time LimeWire is started.
- Support for 'brushed metal' on OSX 10.3+. Just choose the 'Brushed Metal' skin!
- New sort arrow icons for OSX that look more like the native icons used by other OSX programs, contributed by Roger Kapsi.
- A completely brand new (and much prettier!) 'Annotate' interface for audio files, contributed by Roger Kapsi.
- Support for reading metadata from M4A & OGG files, and writing metadata for OGG files.
- The ability to have typing on a table automatically select and move to a row that matches what you typed for. For example, if you have search results for, "LimeWire, BearShare, or BitTorrent", typing 'L' will move to & select the row with LimeWire', typing 'B' will move to BearShare's row, and typing 'B' again will move to BitTorrent's row. (Alternatively, typing 'Bi' would also move to BitTorrent's row.)
- Support for using command C, V, X and A in tables for copying, pasting, cutting & selecting all rows when using OSX.
- The ability to hit 'enter' to initiate the default action for a table (such as downloading in the search results, launching in the downloads, browse-hosting in connections, etc..) instead of requiring a button is clicked or double-clicked.
- A new progress bar when starting LimeWire, to show that LimeWire really is doing things!
- Much faster download connections to hosts that require a push. This is done by using UDP to send the initial push request to either push proxies or the host itself.
- Extremely optimized hashing calculations (both SHA1 & Tiger), contributed by Philippe Verdy. In some cases, files can be hashed over twice as fast!
- The server side of a new addition to downloads that will allow partial file sharing to scale to a greater number of users.
- Notification to Ultrapeers to stop sending queries while LimeWire is already completely full handling upload requests, contributed by Gregorio Roper.
- A new (turned off by default) search result column that displays the time the file was added to the network. Note that this will only work if the replies were returned from newer LimeWire clients.
- An additional option for throttling bandwidth of downloads, contributed by Eugene Romanenko.
- Faster loading of the Tips of the Day.
- Removed the 'compression' options, since compression should be used by everyone.

LimeWire 4.2 is going to contain a whole slew of features that will make LimeWire easier to use and perform even better than it used to. This release has a lot of new code, so we'd appreciate everyone's help in ironing out any bugs, and of course more suggestions for features.

Thanks to all the open-source contributors and the beta testers!

Thanks.
The LimeWire Team

Salut Sam, great!. I was waiting that you release the beta before telling you bugs I have with my compiled CVS version.

1)resizing down to a certain extent the LW window in os x loose the connection status bar as well as the bottom buttons.

2)the file view in browser doesn't support accentuated caracters as é, è, à and show interrogation marks.

3)when the ISP change the IP address while LW is running, LW retain the old IP address as a X-alt source. I got up to 22 sources for non uploaded files over a week and those 22 sources were all my old IP addresses. Pretty easy to fix I guess.

All for now. Merci beaucoup! :)

PS1: when will the console tab will appear? This could help a lot test the betas.
PS2: about mac classic, there should be an advisory in the Pro registration process so those users don't get rip off. I agree to drop 1.1.8 java support, but since you have paid customers, be vigilent if you want to avoid problems.

Great changelog once again, and I'm looking forward to trying out all these impressive developments, especially the copy/paste and browser developments.

Any pointers on which versions to test for hashing speeds? I'd been reading about Philippe's optimizations for a while, but wasn't sure when they were integrated.

Just a quick note: Tried to install, but no error message came up. Here's the console entry:

Quote:

Copying /Volumes/LimeWire/Install LimeWire.app/Contents/Resources/Install LimeWire.pkg to /tmp/LimeInstallation/5018 mkdir: /tmp/LimeInstallation/5018: Permission denied cp: /tmp/LimeInstallation/5018: Permission denied Checking Pro/Free 2004-07-01 12:43:42.488 open[5023] No such file: /tmp/LimeInstallation/5018/Install LimeWire.pkg

Deleting the /private/tmp/LimeInstallation/ allowed the install to proceed.

Metal OSX theme: dragging the upload bandwidth slider also drags the preference window (workaround--using the arrow keys on the keyboard).

stief, do you use fast user switching and have you rebooted your machine since your last LW installation?

Hi Roger

Nice icons and arrows (haven't tried the annotation much yet)

yes, fast user; and no, no reboot for a few days.

hehe, thanx - it's all a preparation for the next big thing(tm). :D

oh and is there a chance that you installed LW on a different account than this time?

The following steps are necessary to reproduce this:

Install LW on account A
do not reboot in the meantime
switch to account B and try to install LW

Hi Roger--lots of goodies to try :)

I wanted to try out the weblink by mailing you a picture link, but in the annotation window--couldn't select a portion of the filename (seemed to be the metal theme drag problem). I'll try again.

Anyway, the install problem reproduced as you instructed (I also logged out of the previous account).

Deleting the LimeInstallation folder allowed the install to proceed, but this time also the console noted a Finder crash as well

Quote:

Date/Time: 2004-07-01 14:57:59 -0600 OS Version: 10.3.4 (Build 7H63) Report Version: 2 Command: Finder Path: /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder Version: 10.3.1 (10.3.1) PID: 335 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Here's a picture of one of the kid's pets if anyone wants to try the link. Let me know how the bandwidth speeds go.

now-dead link edited

I'm not sure how the password works :confused:

Worked great Stief! On this exemple http://x.xxx.x.xxx:6346/get/235/546489/allo.txt, the password is a number, 546489 in that case. If you restart LW the "password" will change. 235 is the number assigned to the file allo.txt. If I type http://anip/gnutella/file-view/apassword/ I'll see all the shared files of that IP.

Ciao

Ah--thanks. I guess that password is to stop the web-leeching that almost killed gnutella ~2 years ago.

Anyway, the upload pane showed some oddities. I tried the link myself just before you did, then while you were getting the file I set the bandwidth to unlimited. The progress display doesn't look right, and the speeds aren't correct (not averaging fast enough?)

Speed was fast and I didn't get a problem finishing or opening it. Surely a display glitch.

À+

Merci et voilà
This also brings up another glitch--I didn't realize I was sharing some incomplete files. BAD! Now I see why so many OSX'ers are sharing incomplete files.

When an incomplete tune is previewed or launched in LW, looks like a copy is also sent to iTunes.

Hope this is an easy fix (Roger?).
Any chance we'll be able to see the playlists in the Library, or else have the option to show files as flat rather than nested in the LW Library? This is going to be a pain to hunt those incompletes since they show with different names in the iTunes playlist.

Well, time for a drink. Cheers to all.

but in the annotation window--couldn't select a portion of the filename

I'm not sure what you mean with this. The new annotate window is only available for audio files (mp3, ogg, m4a etc.).

kid's pet: cute :)

Ah! I couldn't edit the filename in the annotate window of the hedgehog.jpg (OSX pinstripe theme).

Do you think you the annotation capabilities can be extended for iPhoto images also?

btw--the advanced button on an iTune file also wouldn't let me edit the filename (but name is editable in the Library list).

This also brings up another glitch--I didn't realize I was sharing some incomplete files. BAD! Now I see why so many OSX'ers are sharing incomplete files.

I think it is a bug in the html page generator. It doesn't filter incomplete files.

When an incomplete tune is previewed or launched in LW, looks like a copy is also sent to iTunes.

Hope this is an easy fix (Roger?).

hmm, there shouldn't be a relation. LW's iTunes integration is limited to add newly downloaded songs to itunes (and only if they just finished downloading). The launch button on the other hand is like a double click. It just starts the associated application and LW doesn't know which and if an application is associated with a file at all. The build-in player is completely independet from iTunes...

yeah, that's the old annontate window (it's also acting as the advanced editor for audio files). It has some flaws. :)

You are right Roger (no surprise there, eh?)--almost all the 50 incomplete files that showed in my file-view were from the incomplete folder. One was from iTunes, but it was from a month ago. I couldn't find a way to get LW to send a partial to iTunes.

On a minor oddity noted in uploads, I guess LW 4.0.5 uploads at "110%." Now that's turbocharged :p

I'm scratching my head over download rates and verification times: looks like Pro is way faster than Basic or ACQX on ethernet transfers:

I installed various versions (only one at a time) on the G4 iMac and downloaded a 699 MB .avi file with the G3 iBook running Pro. Basic and ACQX were way slower than Pro, and verification time seemed high--5 minutes and 29 seconds. Both machines had upload and download bandwidth prefs set to "unlimited."

As a quick comparison, a Finder transfer of the file between the machines took 2 minutes and 20 seconds--that's almost half as long as it took LW to verify the file.

Excluding the verification time which was the same, Pro served up the file in ~ 8 or 9 minutes ; ACQX 36 mins, and Basic 28. Too much difference, no?

Anyway, here are the numbers that showed in tooltips, and my best guess as to actual transfer rates if verification time subtracted.

LW 4.1.1 (Pro) 14:43 (1,408 KB/s) = 1,273 KB/s
ACQX 110.3 41:04 (379 KB/s) = 334 KB/s
LW 4.1.1 (Basic) 32:07 (486 KB/s) = 446 KB/s
LW 4.1.1 (Pro) 13:48 (1,520 KB/s) =1,410 KB/s
FINDER 2:29 =4,810 KB/s

Is this a stats display problem? Free throtting? Luser error? :confused:

4.1.1 Pro Beta feedback
 

Excellent update; I installed 4.1.1 Pro (from usual pro customer link) over my prior 4.0.7 installation without any problems -- it installed, ran immediately, and has been very stable (no crashing or freezing so far). The system specs for the computer I'm running 4.1.1 beta on follow my signature below.

As promised, I'll now spend some time working with 4.1.1 with regard to the magnet updates, "semi-private networking" features, and HTTP server updates that we discussed in the following prior posts and that I in turn committed to testing in terms of the enterprise (company workstations, desktops, and network) when this beta arrived:

Limewire 4.0.6 Breaks Magnet Links
http://www.gnutellaforums.com/showth...threadid=26254

Semi Private Limewire Network?
http://www.gnutellaforums.com/showth...threadid=26205

Limewire Pro 4.0.7 HTTP Web server Functional?
http://www.gnutellaforums.com/showth...threadid=26450

Thanks again for a great product -- the upgrade to Pro was well worth it.

Aaron
----
System specs for LW Pro 4.1.1 beta test:

OS: WinXP Pro, SP 1, up to date with patches/updates
as of July 15th 2004

CPU: Pentium 4 2.8Ghz, Hyperthreading, 800MHz front side bus

RAM: 512MB

Motherboard: Asus P4P800-E Delux

Hard Drive: 72 GB Serial ATA (Raptor; Western Digital)

Video Card: PNY nVidia FX 5200 AGP 128MB ("Verto")
---

4.1.1 Magnet Test Results -- Pass and Fail
 

As a followup to my previous reply I have posted details on magnet link tests with Limewire 4.1.1 Pro BETA, which fixes the issues with Bitzi magnets that I previously reported (below). However, the download never does start even though the magnet is accepted by Limewire. Details, and test materials, are provided at:

http://mantiscorp.com/people/aew/lim...agnets411.html

A description of the original problem reported to this forum is available in this thread:

Limewire 4.0.6 Breaks Magnet Links
http://www.gnutellaforums.com/showth...threadid=26254

Over the next few days I'll test the other features mentioned in previous reply. For the record, I've been running 4.1.1 beta with lots of uploads and downloads for several days straight, day and night, without any crashing or freezing -- it's good and stable on my system.

Aaron
----
System specs for LW Pro 4.1.1 beta test:

OS: WinXP Pro, SP 1, up to date with patches/updates
as of July 15th 2004

CPU: Pentium 4 2.8Ghz, Hyperthreading, 800MHz front side bus

RAM: 512MB

Motherboard: Asus P4P800-E Delux

Hard Drive: 72 GB Serial ATA (Raptor; Western Digital)

Video Card: PNY nVidia FX 5200 AGP 128MB ("Verto")
---

Wait a sec, have you taken a closer look at your magnets? They contain your IP (the xs parameter) and if you delete the file it is certainly no longer available. So how do you want download something that no longer exist? Keep in mind that LimeWire does not trigger auto searches...

Magnet handlers should not rely on hosts specified by the xs attribute
 

Rkapsi, are you referring to the Magnet411.html test results page located at:

http://mantiscorp.com/people/aew/lim...agnets411.html

I believe so, and will explain what those test steps mean in more detail below with regard to your point about the IP address:

I downloaded the test files using Limewire specifically so that I could create the magnet links using Limewire's built-in feature (when a file's in the Library I right-click on it and select "Magnet Details for File...").

Then, I delete the file so that it's not in my own library -- the test files are widely available on Gnutella and so I simply delete my own copy so that I can test the magnet links that Limewire creates for them; the files are still available on Gnutella, by many users, so removing them from my own library doesn't make it impossible to find (doing so only forces Limewire to actually try and find it on the Gnutella network by using information contained in the xt magnet link attribute). I intentionally delete the file from my own library because if I try to use a magnet link (click on it from a Web page, for example) for a file that's already in my library Limewire won't even attempt to download it, which makes sense. By deleting it, I force Limewire to actually use the entire magnet link -- the files are still available from many users on the Gnutella network (I intentionally choose popular files for this test so that when I deleted them from my library Limewire would still be able to find many sources on the network).

In summary: After I've obtained a widely available file I then construct the magnet link as described and then *delete* the file from my library so I can test if the magnet link I just created actually works. Because the test files I'm using are widely available, Limewire should have no problem accessing them via the magnet link. Limewire should use this portion of the magnet link for the Macbeth.txt file, for example, to find sources for the file on the network:

xt=urn:sha1:EECI66YQYRH347K7S5O3NNFP5SSSQDUV

As you point out the xs attribute (not xt above) does contain my IP (or the IP of whatever machine the magnet link was created on if Limewire was used to create the link). This is how Limewire creates magnet links, so I didn't remove the xs attribute. However, a static IP address such as stored in the xs attribute should *not* be the *only* way the file is located. The xs attribute identifies a specific location for a file (http://###.###.###.etc) which is only one way to find the file, and that http location should be combined with the xt attribute to enable multi-source downloads (swarming).

If the file isn't available via the IP address specified in the xs attribute the download should still happen because xs contains a globally unique, location-independent identifier (urn:sha1:###) that provides Limewire with all of the information it needs to find and download the exact file specified. There's no open-ended search involved using xs. In other words, based on the urn:sha1 value stored in xt Limewire can locate and start downloading the exact file automatically even if the IP host specified by the xs attribute is not available.

This is especially important to do on a dynamic P2P network such as Gnutella where the host specified by the xs attribute can "go away" moments after the magnet link is created. Since I created these links on my own computer, for instance, if I quit Limewire the xs attribute is no longer valid since Limewire's no longer available to handle incoming those http request. Similarly, if I shut down my computer the IP specified by xs is no longer available. Even if I just restart my computer the IP address changes since I (like many other users) have a dynamic IP address that is assigned to me when I connect to my ISP: each time I connect I am assigned a different IP address. Therefore, the xs attribute can never be considered reliable. Limewire should use xs as one of many potential sources, but shouldn't rely on the xs host being available. Instead, xs should be combined with xt for multi-source downloads of a file that's precisely identified by the urn:sha1 value.

Currently Limewire 4.1.1. Beta fails to start the download after it receives and parses certain magnet links, but it does just fine with others. More precisely, it fails to start the download for magnet links that I create using Limewire itself as described in my Magnet411.html page. I can force it to do so by clicking on the "Find More Sources" (or Resume) buttons, as described in my Magnet411.html page, but the program should actually initiate the download itself and not require human intervention in this way. In these tests the magnets are created by Limewire for widely available files on the Gnutella network: it should have no problem finding them, and will do so if I manually click on the "Find More Sources" (or Resume) buttons, otherwise the download will never happen (it just waits and reports that it needs more sources although many are actually available).

Does that help clarify the testing procedures I used in the Magnet411.html file?

Aaron

Again, LimeWire does not search automatically for files on the network. Auto searches killed almost Gnutella and as long as no one has a sudden inspiration how to solve that problem it won't change.

Until then magnets rely on the IP provided via xs parameter.

I'm afraid that I don't understand what you mean in terms of auto-searching drains the network. Does Limewire currently only use the IP address specified by the xs attribute in the magnet link, and ignore xt altogether intentionally because using it would cause more traffic? Or do you mean that it intentionally processes the magnet link (and handles the xt info properly) and shows the file name in the download area, but doesn't actually start the download until the users clicks on "Find More Sources". That is, do you mean that enabling someone to click on a magnet link on a Web page to have Limewire search/download automatically based on the xt urn:sha1 part of the magnet is intentionally not fully implemented by Limewire and that human intervention (clicking on "Find More Sources") is intentionally required because that that extra step somehow puts less strain on the Gnutella network?

In any case, why would searching for files automatically via magnet links be any worse than the manual searching that we do now (i.e, typing in search terms)? Tons of traffic, both searching and downloads, are the result of people trying to find specific files that aren't easily identified on the network (and so trial/error to find them ensues).

A magnet link may require more hops to find the exact file since using the xt=urn:sha1 information forces a search for a precise file, but that shouldn't cause a great deal of traffic since large lists of "possible matches" don't need to be returned for vague search terms -- only when an exact match is found does a download start, otherwise return results should be ignored (or, ideally, not returned at all if an exact match isn't found for a specific sha1 hash). Perhaps Gnutella doesn't support searching for an exact file?

I would think that being more precise by specifying the exact file to download would be better for network traffic overall because users could then find exactly the files they want faster and with less searching than if using the usual keyword (manual) approach. The download traffic, in particular, should be much less: with precise magnet links I could get exactly the file specified by the magnet, whereas with a manual search I have to type in keywords and start the search, download potential matches from a large list of files that's displayed, and then preview a lot of files as they download to see if I got what I wanted. Most of the time I have to repeat this process over and over until I get what I want, meaning I generate a lot of traffic (both for search terms and downloaded files that are aborted after preview, or download entirely then deleted upon realizing they're not what I want). A good implementation of magnet links could eliminate a lot of wasted searching and downloads, which in turn would save a lot of bandwidth.

Is there some history on the auto-search problem that I can look at to get a better context for the reason Limewire doesn't support it?

Aaron

Here's a thread:

http://www.gnutellaforums.com/showth...ight=auto+find

Search for the term "auto find"

LimeWire does not ignore the various attributes of a magnet link but if xs fails it doesn't take further action to find the file automatically (e.g. by ds or xt).

Agreed -- don't use auto searching (auto-requeries)
 

Thanks for the link -- I took a first pass, and will study in more detail, but at first blush it seems that the issue described in the forum discussion you've pointed me at is about the negative impact of "auto-requeries" (auto searching) which I agree with and don't suggest be changed for magnets. The problem at the moment with regard to Limewire's handling of magnets is that it never actually sends out a first query in the first place (other than to the IP address specified by xs, which will almost always fail on a dynamic p2p network since IP addresses change frequently and host computers come and go continually). So I think we're saying the same thing in terms of the bandwidth issues and auto-requeries (auto search) -- don't use auto-requeries for magnets at all, but simply do a single initial query based on the xt=urn:sha1: info so that the process of clicking on a magnet and having it at least start the download (if possible) is seamless and reliable.

So rather than support auto-requeries it's only a matter of Limewire doing a single query in the first place using the xt=urn:sha1: info instead of relying on the http:// IP host info provided in xs. This would be the equivalent of doing a single search, but in this case for a specific file. If that search fails to turn up any files then don't do an auto-requeries, but instead require the user can click on "Find More Sources" as usual. The problem is that currently the first search doesn't take place at all, other than for the http:// on a specific IP addresss specified by xs.

Since the proposed fix doesn't require auto-requeries, won't create large amounts of traffic, and is only needed to properly process a magnet links would Limewire do that?

Aaron

Confirmed -- don't need auto find ("auto-requeries" / auto searching)
 

I have finished reading the entire forum about auto finding that you pointed me at, and can confirm what I wrote previously: auto find (aka "auto-requeries" or "auto searching") is not needed to fix the magnet download problem. Although it would be nice if there was a solution to the auto find issue I wasn't suggesting it for fixing the magnets and it isn't a feature that I'm suggesting be implemented at all; my only concern was that Limewire breaks in terms of handling the magnet if the original http:// source isn't available (and it almost never is; in the month or so that I've been testing magnets with Limewire only a few have ever worked seamlessly -- I end up manually searching for the file once the magnet fails to download because the host specified by the xs attribute isn't available).

My reason for posting my magnet test results was to provide details so that developers could fix the download issue, which seems pretty straight-forward and doesn't require auto-finding. If Limewire attempts just a single search (and not more) for the file specified by a magnet's urn:sha1:### info that would solve the problem I've reported. If that single search comes up empty, then it's up to the end user to manually "Find More Sources".

This solution (a single search based on the urn:sha1:### info if the xs http:// host is not available, but *not* using auto-find/search to repeatedly do the search) won't create the bandwidth issues that resulting in the auto find feature being removed from Limewire in the first place and would fix the problem with magnet links.

I think we were talking about two different things entirely for most of this dicussion, and hope this clarificaiton helps (and thanks for the material on why auto-find was removed in the first place).

Aaron

Actually, I think we could use some kind of auto-requerying.

I've been using a auto-requery-enabled LimeWire at home and it really works a lot better if LimeWire does the find more sources queries fully automated, one more FMS per hour. BearShare is using automated requeries, too and I think sooner or later we will see LimeWire use limited automated requeries again.

Magnets and Medical Apps
 

I'm not opposed to auto-requeries being implemented in Limewire in some form if the implementation doesn't flood the network, but for this particular feature (fixing the broken magnet download process) I'd be just as happy with a single-search based on the urn:sha1:### info to start. If auth find makes a comeback as a result that'd be great, but it not even having the single search occur seamlessly would be a great step forward since currently using only the http:// host is only useful when the host is a stable system on the network (very few are -- almost every magnet link I've tested is not available in Limewire since it relies exclusively on the IP host, whereas they work just fine in other p2p programs that actually use the extra info to search.

Shareaza, for example, does a good job of handling magnets. When a magnet is used with Shareaza it displays a dialog box to the end user asking if they want to download the file immediately (via the http:// host) or start a search (using the hash info).

Simply fixing the broken magnet download process (so that it starts a search at least once) would be a big step forward for integrating Limewire with the Web. Over this summer we're testing Limewire Pro and other P2P clients on a medical network that uses a Web-based front end to present doctors and patients with media (owned by the hospitals; no copyright issues). Currently Limewire doesn't work because it doesn't integrate well with the enterprise or the Web. To integrate with the Web it requires seamless downloading of magnets, and also the ability to hand-back the content it downloads to the client (serve to the client after processing the request to download a file). To integrate better with the enterprise we need some form of control over which nodes a given Limewire client will interact with. All of these are fairly straight-forward updates, and would go a long way toward making Limewire Pro suitable for enterprise (business) applications, and so I'm more than happy to do the extensive testing needed to help make that possible.

Aaron

brilliant
 

Hi Shipmates
I have been trying various P2P clients and have seemed to use Limewire more than the others and find the whole experience very easy on the brain which is always good! Respect to the people that are involved in presenting it to us out here and you should all pat yourselves on the back and it takes a hell of a lot for me to say this .......so Thanks for a pretty good experience and cant wait for what you do next!
Regards
Pirate