LimeWire 3.9.10
 

The LimeWire 3.9.10 beta is released, with the pro version available from a link on your Pro download page, and the free version available from the LimeWire download page.

Changes in 3.9.10 include:
- Fixed some conditions where reading ID3v2 tags would fail.
- Fixed dynamic querying when locales were involved.
- Fixed the font size of the menu options (File, Tools, Help, etc..) in all themes except the Default OSX Theme (which was already correct).
- Fixed auto-matching of possible filter choice to reselect a new match when the filter changes.
- Fixed creation of icons for default search types so that they will work on Mac Classic again.
- Fixed wishlist/download button to correctly transform and be enabled at the appropriate times.
- Fixed error associated with Java 1.3 and clipped tooltips.

LimeWire 4.0 is still on schedule for Tuesday, May 18th.

Thank you to everyone who has helped us to build LimeWire into the sophisticated, easy-to-use file-sharing program that it is. We are consistently #1 and #2 on Mac downloads on download.com, and in the top 10 Windows downloads. The removal of bundled software from all versions of LimeWire is right in line with people's choices, as evidenced by the fact that Ad-Aware is the #1 download for Windows on download.com (and has been for two weeks now).

Thanks,
The LimeWire Team

3.9.10
 

The "About" pane still says 3.9.9.

Looks good here.
minor notes: A Magnet download didn't recognize that the file was already in a subfolder of the shared folder.
--About box shows 3.6.10 Pro
--OSX installer sets permissions on limewire app to an admin user other than the one requested by the installer.
--Spelling correction for the getting started screen: "you can narrow you[r] search results."
--Allow the columns to be widened by taking space from the next possible column (for the case when the next column is already minimized).

The 3.9.11 beta is released.

A few small fixes are in 3.9.11:
- Fixed magnet registration on English LimeWire PRO for Windows installer.
- Typo in 'Getting Started' image is fixed.
- The shopping tab is now named 'Shopping'.
- Some more ID3v2 fixes.
- Some fixes that could have caused 'Could Not Move to Library' on OSX (and other Unix-based systems).

Thanks,
The LimeWire Team

What do you mean with "sets premissions on limewire app to an admin user"? Do you mean the group, the owner or the premissions for others?

Hi Roger. The owner gets set to another owner; the other permissions are the same as yours.

I run two admin accounts on my laptop--one for work (lets call it "worker") and one for LW ("stief"). Quite a neat feature of Panther, btw. When I login to 'stief' and install LW under the 'stief' account, the owner is set to "worker", even though the installer ask me to authenticate using the "stief" password.

I just checked: set up a new admin user "roger", downloaded the 3.9.11, installed, authenticated with "roger", and permissions are set on the new LW 3.9.11 app for owner "worker".

I suspect the permissions problem has more to do with OSX's Installer.app. We'd be very hesistant to change the installer seven days before a major release... It'll get fixed, if it can be fixed, soon though.

On another note... does anyone have suggestions for new 'Tips of the Day' for 4.0?

Yep, I think it's an Installer.app issue. I assume it picks the first best non-root admin account (stief: was "worker" the first admin account on that machine? With NetInfo Manager you can see if "worker" is the first non-root user in the admin group -> /groups/admin). I've tried to install it from the root account and it set my admin account "roger" as the owner...

Yes Roger--you're right. "worker" is first user after root in NetInfo (root is not enabled). Nice catch.
It seems harmless (only noticable when a jum install is forbidden). btw--have you tried running LW as a separate user? I find it almost as good as running LW as a background app (daemon?), and it seems to run just fine. I want to eventually set it up on the 24/7 machine just to serve up private magnets.

As for TOTD Sam, numbered tips would be handy and ordered more logically (I wasn't sure if I had gone through them all or saw a duplicate).
--add some of the useful links, like Roger's iTunes guide http://www.kapsi.de/files/itunes.html and more of the links Ursula put together http://www.gnutellaforums.com/showth...threadid=24520
--add a recommendation to use AdAware or its like (and repeat that LW no longer supports spyware)
--add a definitive note about the difference between Pro and Free

3.9.11 buglet: sort by location
 

In the search results window, sorting by location doesn't work. Clicking on the header, the arrow changes direction but the listing isn't sorted; nothing happens. (Sorting works on all the other columns.)

LimeWire 3.9.12 is released.

Changes in 3.9.12 include:
- Added workaround for faulty JIT on OSX 10.2 with Java 1.4.1. Previously TigerTree hashes were corrupted because of this bug.
- Added status of what core components are loading just after the GUI becomes visible.
- Removed 'Chat' buttons from downloads & search results. (You can still chat from the right-click menu.)
- Fixed sorting on location column.

In five days LimeWire 4.0 will be released.

Thanks,
The LimeWire Team

KDE/Gnome Menu Entries
 

Could future versions of LimeWire's installer in Linux drop in KDE/Gnome menu entries?

The guide at:
http://freedesktop.org/Standards/des...ry-spec/0.9.4/
explains how to format a ".desktop" file.

http://www.freedesktop.org/standards...8/ar01s02.html
and http://freedesktop.org/Standards/bas...6/ar01s03.html explain where to place the ".desktop" files.

On SuSE 9.0, none of that XDG environment variable stuff seems to be defined so, $HOME/.local/share/applications/ works as a decent place to drop in a ".desktop file when the installer is being run as a normal user. When it is being run as root, it should drop a ".desktop" file in /usr/share/applications/ and it would appear on all user's menus.

Following their specification, a working ".desktop" file I created looks like this:
If LimeWire is ever uninstalled, removing its entry is as easy as removing the LimeWire.desktop file it dropped in $HOME/.local/share/applications/ or /usr/share/applications/ (and possibly also rebuilding the menu cache if the uninstaller is run within kde using "kbuildsycoca" but I don't think that is required).

The specs at www.freedesktop.org regarding .desktop entries seems to work ok in KDE 3.1.4, I haven't tested any other environment though.

Note that this bug occured only on Mac OSX 10.2. The compiled code was correct, just executed incorrectly by the Mac version of Java 1.4.1. If someone, using this OS for Java programming knows how to avoid this problem or why it occurs, it could be helpful to investigate it , because the bug does not occur when LimeWire is run in interpreted mode (-Xint) without JIT enabled.
Sam posted a bug report to Apple, but this also indicates possible unpredicable bugs elsewhere in other parts of LimeWire or in any other Java application.

The bug is isolated and reproductible with the two classes published in the GDF Files section that implement and test the "Tiger" MessageDigest,:where there's a separate extensive test class that demonstrate correct results on Windows, Linux, Unix, Mac OSX 10.1, 10.3 or other versions of Java on OSX 10.2.
Shamely for OS X 19.2 i affects the latest version of Java for that platform. So this is a regression bug of Java. The precise condiions for which this bug occurs are unknown.

May be there's a way to remove some code optimizations to make the class work on Java 1.4.1/OSX10.2. For now Cryptix will be used, but it's much slower and it will require an extra JAR file.
I wrote his class, but I have no Mac OSX to investigate it.

'?' in filenames
 

I am in the process of downloading some songs from another user, but alas two of the titles have question marks (fairly common in song titles). For example:
Should I Be Sweet?

This song is listed in the Search results, but when I click on it, I get a "Need more sources" message which I assume is a "File not found" error message on the remote machine. According to the Results window it is running Lime, but alas doesn't indicate which version.

On my OS (OS/2), question marks aren't allowed in filenames, and for better or worse I have been forced to get in the habit of removing them. Apparently, this individual is using an OS which does permit them, but his/her version of LimeWire isn't taking this into account. Is this a current issue or has this been fixed in earlier versions?

Thanks and keep up the good work.

in 3.9.12 beta pro on 10.3.3, the filters sometimes switch to audio, and stick there, after a repeat search (no filters active before the repeat search was chosen). I ran out of time to nail down the steps required to repeat. The screen shot shows all filters set to "All" but the results locked into "Audio"
ps--is the clarity of these screenshots OK? Too large?

Re: Magnet URI dialog
 

we are experimenting with a new linux installer which does that (and is faster, better looking, has less carbs...)

It will not be in for 4.0 and for at least a week or two afterwards though. If you are interested in helping, check out http://bitrock.com/

Any areas you want us to concentrate on this weekend?

Try everything you possibly can to break LimeWire. That's about it.

Re: Re: Magnet URI dialog
 

I tried out their installer and it definitely is looking nice!

Could I suggest to override the SetToolTipLocation() method for the JMultiLineToolTip so that the tooltip will not extend below the bottom limit of the visible desktop? (the tooltip will not display completely, not ably for rows in the Connections table).

The default computed location just attempts to position the tooltip below the mouse cursor position, and adjusts it above to make it fit in the physical screen, but not on the visible desktop.
With my bottom desktop toolbar, this hides about 4 lines of the tooltip text.

One suggestion would be that if the mouse is at or below the middle of the screen height, then the location should be set above the mouse cursor rather then below it, keeping the adjustment to avoid it to go above the top of the physical screen.

Also, tooltips for table rows may better be aligned horizontally with the hovered table cell for which the tooltip is displayed. Clicking on the tooltip should have the same effect as clicking on the table cell, after the tooltip is closed, if the cell is editable and the tooltip does not spans on several lines (for example when renaming files). If the tooltip can fit on the cell space, and the cell is fully within the visible desktop area, then there's no need to move it above or below the mouse cursor.

Since ~3.9.7
 

On startup, LW often lingers for a few minutes at Quality: Poor. A glimse at the Connections window reveals only one or two connections to other peers and leaves.

If I disconnect and connect, within a flash the Connections window is flooded with connects and within ~20 seconds at least a dozen connections have been established and Quality: Turbo is displayed .

This seems to have been introduced with the defaualt list of GWebCaches introduced in 3.9.7 but I am not sure about this.

3.9.12 grabbing CPU
 

After running 3.9.12 ~30 hours, it has started grabbing >95% CPU time after running ~60 seconds. This is AFTER shared files have been scanned, AFTER the connections have been established.

I have backed down to earlier versions, even rebooted, yet it now occurs with 3.9.12 every time I run it. It isn't at all obvious what it can be because it isn't caused by any user interaction, but if I had to GUESS, I'd wonder if it didn have something to do with the regular out-of-memory messages I have been getting.

Re: 3.9.12 grabbing CPU
 

Such message won't be very helpful if you don't specify your system settings (use the "generate error" menu option to list all relevant information).

I have run this version since several days without such problems (on Windows XP, with both Java 1.4.1-04 and 1.5.0-Beta1).

Also it would be helpful to know if this occurs while the GUI is displayed or when it is running in the system tray or iconified.
If this occurs with the GUI displayed, which panel is active?

If this is caused by a file recently downloaded, it would be helpful to determine which (We have seen some occurences of MP3 files that caused such behavior in previous betas, but it's possible that there exists similar problems, caused by some strange ID3v2 tag formats which may let the code allocate excessive buffers for parsing it.)

Re: Since ~3.9.7
 

I don't think so. Disconnecting and reconnecting will just attempt to reuse the same existing list of peers that existed before disconnecting. At startup, there's lot of things to do in LimeWire, so connections may be slower. Once all gets in place, things go faster.

LimeWire has worked a lot to optimize the init phase and reduce its power up time (including reducing the time to process list of Gwebcaches).

Just disconnecting/reconnecting will not trigger new accesses to Gwebcaches.

What may happen is that your last saved list of peers was outdated (because you had not run it for some time), so LimeWire will first attempt to connect to them before querying Gwebcaches if this list is exhausted.

Other sources of peers comes from attempts to connect to busy hosts with no more connection slot (they report other peers they know in a X-Try-UltraPeer header). This minimizes accesses to Gwebcaches.

The problem of Matamoros is that he is on os/2 and there is no LW devs including open sourcers that test LW on that OS... (Never seen myself an os/2 OS except in screenshots).

Ciao

Quote:

Originally posted by verdyp With my bottom desktop toolbar, this hides about 4 lines of the tooltip text.

This happens on OS 10.3.3 too, but the tooltip window correctly remains within the bounds of the LW Window on the right (which is where I usually have my Dock).

However, when resuming a download or trying to use the scroll bar, several clicks may be required. Could the tooltip window be made 'transparent' for mouseclicks?

Re: Re: 3.9.12 grabbing CPU
 

Where is this menu option? I don 't see it anywhere.

options->bug reports->view example

Are upstream stats reliable? This is an old problem, but just in case it's more than a GUI problem, here's a screenshot. (14 hrs uptime; uploads throttled to 101.25 KB/s on a 1 mbps cable connection)

Ah, right. But I don't see anything about "generating an error message" that Verdyp is referring to. This panel is referring to the errors messages that LW generates , no?

In the menu! You don't need to open the options panel to generate a pseudo bug-report for display: Help->Generate error

http://www.rodage.net/private/report1.png

This will open a "Internal error" alert that you can consult with the second button.

http://www.rodage.net/private/report2.png

The whole report is in the white scrollable area, which is selectable (you can copy from it).

http://www.rodage.net/private/report3.png

Then click OK to close it, and finally "Reject" in the first screen to ignore the report (don't need to send it to LimeWire, as it's a faked error, but not a bug in the software).

The "Generate Error" menu option is only available in CVS versions of LimeWire. We don't want generated exceptions bogging down our bugserver.

You can view a similiar report in production versions by going to Tools -> Options, Bug Reports, and choosing 'View Example'.

I should have noticed it... Thanks for noting it is is absent from beta versions (I thought it was only missing in releases).
Well we could as well disable the "Send report" button. Of course the "View example" button in options pane will work as well.

Transparency may not work on MacOS Classic, it is tricky to program due to display refreshes. If your display board does not support accelerated alpha transparency, this may take lots of CPU time.
Well I think that the simplest would be that a click on a tooltip forces it to close, so you can click behind it.

The upstream bandwidth currently only counts the actual TCP payload (ignoring automatic retransmissions in case of TCP errors detected), but not the TCP header or IP headers which are unpredictable due to buffering within the OS, and not even the PPP/LCP overhead on the internet link or the ATM encapsulation.

To get more accurate data, you need to estimate the overhead, or look into OS statistics (you won't get data below the IP level (i.e. PPP/LCP or ATM framing will not be visible on DSL/cable connections; on 56K modems, you can get the final bandwidth sent to the modem in the OS statistics, but even in that case your modem will apply its own protocol (data compression, error control, and framing bits).

The true bandwidth used is hard to determine (you can just take an estimate of about 5% of overhead for the underlying transport or link protocols).

Also the "spiky" bandwidth is typical in case of slow or far downloaders, that can't reply in sustained time. This spiky curve is smoothed when there are parallel transfers to distinct hosts.

Ok, I have restarted 3.6.12, it is now hogging CPU at >95%. Now I open the "sample error" message window. but unlike LW's error messages there is no cptoin for copying the text , unless there is some undocumented keyboard combination (Ctrl-Ins doesn't seem to work). I hope you aren't expecting me to type the text line-by-line into my browser :(

OK, Use Ctrl+C to copy the selected text...

This gives me a suggestion for the GUI: add tabbed panes in the About box, with one listing this configuration (without the unneeded error trace). And add a Copy button in the bug report view.

Another suggestion: couldn't we display the startup tips in the empty search result window, beside the promotional HTML panel?
This would allowing closing permanently this tip window that I find irritating, but it would be visible enough to inform users.

Ok, to start with, I deleted all the files in .limeware except createtimes.cache and
fileurns.cache (it takes ages to regenerate these). This cleared up the above-mentioned startup problems (<strike>except for some reason that LW is reconnecting as leaf rather than UP, even though the latter is enabled</strike>it is now running as UP). Now, I startup, and within 60 secs, LW starts grabbing >99% CPU.

I have a 2048/1024 ASDL connection and am sharing ~4,5k files

<pre>
LimeWire version 3.9.12 Pro
Java version 1.4.2_01 from Sun Microsystems Inc.
OS/2 v. 20.45 on x86
Free/total memory: 12014248/66650112

java.lang.Exception: Example Bug
at com.limegroup.gnutella.gui.options.panes.BugsPaneI tem$1.actionPerformed(BugsPaneItem.java:91)
at javax.swing.AbstractButton.fireActionPerformed(Unk nown Source)
at javax.swing.AbstractButton$ForwardActionEvents.act ionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed (Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseRe leased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent( Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(U nknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unkno wn Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForHierar chy(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarch y(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarch y(Unknown Source)
at java.awt.Dialog$1.run(Unknown Source)
at java.awt.Dialog.show(Unknown Source)
at com.limegroup.gnutella.gui.options.OptionsConstruc tor.setOptionsVisible(OptionsConstructor.java:372)
at com.limegroup.gnutella.gui.options.OptionsMediator .setOptionsVisible(OptionsMediator.java:84)
at com.limegroup.gnutella.gui.GUIMediator.setOptionsV isible(GUIMediator.java:536)
at com.limegroup.gnutella.gui.menu.ToolsMenu$1.action Performed(ToolsMenu.java:26)
at javax.swing.AbstractButton.fireActionPerformed(Unk nown Source)
at javax.swing.AbstractButton$ForwardActionEvents.act ionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed (Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.AbstractButton.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(Unk nown Source)
at javax.swing.plaf.basic.BasicMenuItemUI$MenuDragMou seHandler.menuDragMouseReleased(Unknown Source)
at javax.swing.JMenuItem.fireMenuDragMouseReleased(Un known Source)
at javax.swing.JMenuItem.processMenuDragMouseEvent(Un known Source)
at javax.swing.JMenuItem.processMouseEvent(Unknown Source)
at javax.swing.MenuSelectionManager.processMouseEvent (Unknown Source)
at javax.swing.plaf.basic.BasicMenuUI$MouseInputHandl er.mouseReleased(Unknown Source)
at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent( Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(U nknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unkno wn Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForHierar chy(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarch y(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)


Detail: Example

-- listing session information --
Current thread: AWT-EventQueue-0
Active Threads: 50
Uptime: 46:18
Is Connected: true
Number of Ultrapeer -> Ultrapeer Connections: 0
Number of Ultrapeer -> Leaf Connections: 0
Number of Leaf -> Ultrapeer Connections: 7
Number of Old Connections: 0
Acting as Ultrapeer: false
Acting as Shielded Leaf: true
Number of Active Uploads: 9
Number of Queued Uploads: 0
Number of Active Managed Downloads: 1
Number of Active HTTP Downloaders: 1
Number of Waiting Downloads: 1
Received incoming this session: true
Number of Shared Files: 4885
Guess Capable: true

-- listing threads --
Acceptor: 1
AWT-Shutdown: 1
AWT-EventQueue-0: 1
TreeHashTread: 1
pinger thread: 1
QRPPropagator: 1
MessageLoopingThread: 8
QueryDispatcher: 1
MulticastService: 1
HttpClient-ReferenceQueueThread: 1
TimerQueue: 1
FileManager.loadSettingsBlocking: 1
UDPService-Receiver: 1
TimerRunner: 1
DownloadWorker: 1
OutputRunner: 7
ConnectionDispatchRunner: 9
QueryUnicaster: 1
ConnectionWatchdog: 1
DestroyJavaVM: 1
Java2D Disposer: 1
PlayThread: 1
Thread-131: 1
AWT-Windows: 1
HttpClient-IdleConnectionThread: 1
Thread-397: 1
HTTPAcceptor: 1
ManagedDownload: 2


-- listing properties --
LAST_EXPIRE_TIME=1084664429120
UPLOADS_PER_PERSON=1
CLIENT_ID=488128BDC479AD40FF38C518E2C46100
FREELOADER_FILES=100
EVER_ACCEPTED_INCOMING=true
EVER_SUPERNODE_CAPABLE=true
FREELOADER_ALLOWED=10
MAX_UPLOAD_BYTES_PER_SEC=117
TOTAL_UPTIME=3922
PORT=6348
CONNECTION_VIEW_ENABLED=true
CLEAR_UPLOAD=false
AVERAGE_UPTIME=3922
EXTENSIONS_TO_SEARCH_FOR=mp3;ogg;jpg
INSTALLED=true
MAX_SIM_DOWNLOAD=12
LAST_GWEBCACHE_FETCH_TIME=1084664458460
CONNECTION_SPEED=1000
MAX_DOWNLOAD_BYTES_PER_SEC=4
</pre>

It seems you are alone to test LimeWire on OS/2. It seems to be an issue with the virtual memory management (with committed memory) on OS/2, and difficulties to handle multiple threads efficiently on this platform, and to support CPU throttling:

I note that you share a lot of files, but you have erased your THEX data cache. This is still a new feature in LimeWire, ant i will take time until all your files are indexed.

What seems to happen is that this occurs the first time a user starts downloading from you with THEX control. THEX tree data is not computed immediaely when you add files in the library. Instead it is computed in parallel with uploads.

I made special efforts to maximize the throughput and efficiency of the THEX hasher (which is running on is own thread on your host), so that it won't take lot of time to compute. However, throttling of this hasher by concurrent threads seems to be ineffective on OS/2. As there's nobody at LimeWire or in our open-sourcers that has worked to see what's happening on your platform, there's littel we can do to help you.

One suggestion:
Exit limewire, save your limewire.props file and the thex and urn cache files as well as the file stats cache.
Then restart with much lower number of shared files (for example reset the configuration to share the default share directory).
Restart and share only a few popular (but not too large) files, and see what is happening. You'll see a CPU spike when the first file will be uploaded, when this file gets THEX-hashed.
It should return to normal just after.
If you see that, then it just happens because your thex cache file was emptied.
You may then restore your saved settings. No immediate solution for you on OS/2 until all your popular files get THEX-hashed on demand. I recommand you check your system settings related to virtual memory management (if you don't have a permanent and unfragmented swap space, you could experiment long delays o perform efficient multithreading).


On Windows, my UltraPeer (using an Athlon XP 1800+) handles more than 450 concurrent threads with 5 to 10% of CPU usage...

Another guess: ID3v2 parsing?
 

Ok, I am now back-tracking from version 3.9.12 trying to discover in which version the CPU hogging starts.

At version 3.9.10, after ~60s , rather than the CPU jumping to 99%, I get a the following error message (twice) during a lot of disk activity. Is it something to do with ID3v2 parsing? In other words, in subsequent versions, does something get caught in a loop rather than generate an error???

LimeWire version 3.9.9 Pro
Java version 1.4.2_01 from Sun Microsystems Inc.
OS/2 v. 20.45 on x86
Free/total memory: 30632248/66650112

de.vdheide.mp3.ID3v2BadParsingException
at de.vdheide.mp3.ID3v2Frame.<init>(ID3v2Frame.java:2 31)
at de.vdheide.mp3.ID3v2.readFrames(ID3v2.java:936)
at de.vdheide.mp3.ID3v2.<init>(ID3v2.java:92)
at de.vdheide.mp3.ID3v2.<init>(ID3v2.java:118)
at com.limegroup.gnutella.mp3.ID3Reader.parseID3v2Dat a(ID3Reader.java:228)
at com.limegroup.gnutella.mp3.ID3Reader.parseFile(ID3 Reader.java:131)
at com.limegroup.gnutella.mp3.ID3Reader.readDocument( ID3Reader.java:115)
at com.limegroup.gnutella.xml.LimeXMLReplyCollection. constructDocument(LimeXMLReplyCollection.java:245)
at com.limegroup.gnutella.xml.LimeXMLReplyCollection. <init>(LimeXMLReplyCollection.java:198)
at com.limegroup.gnutella.xml.MetaFileManager.loadSet tingsBlocking(MetaFileManager.java:304)
at com.limegroup.gnutella.FileManager$1.managedRun(Fi leManager.java:592)
at com.limegroup.gnutella.util.ManagedThread.run(Mana gedThread.java:49)
Parent Cause:
java.lang.OutOfMemoryError


-- listing session information --
Current thread: FileManager.loadSettingsBlocking
Active Threads: 39
Uptime: 1:39
Is Connected: true
Number of Ultrapeer -> Ultrapeer Connections: 0
Number of Ultrapeer -> Leaf Connections: 0
Number of Leaf -> Ultrapeer Connections: 6
Number of Old Connections: 0
Acting as Ultrapeer: false
Acting as Shielded Leaf: true
Number of Active Uploads: 4
Number of Queued Uploads: 0
Number of Active Managed Downloads: 0
Number of Active HTTP Downloaders: 0
Number of Waiting Downloads: 0
Received incoming this session: true
Number of Shared Files: 4885
Guess Capable: true

-- listing threads --
Acceptor: 1
AWT-Shutdown: 1
AWT-EventQueue-0: 1
TreeHashTread: 1
pinger thread: 1
QRPPropagator: 1
MessageLoopingThread: 6
QueryDispatcher: 1
MulticastService: 1
HttpClient-ReferenceQueueThread: 1
TimerQueue: 1
FileManager.loadSettingsBlocking: 1
UDPService-Receiver: 1
TimerRunner: 1
OutputRunner: 6
ConnectionDispatchRunner: 4
QueryUnicaster: 1
ConnectionWatchdog: 1
Image Fetcher 0: 1
DestroyJavaVM: 1
Java2D Disposer: 1
PlayThread: 1
AWT-Windows: 1
HttpClient-IdleConnectionThread: 1
UDPService-Sender: 1
HTTPAcceptor: 1


-- listing properties --
LAST_EXPIRE_TIME=1084675839590
FILTER_ADULT=true
UPLOADS_PER_PERSON=1
SHOW_TOTD=false
CLIENT_ID=04D10FE24F6DF66BFF2E1BC688810700
FREELOADER_FILES=100
EVER_ACCEPTED_INCOMING=true
BANNED_WORDS=.wma;.rm;.m4a;.swf
FREELOADER_ALLOWED=10
MAX_UPLOAD_BYTES_PER_SEC=77
TOTAL_UPTIME=1700
PORT=6349
CONNECTION_VIEW_ENABLED=true
CLEAR_UPLOAD=false
AVERAGE_UPTIME=1700
EXTENSIONS_TO_SEARCH_FOR=mp3;ogg;jpg
INSTALLED=true
MAX_SIM_DOWNLOAD=8
LAST_GWEBCACHE_FETCH_TIME=1084677177130
CONNECTION_SPEED=350
MAX_DOWNLOAD_BYTES_PER_SEC=2

First, thanks for the taking the time to address these issues; I realize that OS/2 is not a priority.

Perhaps. But I didn't have this problem until a recent beta.

Oops. That is the filename of the THEX cache? Next time I will be more careful.

Well,I am now running LimeWire 3.9.10 in the background (~14 uploads at the moment) and total CPU usage is around 5%. It is only versions 3.9.11 and 3.9.12 where I encounter this problem.

I have 512 MB of memory, and the swap file (2MB) is unused, so fragmentation is not an issue.

default as leaf?
 

Starting with a fresh configuration several times in the course of various experiments this evening, I notice that LW (I am using v3.9.10 right now) apparently defaults to function as a leaf rather than a Ultra Peer, even though Disable UP is by default unchecked in the options.

To get around this, I checked this option, saved options, then unchecked it, save again, and then disconnected and reconnected. LW then (nearly instantly) connected as a UP.

multithreading
 

At the moment, I have 3.9.10 running as UltraPeer with 12 uploads and 147 threads; in total my system has 340 active threads. CPU usage fluctates around 8-14%. I think OS/2 is also pretty good at multithreading.

Re: default as leaf?
 

I's normal that your servent starts as a leaf with a fresh configuraion: your public ip has no been validated, and there is no past proof of bandwidth and no past proof that your servent can accept incoming connections. Also, it needs to proove that your serven has a good past of connection availability.
The election mechanism needs several conditions before a node can become an UltraPeer. And even in that case, the promoion will only occur if you get replies from the network that more ultrapeers are needed. Of course this will only happen provided that Ultrapeer support is not disabled.
When you stop your servent, some statistics are computed and stored, and benefit to the next restart (the delay before resarting is taken into account to compute your host availability).

Re: Another guess: ID3v2 parsing?
 

We know that there are issues in ID3v2 parsing, because of he way it encodes some field sizes (and ambiguities in its past specifications).
If you have an example of such MP3 file that causes such issue, i would be good to upload it somewhere in a private URL, and to report this URL in a email to dev(at)core.limewire.org (don't post a file to this developers mailing list).
I had personnally a similar issue with a MP3 file that was created or tagged by an unknown codec or tagging tool. The solution o this problem was in a revision of the ID3v2 spec.
We have put some security for this parsing (because in the past it could cause LimeWire to not starting): now we track some malformed or unexpected formats, as well as the possible out of memory errors they could produce.
If your MP3 plays well in your player, or if your player displays the ID3v2 tag correctly, then we have another issue with an unsupported format. Now there is the ID3v2 spec, but there are also undocumented features used in some codecs or taggers, and sometimes too some bugs in various MP3 tagger tools.
The LimeWire's code tries to manage them by at least ignoring unparsable ID3v2 frames. If you know ID3 tags well, you'll see that no player today can read all possible formats (Windows Media Player for example is unable to parse many valid MP3 files and ignores many ID3 tag variants or more recent versions)

Thanks for the very helpful explanation. In this and several earlier posts here, you've shared a lot of useful information about how LW works, and I hope that it can be added to the FAQ in some form.

With respect to that, I would be more than happy to volunteer my services: I am an Engish native-speaker who has worked as a (freelance) technical writer for many years. But of course I am not a programmer, and I can't tell how a program works just by looking at source code, so I would need a fair bit of input to be able to help develop the documentation further.

Anyway, let me know if I can be of assistance in any way; it is always said that programmers hate writing the documentation...

Re: Another guess: ID3v2 parsing?
 

Yes, but you see the problem is that this is happening in the background (some 60 secs after Limewire v3.9.11/12 has scanned the Shared folders and established connections). I hear disk activity, it stops and CPU usages jumps up. Of course I have no idea which MP3 file is being read at the moment (if indeed that is what LW is doing). Perhaps you could add this to the information currently displayed very briefly at the bottom of the Search window on startup, but I can imagine you don't want the interface to get too busy.

In any case, I have backed down (temporarily I hope!) to 3.9.10 which doesn't have this problem.

Good idea: Limewire now integrates messages in the Status bar once the GUI construction is complete (they are displayed there instead of on the initial splash screen) and they explain what is being performed once the splash screen is closed and replaced by the constructed window.
There is now the support needed to display file names getting scanned (notably if they are MP3 with ID3v2 scan in progress). Note however that this status bar may become "flashy" if you add a large collection of files, such as when adding or setting a new shared folder.

[Thanks for the earlier info Philippe, and for all your gnutella/LW work too]

Well Sam--I couldn't break 3.9.12 on OS 10.3.3. I had to give after 24 hours running wide open because after 5GB up ands 1 GB down I used up my self-imposed bandwidth for the week! 4.0 is a great improvement and ready to roll as far as I can find--congrats to all once again.

Here are the only things that still seem odd:

--the 'already-downloaded icon' doesn't pick up on tunes that get sent to the shared iTunes folder if they are manually deleted from the unshared dl folder . (Roger--I don't work with iTunes much, so this is likely to be a new user problem. Otherwise, I was impressed by how well LW integrates with iTunes). I guess keeping the Library updated is in the future plans. The recognition of files in the unshared folder does work well--thanks for that.

--the incomplete icon doesn't always sort properly when complete and sorted by Quality (it will when the sort arrow is clicked twice). Too, some search results displayed stars in the Quality column but when selected for download, the 'overwrite?' message is properly displayed and the icon updates to the 'complete' one.

--several times the Monitor showed a duplicate upload (different progress) to the same IP/vendor. Uploading the same file at the same time seemed a waste of bandwidth, so I had to kill one (the lowest) and reset the upload prefs to only allow one slot per person. Too bad--I'd like to allow more slots per person.

--Ethernet transfers are still throttled by the upload bandwidth controls. Would be good if ethernet transfers were exempt.

---I did get one hang (beachball; Activity monitor registered a hang), but LW recovered within 20 seconds. This happened during the early minutes of a download swarming from 92 sources/downloading from 10 hosts. The file downloaded correctly.

So, after abusing LW by selecting >50 files at a time to dl or resume, changing upload prefs on the fly, quickly resuming multiple searches, messing with resuming incompletes from the library, and other nasty habits, I failed to break LW. I ran out of time (and bandwidth!) to try with OS 10.2.6 or Mac OS 8.6--sorry. I grabbed a bunch of stats screenshots before I had to quit

I hope the Opensourcer and Review pages will be updated in time for Tuesday. Too bad Jens and trap_jaw aren't around for a bit to also enjoy the reactions.

Thanks. Best wishes for the release.