Re: Push Proxies in download mesh.
You'd be surprised how little this would help, in the current incarnation atleast. Alternate locations go out of date very quickly, and adding another very transient piece of data (the ultrapeer of a host) to the information would just pollute the mesh with lots more garbage, leaving the directly connectable hosts in the dust. Push proxied hosts also are completely meaningless for other hosts that are firewalled. Perhaps once fw->fw transfers are in, we'll take another look at how effective push proxies can be in the mesh.

Re: "seekable integrated player"
No clue what this is. I know we recently (a version or two ago) did some changes with the player... dunno if that was it.

Re: lots of updates
What is going wrong with the English installer?

Re: LAN IPs in browse-host
LimeWire doesn't actually know their real IP (atleast at the time the tab is created). It connects using push proxies, so the results display fine.

Re: Sorting bitrate wrong
Yeah, that's always been that way. It sorts by alphanumeric values, not numeric values. (So it's not really a double digit then triple digit thing, it's that the number 9 or 6 is higher than the number 1.) It'll be fixed at some point, but probably not for 4.0.

Re: Firefox & Linux
Not sure what's going wrong. LimeWire should be listening on a specific port for the request. To be honest, I'm not sure this will be fixed before 4.0 unless it's also happening on Windows and/or OSX.

Re: Localization & connections
This is by design. As a leaf, LimeWire will try for about 30 seconds to find an Ultrapeer of the same locale. If it doesn't find one, it just gives up (instead of creating massive connection churn). As an Ultrapeer, LimeWire doesn't actively seek the same locale, but instead reserves 3 slots for incoming connections of the same locale. When LimeWire 4.0 ships, connecting to users of the same locale will be much easier because the locale is now placed in the pong.

Re: Losing the selection
Fixed in the development version.