LimeWire 3.9.6 Beta
 

The LimeWire 3.9.6 beta is released, with the pro version available from a link on your Pro download page, and the free version available (with NO BUNDLED SOFTWARE) from the LimeWire download page.

Changes in 3.9.6 include:
- Search result status icons (saved, incomplete, downloading, etc...) now update to reflect the file's ongoing status. The 'saved' icon will also be shown if the file is found in the Saved folder even if the Saved folder isn't shared.
- Magnet details (from the library right-click menu) should now work under Linux with Firefox.
- ID3v2 parsing now works with non-English character sets, submitted by Roger Kapsi.
- Various focus management fixes, to put the focus in the search text boxes (or the What's New button) at appropriate times (such as when LimeWire starts).
- Fixed column size flickering.
- New default column sizes, better fitted for a brand new installation.
- Fixed search results to maintain the selection when new results come in and a filter was selected, and also when a new filter is chosen.
- Changed filters to not automatically select the result that matches a media-type search, but instead make it bold and keep it visible to inform the user a match is available.
- Reduced font size on statistics.
- Changed method for column resizing -- instead of resizing all subsequent columns when one changes, only the next column is resized. This should make it much easier to set the columns to your preferred size.
- Raised number of wanted results when LimeWire is acting as an Ultrapeer to make them behave as well as leaves.
- Fixed search progress bars & clearing filters on repeat searches.
- Randomized What's New queries a little more.
- Fixed to ignore some invalid ID3v2 headers.

This is mostly likely going to be the last beta, unless any showstopping bugs appear.

LimeWire 4.0 is going to be a fantastic release, thanks in large part to the comments on these forums and the contributions submitted to limewire.org. LimeWire is one of the few open-source programs that competes (and wins!) in the consumer market, and we're confident that the 4.0 release is going to be a rock-solid version. We've come a long way since the 3.x series, adding the revolutionary "What's New" search, an almost guarantee that every delivered result will connect and download, customizable filters for search results, ID3v2 parsing, complete international support, and many more behind-the-scenes firsts for a p2p program.

Thanks,
- The LimeWire Team

... any comments / suggestions / gripes? :)

Wow! I can't belive you managed to get all those changes included! Congrats to you and the team. Will you be celebrating so hard that we should save further comments till next fall? :D

Seriously, much appreciation from here. From opensourcer to intern to this . . . you've had a very productive year.

Cheers

looks great, guys!

>From opensourcer to intern to this . . . you've had a very productive year.

It's definitely not just me... I just happen to enjoy reading/writing on the forums and working on GUI things, so I have a more public face.

:)

The 'team' does indeed deserve the credit, and any team is made up of individual contributions. However . . . you've also taken an unfair share of the heat when times were rough.

So, a quick check confirmed that all the fixes (yay! readable stats!) are working here as far as I can tell.
some minor points (feels cheap to be even mentioning them, considering all the fixes and improvements) :(

--if it's an easy fix--why not also reduce the size of the control-click contextual menu font and keep the look consistent?

--the CNet "Review LimeWire" link in the help menu returns <We can't seem to find the page you're requesting. If you know the name of the product you're looking for, please search for it here:> Might be nice to fix that for 4.0

--I see the arrows that show a breakdown of multiple search results are gone as you warned earlier. Is there a workaround to see the IP/vendors of those sources?

--Tooltip info isn't always showing when hovering over search results. It seems I can only get audio results with tooltips.

That I like at lot, thanks
:)

I think the "what's new" should have porn filter enabled by default, even if adults keywords is unchecked in the filter options. I think many people will be disgusted to see all the porn and the pedophilia there may be on the Gnet when they only want to look at movies and video clips. (maybe add an option in filter -keywords- to disable the porn filter in "whats new" near the adult keywords filter)

Merci à l'équipe LW!:)

Got the Lime?

Magnet URI dialog
 

This is a minor cosmetic bug. So it isn't a biggie.

Running LimeWire 3.9.6 beta, java 1.4.2_04, in SuSE Linux 9.0 (at 800x600). When you copy a magnet URI to the clipboard, then switch to LimeWire, LimeWire stretches the dialog box to the width of the full magnet URI. So what I see is a dialog box that is wider than my screen can fit.

One sample URI that causes this is this:
magnet:?xt=urn:sha1:GZLEHA3FR46YNHEU5AEFUTAM5HYEEE MF &dn=LimeWireLinux.bin &xs=http://<my-ip>:6346/uri-res/N2R ?urn:sha1:GZLEHA3FR46YNHEU5AEFUTAM5HYEEEMF
(intentionally broken up with spaces to prevent it from stretching the forum's width)

Still losing selection, *sometimes*
 

In LimeWire 3.9.6 beta, although it keeps the selection longer than in 3.9.5 beta, I am still having a case where it randomly loses my selection of things in the search results. I can't 100% reproduce it but when I do a search for almost anything and select the initial results that come, and then a surge of more than 100 results comes in a few seconds later, random search results I had selected before the surge of incoming results get deselected after that surge of results came in.

Re: Magnet URI dialog
 

Magnets can contain anything and everything (and sometimes the same item several times), so there is no standard way to extract a more human-readable representation of the file contained in the magnet.

Setting a fixed maximum length may be an option but it is unlikely it will be in 4.0. Feel free to look around the code - we're open for ideas/suggestions. (com/limegroup/gnutella/gui/search/MagnetClipboardListener.java is where most of the related stuff happens)

Re: Contextual menu font-size
The font size matches up exactly with the font size of other contextual menus (such as right-clicking an item on the desktop).

Re: Review link
Being looked at.

Re: Arrows
Currently, there's no way. We had planned to have a new window that would show the other results, but we didn't have the time to do it before 4.0.

Re: Tooltip
Lots of people disliked having the tooltip pop up for every result. It's only shown now if there's metadata.

Re: Filter on what's new
Will be there before 4.0.

Re: selections
If an item came in that matched an existing result it will get grouped into that result & raise it's # count. If that happens to move the line up or down (to keep the sorting in order) AND that line was previously selected, then only that line will keep the selection (even if other things were selected). This is necessary (although the behaviour could be improved) because of some bugs with row selection in Java that extend the selection when new results are added or move around.

The 3.9.7 beta is released, with a few minor bug fixes.

Changes include:
- New default list of GWebCaches, thanks to Philippe Verdy.
- Some synchronization fixes related to alternate locations in downloading.
- Ignore errors related to loading native libraries for non-essential utility functions.
- Fixed UI bugs with making tabs visible (Monitor, Connections, Library, etc..).
- Fixed problem with selecting a value in an earlier search result filter not removing the filter from latter boxes.
- Small UI fixes for the Windows L&F on XP.

Hi all (get registered zab--I've been hoping you'd introduce yourself so we all could welcome you and then grill you mercilessly with all sorts of questions :p )

--Is there supposed to be firewall detection? Both 3.9.6 and 3.9.7 connected as Ultrapeers and didn't pick up on the fact my built-in firewall was ON (I'd forgotten to turn it off). I thought something was odd when I didn't see any incoming in the Connections Pane, and no uploads in Monitors. Luser error, LOL.

--thanks for the update on the previous notes Sam. I mostly use the tooltip to see long filenames (rarely to look at metadata), so will miss that feature in the regular releases.

--I second et voilà's idea of the porn filter being on by default. It won't stop all, but it's at least a bit more than a token gesture.

--btw--I like the way the alternate sources are totaled at the end of the results line. Much more intuitive and informative.

cheers--I'm looking forward to reading the reviews of 4, watching the effect on http://www.limewire.com/english/content/uastats.shtml and hope Philippe's work on the gweb cache's cuts down on the "can't connect" posts.

[edit--spelling correction--sorry]

1) I corrected the spelling of my first name above, 1 L, 2 P, thanks. ;-)

2) This work is not finished. In fact the list of caches will need to be updated regularly (we can see that it should be updated at least once each month, in beta versions, and make sure that a release version contains the latest working list. If a release has been published more than 2 months ago, there should be a minor update to the release branch to update that list in the donwloadable distribution. It is not necessary to advertize this minor sub-version if there's no other significant protocol implementation update or GUI bug correction. So people that have version M.n.x should not be asked to update to version M.n.y, but they may be informed if a version M.(n+1).* is released. Such information should then be displayed automatically on version (M+1).*.*

Downloadable beta versions should also expire after 2 months (so that the user downloads a newer beta, with bugs corrections and performance updates or a release): we've seen that a new component in a beta may cause unexpected problems on the network for its scalibility or on the resources of some other servers on the web.

For CVS version users, the same policy should apply: a user should update its sources to get the new update.ver file at the same time. If a user forgets to get the complete updated sources, the update.ver will expire and beta tests will no longer be helpful as their results will be too old. Some bug corections are essential for a release (some releases will discard temporarily some new components that still don't work as expected, before they get reintegrated in the development branch with their corrections).

I'm going to have to disagree with the idea of forced upgrades.

If you want to implement some nagging system, that's fine. There's already the "there's a new version of Limewire" message, that has previously included information about why it's absolutely necessary to upgrade. But, in the end, it was still my decision to install the new version.

I don't see the reason for taking the step from strong encouragement to force. It's enough to make some people suspicious of what all is included in the upgrade and possibly switch clients (or, edit the source to bypass the check).

effect of Web proxy
 

How does the new proxy option work? Does it alter which IP number I am using?

Re: Re: Magnet URI dialog
 

When spaces are intentionally added into the magnet URI, LimeWire properly wraps the magnet URI in the dialog. Without spaces, no wrapping occurs and it simply makes the width of the window be as wide as the magnet URI is, no matter how long the magnet URI is, even if the resulting dialog doesn't even fit the screen. That is what I was referring to. So if someone actually wanted to read the entire magnet URI, they have to drag the dialog around and if the URI is long enough, it might even be possible that the Yes and No buttons might not even be visible on the screen when copying a magnet URI without having to drag the dialog box around.

Why do you think that I want a forced upgrade?
I was speaking exactly about the condition that makes the "upgrade available" alert to appear. What would be forced is the display of this information box. By "expiring" I mean really the condition that allows a servent to run without this forced message at startup. Users can still dismiss and choose to update later...
But if they ignore it and restart the servent, they will see again this dialog (once).
This is an important feature notably for beta versions and CVS-compiled versions (with its own signed "update.ver" file), so that preliminary code will not harm the network for too long after a major bug is discovered.

Re: Re: Re: Magnet URI dialog
 

A solution could be to display the message with a specific dialog which includes a scrollable area with autowrap enabled.

The dialog box will still be bounded, and the full URL will still be accessible and readable...

See for example the presentation adopted in the web page displayed when you click on "Show Magnet URI details" for one of your files in your library.