LimeWire 4.10.7's been out for a day or so. Changes are listed at http://www.limewire.com/english/cont..._history.shtml .

If folks could give this a whirl and let us know how it goes, it'd be much appreciated. There's some serious changes to the internal networking code, and we'd like to make sure everything works.

If you do LAN transfers (from one computer to another within the same network) and they're both using this newer version, you'll notice the transfer speeds are faster than anything you've ever seen since 4.9.0. (We saw ~5,000kbps speeds.) Even if you don't do LAN transfers and both sides are using this newer version, transfer speeds should be faster.

Thanks.

RKapsi, I noticed the improved iTunes support for videos. On OSX does that mean automatic import for mpeg 4 files? It seems like something easy to add. Perhaps not everybody would desire their movies be imported also, but if they are, then they could just as easily be deleted from iTunes. Just a few days ago I tested out my new dvd player which supports divx/xvid/mpeg4 & simply burnt a data dvd-rw with music clips, & they played happily on the player. (Cost equivalent of US $80.45)

What are the improvements for iTunes video if this is not the case? "Added support for sharing video files via DAAP (to programs such as iTunes)"

* Whilst I was running Panther & 4.10, I found my VM usage whilst using the search function seemed to have a memory leak. Has this been repaired? Will this also occur on Tiger using Java 1.5? Perhaps it's system & hardware related ... I upgraded about a week ago. I found instant improvements in Java 1.5 but didn't try 1.4.2 in Tiger & haven't been using 4.10 (was too impractical before ... see jum's last thread in this section!)

Sam, let me be the first (around here) to give you a warm welcome back. I also like the new changes. (btw, I've been bitching about LAN transfer speeds for a long time now. its about time you remove the cap on it! )

I also want to say that spam is on the rise (in a few areas). A few things to seriously consider for the next release:

1) Along with WMV/ASF files, ASX files should also be ignored by default. As I already told Roger about this: "ASX files are textual command files that manage streaming of ASF files." These files are being used specifically by spammers. Since you already ignore ASF files by default, why not ignore the files that are used to control them?

2) The most important of all: Action URL Launching. The word is out!! Spammers are using this technique now. Its only a matter of time before a malicious user will take this convient tool and destroy gnutella (and its users) with a nice exploit through a browser. Think of how many LW users run Internet Explorer. Its an exploit playground. (to the average user that reads this, i just have to recommend the firefox browser instead of Internet Explorer - www.getfirefox.com)

well I doubt it will make much difference or any on my machines since LW was already capable of maxing out my connection with no problem 750KB/s+ but I will give it a try.

ultracross

Have you given IE 7 Beta a try they have made some improvements to browser safety and it loads pages allot faster. It has a Phishing filter in it now and they say the official release will be even faster and more secure than the beta. Personally I like but haven't really be able to test the new security that much yet. It has blocked a couple of web pages with the Phishing filter but I don't know if they were actually Phishing pages.

__________________










A little common sense goes a long way

Later Grandpa

Some bug reports:

LimeWire version 4.10.7 Pro
Java version 1.5.0_06 from Sun Microsystems Inc.
Windows XP v. 5.1 on x86
Free/total memory: 2505280/23158784

java.lang.RuntimeException: java.io.IOException: Unable to establish loopback connection
at com.limegroup.gnutella.io.NIODispatcher.swapSelect or(NIODispatcher.java:504)
at com.limegroup.gnutella.io.NIODispatcher.run(NIODis patcher.java:542)
at java.lang.Thread.run(Unknown Source)
at com.limegroup.gnutella.util.ManagedThread.managedR un(ManagedThread.java:64)
at com.limegroup.gnutella.util.ManagedThread.run(Mana gedThread.java:53)
Caused by: java.io.IOException: Unable to establish loopback connection
at sun.nio.ch.PipeImpl$Initializer.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.nio.ch.PipeImpl.<init>(Unknown Source)
at sun.nio.ch.SelectorProviderImpl.openPipe(Unknown Source)
at java.nio.channels.Pipe.open(Unknown Source)
at sun.nio.ch.WindowsSelectorImpl.<init>(Unknown Source)
at sun.nio.ch.WindowsSelectorProvider.openSelector(Un known Source)
at java.nio.channels.Selector.open(Unknown Source)
at com.limegroup.gnutella.io.NIODispatcher.swapSelect or(NIODispatcher.java:501)
... 4 more
Caused by: java.net.SocketException: No buffer space available (maximum connections reached?): listen
at sun.nio.ch.ServerSocketChannelImpl.listen(Native Method)
at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
... 13 more


Detail: Uncaught thread error.

-- listing session information --
Current thread: NIODispatcher
Active Threads: 31
Uptime: 6:50:07
Is Connected: true
Number of Ultrapeer -> Ultrapeer Connections: 0
Number of Ultrapeer -> Leaf Connections: 0
Number of Leaf -> Ultrapeer Connections: 2
Number of Old Connections: 0
Acting as Ultrapeer: false
Acting as Shielded Leaf: true
Number of Active Uploads: 0
Number of Queued Uploads: 0
Number of Active Managed Downloads: 1
Number of Active HTTP Downloaders: 9
Number of Waiting Downloads: 0
Received incoming this session: true
Number of Shared Files: 10
Guess Capable: true
Received Solicited UDP: true
SIMPP version: 44
Port Stable: true
FWT Capable: true
Last Reported Port: 6390
External Port: 6390
IP Pongs Received: 0

-- listing threads --
JmDNS.RecordReaper: 1
HttpClient-ReferenceQueueThread: 1
MessageDispatch: 1
Thread-9: 1
QueryUnicaster: 1
ManagedDownload: 1
Java2D Disposer: 1
TimerQueue: 1
DownloadWorker: 9
BlockingVF: 1
MulticastService: 1
Acceptor: 1
HttpClient-IdleConnectionThread: 1
Java Sound Event Dispatcher: 1
AWT-Shutdown: 1
AWT-Windows: 1
AWT-EventQueue-0: 1
Timer-0: 1
QRPPropagator: 1
DestroyJavaVM: 1
DaapServerThread: 1
HTTPAcceptor: 1
JmDNS.SocketListener: 1


-- listing properties --
WINDOW_Y=63
FORCE_IP_ADDRESS=true
WINDOW_X=23
PORT=6390
TTL=5
RUN_ON_STARTUP=false
UPDATE_DELAY=431999998
UPDATE_GIVEUP_FACTOR=24
SEARCH_MAGNETMIX_BUTTON=true
FILTER_HASH_QUERIES=true
INSTALLED=true
UI_LIBRARY_TREE_DIVIDER_LOCATION=193
EXTENSIONS_TO_SEARCH_FOR=html;htm;xml;txt;pdf;ps;r tf;doc;tex;m...
AVERAGE_UPTIME=148990
TOTAL_UPTIME=1340915
MAX_UPLOAD_BYTES_PER_SEC=85
MIN_CONNECT_TIME=7
COUNTRY=
TREE_NODE_PREFIXES=a
LAST_SHUTDOWN_TIME=1139877343578
APP_WIDTH=981
SESSIONS=9
SHOW_TOTD=false
FILTER_ADULT=true
FORCED_PORT=6390
ALLOW_PARTIAL_SHARING=false
LAST_ACCEPTABLE_BUG_VERSION=4.10.4
DOWNLOAD_SPEED=16
FRACTIONAL_UPTIME=0.13306428
CONNECTION_SPEED=3000
LAST_EXPIRE_TIME=1138761836921
MAX_DOWNLOAD_BYTES_PER_SEC=475
UPDATE_DOWNLOAD_DELAY=10000000
RUN_ONCE=true
APP_HEIGHT=658
EVER_SUPERNODE_CAPABLE=true
MAX_SIM_DOWNLOAD=8
LAST_GWEBCACHE_FETCH_TIME=1139671890890
EVER_ACCEPTED_INCOMING=true
UNSET_FIREWALLED_FROM_CONNECTBACK=true
CLIENT_ID=0442606738FE89A9FF5199D6ED087400
FILTER_WHATS_NEW_ADULT=false
PARALLEL_SEARCH=10
FLUSH_DELAY_TIME=256
IDLE_CONNECTIONS=2
CONNECTION_VIEW_ENABLED=true


-----------------------------------------------


LimeWire version 4.10.7 Pro
Java version 1.5.0_06 from Sun Microsystems Inc.
Windows XP v. 5.1 on x86
Free/total memory: 1711792/23158784

java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Unknown Source)
at com.limegroup.gnutella.downloader.ManagedDownloade r.startWorker(ManagedDownloader.java:2297)
at com.limegroup.gnutella.downloader.ManagedDownloade r.fireDownloadWorkers(ManagedDownloader.java:2484)
at com.limegroup.gnutella.downloader.ManagedDownloade r.performDownload(ManagedDownloader.java:1990)
at com.limegroup.gnutella.downloader.ManagedDownloade r*****run(ManagedDownloader.java:759)
at java.lang.Thread.run(Unknown Source)
at com.limegroup.gnutella.util.ManagedThread.managedR un(ManagedThread.java:64)
at com.limegroup.gnutella.util.ManagedThread.run(Mana gedThread.java:53)


-- listing session information --
Current thread: ManagedDownload
Active Threads: 35
Uptime: 6:49:57
Is Connected: true
Number of Ultrapeer -> Ultrapeer Connections: 0
Number of Ultrapeer -> Leaf Connections: 0
Number of Leaf -> Ultrapeer Connections: 2
Number of Old Connections: 0
Acting as Ultrapeer: false
Acting as Shielded Leaf: true
Number of Active Uploads: 0
Number of Queued Uploads: 0
Number of Active Managed Downloads: 1
Number of Active HTTP Downloaders: 9
Number of Waiting Downloads: 0
Received incoming this session: true
Number of Shared Files: 10
Guess Capable: true
Received Solicited UDP: true
SIMPP version: 44
Port Stable: true
FWT Capable: true
Last Reported Port: 6390
External Port: 6390
IP Pongs Received: 0

-- listing threads --
HttpClient-ReferenceQueueThread: 1
NIODispatcher: 1
UDPHostRanker: 1
DownloadWorker: 10
Acceptor: 1
MulticastService: 1
AWT-EventQueue-0: 1
AWT-Windows: 1
AWT-Shutdown: 1
Java Sound Event Dispatcher: 1
Timer-0: 1
DestroyJavaVM: 1
JmDNS.RecordReaper: 1
Image Fetcher 3: 1
MessageDispatch: 1
Thread-9: 1
QueryUnicaster: 1
ManagedDownload: 1
Java2D Disposer: 1
TimerQueue: 1
BlockingVF: 1
HttpClient-IdleConnectionThread: 1
QRPPropagator: 1
HTTPAcceptor: 1
DaapServerThread: 1
JmDNS.SocketListener: 1


-- listing properties --
WINDOW_Y=63
FORCE_IP_ADDRESS=true
WINDOW_X=23
PORT=6390
TTL=5
RUN_ON_STARTUP=false
UPDATE_DELAY=431999998
UPDATE_GIVEUP_FACTOR=24
SEARCH_MAGNETMIX_BUTTON=true
FILTER_HASH_QUERIES=true
INSTALLED=true
UI_LIBRARY_TREE_DIVIDER_LOCATION=193
EXTENSIONS_TO_SEARCH_FOR=html;htm;xml;txt;pdf;ps;r tf;doc;tex;m...
AVERAGE_UPTIME=148989
TOTAL_UPTIME=1340904
MAX_UPLOAD_BYTES_PER_SEC=85
MIN_CONNECT_TIME=7
COUNTRY=
TREE_NODE_PREFIXES=a
LAST_SHUTDOWN_TIME=1139877343578
APP_WIDTH=981
SESSIONS=9
SHOW_TOTD=false
FILTER_ADULT=true
FORCED_PORT=6390
ALLOW_PARTIAL_SHARING=false
LAST_ACCEPTABLE_BUG_VERSION=4.10.4
DOWNLOAD_SPEED=16
FRACTIONAL_UPTIME=0.13306428
CONNECTION_SPEED=3000
LAST_EXPIRE_TIME=1138761836921
MAX_DOWNLOAD_BYTES_PER_SEC=475
UPDATE_DOWNLOAD_DELAY=10000000
RUN_ONCE=true
APP_HEIGHT=658
EVER_SUPERNODE_CAPABLE=true
MAX_SIM_DOWNLOAD=8
LAST_GWEBCACHE_FETCH_TIME=1139671890890
EVER_ACCEPTED_INCOMING=true
UNSET_FIREWALLED_FROM_CONNECTBACK=true
CLIENT_ID=0442606738FE89A9FF5199D6ED087400
FILTER_WHATS_NEW_ADULT=false
PARALLEL_SEARCH=10
FLUSH_DELAY_TIME=256
IDLE_CONNECTIONS=2
CONNECTION_VIEW_ENABLED=true

Hi all, and thanks Sam for the changelog and asking for feedback here again.

Re LAN transfers--no luck here, but some improvements noted.

--The upload bandwidth controls still seem to control even LAN transfers. I had mine set on both machines to 90 KB/s. Could LAN transfers be made exempt from the bandwidth controls?

--even with the upload bandwidth slider set to "Unlimited" on either or both machines, transfers were limited to not much more than 150 KB/s

--browsing each machine was not smooth--several tries were needed. I remember LAN browsing being almost instant. Port 20300 opened and forwarded on one machine; 20303 on the other.

the good news: the Monitor pane showed only a single upload (in the past two uploads showed per transfer; one to the router's internal IP; the other to the machine's internal IP)

Both machines were running LW PRo 4.10.7, but different java versions. 1.5.0_05 on the laptop; 1.4.2_09 on the desktop.

Attached Images

lan.png (29.7 KB, 63 views)

I have to say that I did not even see the speed increase over LAN transfers.

Any chance something changed in 4.10.7 to increase CPU %?
On a 1.4 GHz G4 running Mac OS X v. 10.4.4 on ppc (1 GB RAM), I was surprised to see the CPU use seems to be much higher than I recall from last summer.

(btw--the VM problem is still the same, but that's not new).

Attached Images

cpuchart.png (50.6 KB, 59 views)

I didn't get around to trying 4.10.7, but just trying 4.10.8 now. I notice my pre-4.9 incompletes refused to load. lol Anyway more to today's issues, I've been finding some odd behaviour. Tiger 10.4.4 with Java 1.5; Audio downlds are seeming to freeze LW during verification (just small files) but the downld & importation into iTunes still continues. I was surprised to see my search & verfication freeze (at 90%) but then iTunes open & import. Similar for the next file. A total freeze of LW except for prefs. 3rd downld the same, froze at 93% verification but iTunes still imported it. The freeze seems to last for a reasonable time after iTunes has imported it. There doesn't appear to be any jump in VM or ram during that time but cpu does jump up.

In one search (my 1st) I initially obtained many results, but suddenly these disappeared. These were files of all sizes & names & artists. I ended up with "only" results of the artist I was after. The search tab shows eg 40/80 as though the others have been filtered out. I didn't see why the others should have been filtered out. CPU is running around 15-20% for a simple downld & upld, 167 MB ram, 543 MB VM, after 4rth search & 1 browse. A browse seems to shoot cpu up to about 50%, with vm & ram staying about the same. End of browse cpu drops down. I have to say since all my searches were for the one artist, not one of them shows any other artists. Is this something new or is this the junk filter gone wild (the level is set on mildish)? I haven't filtered out much at all - just 2 in fact. Or do you think this complication is related to me using old preferences? I forgot to mention, I was doing Any Type searches not audio type searches. And it was only the very 1st search that showed a 40/40 result with the other 40 disappearing. The rest "only" showed the artist I was searching.

The search tab seems to jump into the next hidden thingy ... I have to select that search from the arrow next to the tab to see it when multiple search tabs are present.

But I'm not so far suffering the vm issue I did with the initial 4.10 release. But then I'm running Java 1.5 & Tiger now.

2nd edit: Update: 4rth downld froze at 98% verif. & cpu jumps all around between 50-85%, mostly around the 80% mark during this time & freeze lasts for about 1 minute.

3rd edit: Now some hours later. I did a search, started downlding a file & despite another 2 results (sources) showing up it went to busy host, so I pressed cancel & LW froze up for just over 2 mins. I was still mid-way through the search also. When the freeze stopped, the search had finished. I was at least able to reselect the downld & get it downlding from 2 of the 3 hosts in the search results. But then, I lost one of the hosts & the other went to busy again. So I repeated the process, same thing ... freeze for over 2 mins. cpu jumping between 30-50% & vm 589 & ram 237. Then same thing happened a 3rd time running. cpu goes back down to 20% or less afterward. I had another downld going but this wasn't affected, although it of course froze in the downld window but didn't seem to be affected when the freeze stopped. (BTW I use a Quicksilver 733 with 1.5 GB pc 133-333 ram.)

4th Edit: (almost an hour later) I notice that the file that I cancelled earlier, after coming out of Busy Host, then downlds with 2 sources for a short time but very quickly goes back to busy (after about 10-15 secs & stays busy for 1-2 mins). That's very odd it should do this from 2 hosts simultaneously. Almost as though it is the same host. Well there's about 1 second difference between the 1st & 2nd host starting to downld from. Ah I've noticed it's not always 2 hosts. But did this for some time anyway up until a couple of mins ago. It downlds at 10-13 KB/s or 5 KB/s (depending on occasion). I started this downld about an hr ago.

I had a kern protection failure when LW tried to access iTunes, and the iTunes EULA was hidden. That was on the desktop machine (10.3.9, java 1.4.2_09, and LW Pro 10.4.7), which I hadn't used with LW for quite a while.

Not sure what was going on, but sent the report to Apple with a comment that they support their java.

Thanks for the heads-up on 4.10.8--off to download

I can confirm a spike in the verification process. As I already told Roger Kapsi, it would probably reduce a huge bottleneck if the verification of chunks while downloading would be verified in memory instead of writing to the disk, then verifying it. Verifying it in memory cuts the read/write process in half since you download it, verify it in memory then write it to disk instead of downloading it, writing it to disk, then verifying it. Make sense? This could also potentially speed up the downloading process as a whole. I just know that its killing my disk with amount of read/writes its doing.

Or maybe a hyrbrid combination if the user doesn't have enough RAM?

Making sure we understand correctly a during the verification process the entire LW application freezes, but an import into iTunes succeeds, and eventually LW recovers from the freeze? If so, does this happen only with audio files of certain size? Does it also happen with video files (those should be shared with iTunes), and any other type of file?

What exactly do you mean by "A total freeze of LW except for prefs." Are you able to open and use the LW preferences? Do they get saved properly if modified?

Could you please try to compare whether the cpu and disk activity of 4.10.5 during the verification phase with that of .6, .7 or .8. Also, if you could get a stack trace during the freeze it would help us a ton.

__________________
The more you debug it, the more it bugs

The same issues haven't been evident. So despite using the console to make reports, there's nothing to report. I wonder if it was initial taking over of older version preferences. So I haven't had the same problems reported earlier. No freezing for verification or canceling downlds.

Videos appear in iTunes playlist if that's what you wanted to know. Are you intending to leave as an option in the LW preferences for potential future auto-importing of videos to iTunes on OSX?

After 12 hrs of leaving LW static (but uplding), VM was around 750 MB & after 4 hrs of searching & downlding it finished at just over 900 MB. Closing off windows, searches & console reduced it by perhaps 8 MB.

Edit: I will add though that LW just crashed whilst running in the background. It hasn't done that since I updated to Java 1.5 a couple of weeks ago.

Beta 4.10.9 is out. It reverts some of the changes that went into the last three betas and should use less cpu and cause less disk activity. Unfortunately, LAN transfers may be slower. Please give it a try and let us know how it goes.

Best,
LW dev team

__________________
The more you debug it, the more it bugs

Nothing special to report, other than after about 18 hours of use, all of a sudden both RAM & VM are suddenly on the increase whilst LW is not downlding (is uplding.) Have downlded large files over this time. Have 6 search tabs still up. I did a search just 5 mins before the 1st snapshot image below.

There's 3 mins between no. #1 & 2, 10 mins between no. 5 & 6, 22 mins between 1 & 6. It seems LW or Java has reached that point it just collapses in handling LW. Using Java 1.5, OS 10.4.4, LW 4.10.9
At this moment, 10 mins after the last snapshot, the ram is 348 MB, VM=2.04 GB, & 2,181 threads.

I can presume that LW will crash within the next half an hr. I presume this is OSX Java right & not LW's fault.

Attached Images

lw4.10.9ram.gif (14.6 KB, 36 views)