LimeWire 3.0.0 Beta
 

Well, - since the LimeWire developers obviously haven't announced it yet, I'm going to do that.

Changelog:
* server-side out-of-band replies (reducing the load on ultrapeers once the client-side is implemented, too).
* finally support for themes
* more statistics
* some optmizations
* some bug fixes

http://www3.limewire.com/beta/3.0.0/

BEFORE YOU INSTALL IT, READ THIS:
The bad news is, - somebody seems to have added the wrong version of some library named xerces.jar, - so ... it doesn't work - unless you copy this xerces.jar file into your LimeWire folder and overwrite the old version.

Here's the new version of the xerces.jar file
http://mitglied.lycos.de/mdsgeist/xerces.jar

Size: 1,812,019 bytes

Edit:
You can also get the file in a zip with other xml stuff from apache.org.
http://xml.apache.org/dist/xerces-j/...-bin.1.4.4.zip

EDIT2:
My favourite new feature: LimeWire now completely ignores the upload bandwidth limit...

Thanks--I couldn't get the OSX version to start up (sent in 3 bug reports).
No change in the installer err.txt reports or the installlog.log.

trap_jaw, do you know why 3.0 still reports using java 1.3 on OSX? I'd expected 3.0 would use 1.4.1.

Partial File Sharing? Resume button?

If anything as big as partial file sharing or the resume button had been implemented, I would have mentioned it.

Sometimes I have my doubts that the LimeWire developers are actually using their own software. - I mean you would expect them to notice that the resume button has been completely useless for ages and that it would be fairly trivial to make him actually resume the download, - oh well...

re pfs: I wondered if modesty was a factor, or if someone else wrote the tests.

BTW, thanks for the xerces.jar link--that worked to get 3.0 running, but now only the Windows installer shows on the beta pro page.

I tried your Turner magnet again; no changes noted.

The text beside the buttons for search type is missing, but searches and downloads still work.

LW is maintaining connections to 4 UP's as a leaf. Has this number been changed? Connections seem to be crisper.

Limewire might be the best gnutella client around protocol wise (core), but it lacks consistency for users (gui). One version has a new feature is enabled, the other has it malfunctionning ie "resume". This is disapointing to say the least. While I know developpers have fun improving the protocol and doing network researches that benefit to an open source protocol, they are losing users by not showing support. They might not be in difficulty financially, but hiring a dedicated programmer for user "confort" would pay many times his salary easily. And more users would help the current ones in search results. Another thing is the ****ing installer that "sucks" very much, it might be normal for windows users, but a stand alone application would be much better, especially when Jeans-Uwe (an open soure LW dev, does it for os X). Also the about LW should have for a long time included the history of changes since the last version, many people would appreciate, including me.

Pour résumer, please hire someone dedicated with users in his mind LW!
(Yes I know there is also ACQX for OSx but you can't specify the search type and the developper is making money of open source software, instead of helping by hacking and adding features to LW. He's also very afraid of bad reactions of its users, I told him many times to lower the number of ultrappers connection while being a leaf, but he's scared....and hurting the network).

Sam Berlin is now going to implement PFS, he has already contacted me but my patch is not really compatible to the cvs and my approach may have been a little too simplistic too be of much help, I fear. In addition I don't have time for LimeWire at the moment.

My Turner magnet will not work unless my LimeWire is running. It's not running very often these days because there are networks with more content than Gnutella. I use Gnutella occasionally for music, but for movies, etc. eDonkey is my network of choice at the moment. (With mldonkey I can even access eDonkey and Fasttrack at the same time). For music, Gnutella is a lot faster than Fasttrack (not to mention eDonkey) but the other networks have much more content.

Are you sure the text next to the radio-buttons for the search type is missing? Or is it just not visible because it has the same color as the background? Can you try another theme (if that is possible on OSX)?

The ultrapeers return even less results now (distributing the load reducing traffic peaks for ultrapeers when a leaf issues a search). The consequence is that leafs have to maintain more ultrapeer connections to get the same number of results.

I agree with et voilà that some more communication with the users (like BearShare does) would be nice. But as a developer you really have to define your priorities. A couple of months ago it was most important to improve the state of the network before concentrating on the GUI. And the network core is not really something that you can discuss with the users.

As for the installer: It's a java installer and as far as I know the only one that is more or less decent. You can't expect LimeWire to write or license installers for every platform they are supporting when all the installer really has to do is copy some files into a folder. For windows there is also a native installer, by the way.

Any idea when 3.0.0 will release normally? I feel a tad suspicious about installing beta software when LW is so quirky some of the time. Can you sooth my fears, or tell me that 3.0.0 is coming out soon?

3.0.0 won't be released 'normally' because LimeWire increments the version number when they create a new installer.

My guess is that a stable version will be released at the end of the next week.

I can wait until then. Thank you.

+1 that. Limewire seems to grossly underestimate the power of a nice and easy to read GUI. Human factors are essential for the succes of a product.

• the progress bars are a joke and source of tons of misunderstandings. when are we finally going to have progress bars that show which chunk of a file is being downloaded (like in BearShare and Shareaza)?
• The dropped I/O and Uploads colums are also a constant source of misunderstanding, with users thinking that 90% dropped means Limewire is not working propperly and stuff like that

the new themes are a good idea, but frankly, the way they have been implemented leaves much to be desired. we now have three ugly interfaces to choose from instead of one.

As much as I hate the arrogant snobbish missionary behaviour of their zealot-users, take a look at Shareaza for a second and you will realize that limewire looks like a C64 in comparision. the soviet union robotron-trabant dusty kinda charm does not appeal to the masses.

[edit] sorry... i din't know i was that angry, but i think the issue must have been bugging me for longer than i thought... no offense to anybody

wait a minute... i have only incoming hosts. shouldn't i have at least one outgoing?

Also: Almost zero dropped I/O. Used to be much more w/ 2.9.11

1) There are some patches for the progress bars to show which chunks of the file have been downloaded, - but since LimeWire should download in the correct order beginning at byte 0 ending at the last byte, (at least recent versions do so), seeing which chunks have been downloaded should not be interesting at all.

2) The dropped IO column is hidden by default, like the rest of the connections tab so it won't lead to any misunderstandings for most of the users.

3) Java Swing does not offer you much flexibility as far as the look-and-feel is concerned. It's probably not worth the effort to try and add some real skins like Shareaza has them.

All of those GUI issues should have VERY low priority compared to new features like push-proxy, DHT or Partial-Filesharing. I wouldn't mind if LimeWire had only a command-line interface if it had all those others features instead.

Why should you have an outgoing connection if you are an ultrapeer? You might have one when you connect for the first time but the longer you stay connected, the more likely you are to have only incoming connections.

The number of dropped IO messages are lower because of pong caching. LimeWire does not sent as many pongs as it used to, so naturally less of them are dropped by flow control.

trap, I agree with what you're saying about the technical aspects of LW, but the first priority is the user. B/c w/o the user, gnutella and LW are nothing. Say if PC people go to Kazaa instead of LW, b/c they don't like the GUI, that's one less person uploading and sharing and contributing to the network. The network works on the basis of its wide user base, and at the very least, LW has to maintain its current user base, and ideally increase it. While other gnutella clients improve their GUI, and seemingly, to the casual user, thus drastically increase the effectiveness of the software, LW loses out if they don't at least keep pace. And this is much more applicable to PC users, who have such a wide variety of choices. If the people want eye candy, and it takes a little eye candy to get these people on LW and share, I'd want a couple more thousand users sharing than a fixed resume button.

trap_jaw,

thanks for the info regarding the incoming.

improving gui vs improving core: i completely understand your points. you represent the programmer's/power-user's point of view.

otto normalverbraucher perceives things differently. the look and feel has lots to do with subjective perception of performance, coolness and how new and advanced something is.

i'm caught somewhere in between these two but i realize there needs to be a balance, and currently, there's an exclusive emphasis on making the core better, and that's bad.

the fact that these columns are hidden (because they display misleading info?) doesn't solve the problem. the solution would be some clearly readable stats regarding requested/sucessful/failed uploads and dropped/missing messages. it is reassuring to know that your uploads actually arrive somewere.

regarding the progress bars: if a host downloads from 4 other hosts, it can't possibly start at 0% with all four of them. and what about other vendors? do they also download starting at 0?

looking at the questions in the forum, it seems that at least some of them are misunderstandings because of the GUI being unclear.

i'm sorry i was so rantsy earlier. it's the old story of industrial designers and engineers. they tend to have very different ideas of what the probem is.

I noticed Sam is also working on the related (?) progress bars. Sorry to hear you have less interest in LW. You really should treat yourself and benefit so many of us by getting a Mac! Maybe we can respark your interest in LW. Let's start a fund to make up the difference you think it would cost you to switch! I'll throw in $CDN 20 for starts--anyone else want in on the fun of switching TJ? :D

OK. Still, Why should these networks be so much better at longer files? Packets are packets, or is Java the main factor here? The RIAA scares don't seem to have cut down on the gnutella users, but perhaps the kinds of files being shared has been affected. Is gnutella's "music speed" related to flooding the network with finding multiple connections? Just musing.

I couldn't reproduce the missing text without reinstalling, and I'd trashed the OSX installer--you're probable right that it was the background colours because the text is white on a gradient blue in OSX. The text showed in other themes offered (Windows style--noticed the striping is much more visible). However, font size is very different between the "OSx" [sic] default and the other two options (black and default), and wouldn't revert to the larger OSX font in Advanced Stats.

This may have been responsible for a freeze. I was in UP mode on a direct connection, and after the freeze I haven't been able to run as an UP since.

Leaf mode is quite stable though; searches work as good or better; downloads still require kill/redownload (no repeat required) babysitting; but uploads are still choking after the initial burst. I was puzzled by one "urn get" upload: Does this mean the 2.9.11 host was uploading based on an urn search? The new stats sure give more to think about, and look to be very useful for figuring out why I see so little upload success whether connected directly or behind a gateway.

Re the gui/core priorities, I respect the need to make the core the priority. It does get irritating to read the occasional Acq user sneering at LW when 75% of Acq is LW and opensource work. Why don't the devs use more of Dave's open gui code, installer techniques, iLife integration and java implementation? Two (three?) months ago I though we'd see the benefits of a developer working on an OSX box in "two weeks" but I was wrong. Since there are some core problems that still seem to show up in the OSX (and XP?) forums, I guess the core work must continue, but do wish the devs would at least say they've contacted Apple and tried to find out how to integrate java, LW and OSX--esp OSX LAN's, packet management and firewalls. As you said trap_jaw, "the network core is not really something that you can discuss with the users".

Cheers

ps et voilà--do you host a GWeb cache? Wondered if that could be part of your UP ease of connection.

à Stief, non je n'oserais pas tenir une gwebcache avec mon adresse IP dynamique. Vive Anaheim!

pas de ducks--vive les canadiens. Moi, je suis de Saskatchewan, alors je n'aime pas le chef de Oakland. C'est presque Anaheim! Merci pour l'information de la GWeb. Just a thought. LW just crashed on me just before posting this--it was trying to be an UP. It's up to ~30 connections in ~10 mins, so I'll see. I don't have advanced stats checked this time.

I suggest you go reading user complaints in these forums. How many posings that go like "Can't download!", "Can't search!" or "Always awaiting sources" would you find? And how many postings saying "Help! LimeWire is too ugly" are you seeing?
In addition, as I said before, changing the look-and-feel of java swing applications is not exactly very easy. There were some attempts to do that, but they made LimeWire rather slow and unresponsive.

These columns are hidden because their information is not useful for the average user. For the expert, the info is not misleading at all. Information about successful/failed uploads etc should be in the advanced statistics (at least they are in the cvs version) but those stats are not very useful for the average user, either.

The four downloads start at 0, 100K, 200K and 300K. If you have N downloaders for one file, they will always try to download the first N chunks that have not yet been written.
I really don't know about all the other vendors but I assume most vendors do the same, to be able to preview files as good as possible.

Then the solution is better documentation.

I've not lost interest in LimeWire, I'm just working on a few other projects that require a lot of attention.

Other networks are better, mainly because users with big files are using eDonkey more often than Gnutella. It's not necessarily a question of better technology (not long ago most of the big movie sharers were using IRC). However in case of Gnutella it is also a question of technology. Without partial file-sharing big files are not distributed quickly enough so you have to wait much longer before the files are available and without push proxy firewalled hosts cannot take part in the download mesh.

The urn is sent by modern clients in the QueryHit, so you will know the urn of a file without specifically searching by urn. In addition if you get alternate locations from the download mesh all you usually know is the urn of the file you want (and not how some user may have named the file).

The gui code and the installer only works on OSX and LimeWire would have to create different versions for different OSs. That's more work for the developers. The java stuff should be more or less the same in Acquisition and LimeWire.

Wow--thanks for all the info. I'll be greedy and try and prolong this great class! This is better than finding a host that downloads great stuff at 80 KB/s! Sorry for being a leech--hope I can find a way to pay it forward or back. Any chance I can help you with a Shakespeare or Romantic Poetry class?

Acq has been using Java 1.4 since it was still only available in the Developer's preview version. Should using 1.3 or 1.4 make much difference to the gnutella experience?

Is the URN (Uniform Resource Name?) generated/linked to the sha1 hash (how can I see/know a file's URN?). I thought I read that searches by hash had been blocked/stopped.

I noticed two new columns in the connections pane: compression I/O and QRP %. I like the compression stats (saves having to turn on advanced stats to view), but noted of the hosts reporting, most show 0/40. I have both options for compression enabled, so I guess 0 means I'm receiving 0% of that host's message as compressed, and 40 means I'm compressing 40% of the messages I send out. Did I get this backwards/sideways?

I don't know how to read the infrequent data in the QRP% column (Query Returned P?). Any suggestions?

Cheers, and thanks again. LW has sure helped gnutella be better since those dismal times in November-January, even if I did log three beta crashes today!

Yes. I see users saying they can't connect but in reality, limewire is

-either connecting but doesn't find a good host before the users give up and quits
-or not connected at all because user unchecked the 'connect at startup' checkbox

these are issues of users not understanding what's going on. limewire is not transparent.

or the people looking at the dropped i/o column and assuming that something is wrong since 90% incoming is dropped.

or the people looking at the transfer column wondering what the number before and after the / means, with no way of finding it out.

or the people wondering whether their uploads fail because they always only go to around 4% and then stop.

These posts have been there, I assume you've seem similar ones yourself. These are all interface issues.

The fact that a column is hidden by default does not mean users are not going to see it. And, IMO, users are entitled to know whether their uploads are succesful or not, actually, i think it's crucial. It's weird to leave your PC on 24/7 and giving your bandwidth without knowing what's going on.

Its sometimes easily solvable problems like naming a column 'attempted/succeeded uploads' instead of 'uploads' (I know, there's a space issue). Or removing a resume button, for that matter. There has been confusion about that in the forum, too.

It seems that programmers tend to have a hard time imagining that users see things with different eyes, because they lack the knowledge of underlying processes that make everything seem 'simple' and 'logical' to people who actually write software. That's why you use MLdonkey and people like me don't. Imagine what cars would look like if they were designed by engineers (I am talking about the styling, interior, positioning of the instruments, levers, knobs etc., not the mechanics). It would be a desaster in the market, despite possible superior technology. That's why voila's idea was good to get somebody to specifically deal with user experience. Preferrably somebody who is not tainted by an excessively deep understanding of the underlying technology.

I have been using Shareaza for a while (before it turned into a cult): Limewire (2.9.x) downloaded in chunks that are spread all across the file, so do other servents. I know that because shareaza's progress bar's reflect where the chunks you're uploading are located within the file.

Agreed. This would also save us a lot of work in the forum.

:-)

Yes it should - and LimeWire 3.0.0 *should* be using Java 1.4 on OSX. I thought the problems with Java 1.4 had been sorted out weeks ago.

The URN looks like this: "urn:<type>:<unique identifyer>" in the case of LimeWire and most other gnutella clients a string that looks like this is used: "urn:sha1:<sha1-hash>" -
Shareaza on the other hand uses "<urn:bitprint:<sha-1 hash>.<tigertree root hash>".

1) The compression stats show the bandwidth savings of incoming and outgoing compressions. Since older ultrapeers (2.9.9-2.9.11) have disabled outgoing compression by default, you will only see bandwidth savings in one direction.

2) The QRT (Query Route Table) is always empty if you are a leaf so "QRP %" shows 0. Only ultrapeers keep a QRT for the connections because they are shielding clients from traffic. - The higher the percentage, the more searches are forwarded to the connections (actually it's a little more complicated than that).
The QRT is sometimes a good way to identify freeloaders - although not everyone who has a very low "QRP %" value isn't sharing anything at all (except if that is 0) - the files he is sharing obviously just contain very few different keywords.

That's what a beta is all about. - (I suspect there is something else wrong with the installer because some files are not copied correctly on my system and LimeWire throws exceptions about some missing files all the time - since the cvs version works quite well I am confident LimeWire will sort this out).

* If LimeWire takes more than a few seconds to connect it usually doesn't connect at all. I have my doubts that users are so impatient to close LimeWire after a couple of seconds before closing LimeWire because it hasn't connected
* In the options it states clearly what this button is used for. If the user doesn't understand it, he obviously picked the wrong language when installing. And I think that most users who uncheck that checkbox in the options are bright enough to find the connect button.

Yes, unless they go to the www.limewire.com homepage where it clearly says in the help section that it's normal for the incoming value to be high.

Oh yes, there is a way of finding out. - Ask somebody who knows.

That's not an interface issue at all. It's a documentation issue. If this was an issue, the only solution was not to display that kind of information, because the LimeWire client for example has no way of knowing if an upload was successful if it stops after 4%.
I am not arguing that there are no interface issues at all (the resume button is one big example for such an issue) but what you list here are problems with understanding information Joe User would just care for - I mean I don't even care for it most of the time.
Plus, there is not much room in the Interface to write explanations for everything. - Most of it is explained on the www.limewire.com website, however. And for the rest you come here to ask people who know.

You are not going to compare MLdonkey to LimeWire, are you? I mean MLdonkey is a really good example for a bad interface. Even the command-line interface is worse than average.

2.9.11 downloads chunks as I described it. The uploading client, btw., has no way of knowing which chunks have already been downloaded by the client and leaving out a few chunks from one uploader is fairly normal, if the downloader is swarming.

Regarding Java 1.4 on os x and LW, The java 1.4 version of 2.9.11 works much better than the official 1.3.1 version LW compiles. Startup is faster and you don't have to hide LW to save ressources as it cosumes 0-10% in front like version 2.5.5, before LW began using too much processor because of a gui incompatibility with os x java 1.3.1 implementation. I hope 3.0 is for java 1.4, but the beta I tried yesterday wasn't :(, good news is that using a theme (a new feature), reduces gui cpu usage problems.

Small bug and suggestion
 

There was 1 minor bug I noticed when running limewire. I have Limewire Pro 3.0.0 on XP with Java 1.4.2. When I did a search and clicked d/l the bottom bar will no longer pop up to show the progress though I can drag it up. Also someone should tell the Lime dev the red theme looks nice but when you have the diff colored bars enabled one color is yellow on black(thats ok) and the other is yellow on white(blinding and do no sift well together) Well those were my meaningless comments now you guys can go back to discussing something I really no very little about. Later

Yep, noticed that too then read on the cvs mailing lists that sam already fixed it for the next release.
http://gui.limewire.org/servlets/Bro...vs&paged=false
http://gui.limewire.org/servlets/Bro...ev&paged=false

Hmmm--so using the Windows-like theme reduces cpu usage on OSX. High price to pay!

LimeWire build for OS X users
 

I do regularly build LimeWire for OS X and I do have some fixes in the code that are OS X specific and not yet accepted by the LimeWire developers. This version runs using Java 1.4 (it does not use any installer, just drag the app to your HD), reduces CPU load even if running with the Aqua look and feel and fixes some crashes relating to the use of many open files. You can find it at:

http://baghira.han.de/~jum/

Merci beaucoup Jens-Uwe. I didn't want to reveal your address because of traffic concern I would have caused you. I've used your builds of LW since late 2002, and they are great, especially since the java 1.4 builds work well.

Tx again!

trap_jaw,

I can only say that most of these issues have come up recently (last 2 weeks) in the support forum. Personally, I think a large documentation, esp. for a simple app is a sign of a badly designed app (not techically, but from a human factors p.o.v), but I realize that this is a hard point to argue than I thought.

If you research a bit about human factors, you will realize that the notion that users read manuals is one of the hardest to kill misconceptions of programmers and engineers. They don't. This issue comes up every single time a company employs human factors people to check their software. They find a cumbersome interface issue, and the engineer will reply that, well, it's all documented in the manual. It's fan users like the people posting in this thread that maybe bother maybe read the manuals. Not the average users. Particularly if they can switch to other apps, or bother the forum for support.

There are a few users every day who keep asking the same questions in the forums. It's not like there is somebody with good advice there 24/7. Some of these users give up and use other vendor's applications. If we could take care of some of these issues with interface improvements, that would make everybody's life a lot easier.

Let me give one example: When users start up limewire, they have no indication whatsoever that limewire is doing anything. If limewire doesn't connect, they have a red dot and a greyed dot as sole indicators. No text. They have to go to the connections tab to figure out in the first place whether limewire is at least attempting to find hosts. Why can't limewire clearly communicate it's connection status on the tab that shows when you open the program (search). Like:

a) can't reach the internet (with suggestions to check router/firewalls/etc)
b) connecting/waiting for good hosts

and once the light goes green

c) connected behind router/firewall (suggestion to forward port)
d) connected and everything running well

I know you can find these things out by looking elsewhere if you know what you're doing but a novice user maybe doesn't think of checking the 'connections' tab. If I remember correctly, the 'connections' tab is even hidden by default. Is that again information that's irrelevant to users?

Thanks jum--I've been reading about your work on LW.
Should I completely uninstall my current LW, including the plist, LW folder, and .com.zerog.registry.xml in prefs before using your build to avoid conficts?

à stief: non ça marche tout seul, it's idiotproof!

It should not be necessary if you double click the right app. The only quirk I have encountered occasionally was a corrupted limewire.props file. If you have problems you can move the prefs folder away and try again.

Merci, danke: This has been the best thread yet. Good questions, good information, and now! A solution too.

I would like to second that users do not read manuals. Just yesterday, someone posted saying, something to the effect, "I installed LW, now what?". If your GUI is so unintuitive that a user can't figure out what to do after installation, than something's wrong. Obviously, on the forum, we do get a skewed perception. I mean, people who use the program correctly don't come and tell us how good it is, only the people with problems. Regarding the chunking thing. That bothers me, not knowing if a UL is successful. It bothers me so much, I just turned on the auto clear inactice option, so now I don't see whenever anything may or may not be completed.

Also, a very useful option would be to have two settings profiles. One for UP and one for leaf. Mainly because of this: when I'm UP, a great deal of my UL and DL bandwith is taken, and I can't support as many ULs as when I'm leaf. So if I have my UL slot options set for when I'm a leaf, as UP, I get more ULs than I can handle. And LW seems to ignore or decides based on variables I don't understand how to open up a slot above your minimum slots but below your max, because as UP, I'll open up my max slot setting on leaf, and then a bunch of people get very slow, unreliable DLs. So, if two settings profiles were implemented, i.e., so and so many UL slots on leaf and so and so many slots on UP, it would be very very conveinant.

[edited for grammar]

osu--I think everyone agrees with you: as et voilà said at the beginning, LW should afford to pay someone to ensure that something like the Human Interface Guidelines (isn't this the term Apple uses?) are followed before a version gets out of beta mode. LW and gnutella have a long way to go before they are up to "mission critical" standards. Who should pay for this?

Should LW pay someone to give real answers via Pro Support and develop dynamic documentation? If Pro support is priced on a user-pay schedule, it'd be a lot more than 10 bucks. I've never had an answer by "Zenzele Bell", though Greg and Adam have promptly replied when asked a question. These forums are the place where non-coders vent and even find solutions. This thread is the best example. All of us here have freely helped others based on help freely given from each other. That's the nature of the open-source community as far as I know. It's embarassing to give poor answers and frustrating because we don't know better, but we do what we can. The developers are frustrated at their level too--and they face much more powerful antagonists.

As far as I know, the code is dynamic, and so documentation can't keep up. Hell--the dev don't even have time for a changelog!

What do you suggest to make the "now what?" less of a problem? That is, how could the GUI be more intuitive to say "search, choose a result and click download"?

Other problems, like "what are the numbers before & after the '/' in the Uploads column of a library" are just simply not something that can be concisely explained in a simple GUI. LimeWire is a very complex program, and has all sorts of statistics that can be displayed -- those that are useful for everyday usage I personally think are very intuitive already (but I'm of course biased).

Fancy features like fragmented progress bar (displaying chunks) are nice for people who know that they're downloading/uploading files in fragments -- but the vast majority of people don't know and don't care about that, they just want to know how far along they are in completing their download.

The ultimate goal, of course, is to have a happy medium of an interface between power-users and casual-users... but too often the happy medium in between turns out to be the worst of both worlds.

Regarding seperate profiles for ultrapeers/leaves... with compression turned on, the upstream bandwidth difference between an Ultrapeer and a leaf is around 3-6KB/s, but no more than 6KB/s. It's basically like having one permanent extra upload going. One of LimeWire's goals is to reduce the requirements of all ultrapeers by having more of them (and having optimizations with regards to message exchange). This lets takes more participation, but the burden on any single machine is much much lower.

Sam I think we all congradulate you on the ultrapeer level. This is not what we meant. I'll do some suggestions for you relying on the code of the gui:

1)resume button doesn't work, it should since a download often stop, even if the host is still on Gnet ex; I have to clear download, then click download again in seach results wich is a pain. (for rare files you can't do another search to find more stuff ie French stuff)

2)the "could not download, awaiting sources" sucks a lot, it should say "new specific search is necessary to continue download"

3)the upload tab is occupied in majority with place to see searches coming... not very useful, it could be an option, and it confuses the casual user.

4)when starting, there is a dialog for upgrading to pro, the problem is that for foreign languages as French you don't see the buttons to click ok, you have to press escape, and newbies, especially mac users are utterly lost.

5)there shouldn't be a connection window by default (is it?) Newbies don't use it, and while being at connections, please hardcode the leaf connections to Limewire engine clients only. (gnucleus based suck).

6)please use unicode or à la bearshare change letters ie é to e instead of /e for dealing with other languages, search results are suffering a lot from this, for exemple I have to search okoum instead of okoumé to get results...

7)please update a FAQ and post it sticky on all Lw forums, to help the majority of newbies

8)the look could be better, a way to get ideas is to use other P2P software as Shareaza (beautiful gui for windows), bearshare, emule and even kazaa, keep in mind that EVERYONE is used to the way kazaa works, convergence can be good. Remind to try other programs, they often have good ideas gui wise.

I'm sure others can point you to lacks in the LW gui, and to them post them in this thread!

Merci

Here's a suggestion for a NAT checking utility developed by displaced for Acquisition. LW should have such a utility too, because it checks to see if a user is properly configured to connect to gnutella.
I don't if this bookmark of mine will work here for others:
http://www.sciforums.com/f72/s/showt...threadid=20514

If not, maybe someone who understands Applescript could look at this: http://homepage.ntlworld.com/chris.p...ecknat.app.sit

This should not be necessary any longer with LimeWire 3. It has got a patch in that will do this automatically if the force IP option is turned on. One can debate whether this option should be turned on by default.

I really don't know that much applescript, just enough to like, read a bit, and make backup scripts and stuff, but I don't *think* (emphasis on think) that this would be hard to port to LW. However, looking at the comments in it, whoever made it recognized that it wouldn't work whenever someone used a web proxy, some of it won't work. And it also relies a bit on the public IP address displayed from some website being correcet, which as I mentioned, would be fooled by a web proxy. That's really all I can tell. As I said, don't rely on me, if applescript were a real language, I would know how to say "where's the bathroom" and "hello", but from what I grasp, it looks like it wouldn't be too hard to configure it for LW.

Interesting--thanks for the replies. Yet this might be just the sort of situation osu_uma is talking about: letting the user (and whomever is trying to help) know that all is OK or not. Didn't the LW homepage once have such a link that checked the user's ability to function on gnutella? It would sure help eliminate some of the doubt and uncertainty.

@jum--thanks again. Having a version of 3 trusted by an OSX coder really helps me eliminate setup/platform problems. I had some notes on the differences between LW and LWj, but this thread is going in a different direction. If you don't mind, I'll just email them.

You can email it or discuss it here - either way should be fine.

just some notes on using LWj3--

LWj is stable--it connected as an UP while behind the gateway without crashing. After a few minutes the connections were all lost (this usually results in a crash for me; NAT software related), so I waited a few minutes and quit. Rerouted the 1 Mbit/s cable modem to connect directly (no firewall on) and restarted. OS 10.2.6; ibook G3 700 384 RAM 11GB free sharing 158 files 2GB.

After restarting (prefs set to not connect automatically) and curiously--while disconnected, noted CPU was just as high as when connected. (50-70%). I had no searches going, so what's using all the CPU? Uploads trying to connect? btw--CPU usage as a leaf shows~ 25% open or hidden.

Took this as a chance to see if I could get et voilà's reported uploads at a steady 7k--mine usually show a steady 0k. I was watching the 3-5 uploads which started very quickly to see if they'd be steadier. They weren't: same initial burst of ~30KB/s (the initial burst doesn't show in the average reported on the Monitor pane, only in the stats) and then nothing--the uploads usually end up as "interrupted." Why should the uploads stutter? Something is breaking the connection, right? If this is not LW related, then I need to get my cablemodem replaced. (LW is sure good for testing equipment limits! )

tried trap_jaw's magnet http://www.gnutellaforums.com/showth...threadid=19732 when disconnected---didn't show in the downloads pane, so chose connect, but then LWj wouldn't hide (kept coming to the front) and wouldn't allow any other window to be foremost. Had to quit. This happened when connected directly or behind the NAT.

Console entries are a bit different. Under the previous LW3, console would report
/Applications/LimeWire/LimeWire.app/Contents/MacOS/LimeWire: kCGErrorFailure : CGTranslateCTM is obsolete; use CGContextTranslateCTM instead
The similar message in LWj3 is much more specific:
/Applications/LimeWire/LimeWire.app/Contents/MacOS/LimeWire: kCGErrorFailure : *** Parser error line 1, character position 52

Is this related to my setup compatibility issue or do other OSX users see this too?

Here's one I've never seen before:
2003-06-08 13:22:09.154 LimeWire[942] Warning: Font LucidaSans-TypewriterBold claims fixed-pitch with 0 max advance!

So, just some notes on the little I've seen so far. Thanks again for making the CVS build available. I owe you and others--can I send you a drink?

Cheers--stief

sberlin:

To make the "now what" less of a problem, a few suggestions are in order. First, fix the closing the pro box on foreign language versions, that'll weed out a whole list of problems.

After that, maybe pop up a box that says something like "Are you new? If so, click here to learn how to get started.". Link to an html page. Get someone to write a short, updated explanation of how LW works. That would solve SOOOO many problems. Get someone to explain each basic statistic, problems, and all the associated messages you get when a download fails, etc., etc. It would take a developer an hour to write something like that, and I can't imagine it would be hard to write the code for the pop up.

Also, change the messages to make them more user friendly. Someone already posted above to do things like change the awaiting sources method to "Can't connect for download, try searching again". If you can include real SOLUTIONS to problems when they occur, than the user won't bother with support, and the user will be immediately happy, and not be frustrated.

Your whole support philosophy shouldn't be to have threads and threads of lists of solutions to problems. It should be that the program, Limewire, will have the solutions built into it. Think about how the user feels. He/she/it(hey, it could happen) feels that their problem is common, and easily fixed. And if the problem is fixed, than the user is happy immediately, and begins using the program right away. For instance, if LW remains unconnected for more than two or three minutes, a popup could come and says "Having trouble connectigs? Click here for a list of common connection problems and their solutions." Link to html page. List of problems and solutions. Think about how much more convienant it all seems to the user. It's a whole different philosophy. It saves the support forums for major, complex problems. It saves the developers from having to address these issues, and it saves you guys from having to hire customer support people.

I do not know what is crashing in that case (OS X, LimeWire.app, your router?), but LimeWire with Force IP enabled is supposed to survive these routing changes.

Quote:

After restarting (prefs set to not connect automatically) and curiously--while disconnected, noted CPU was just as high as when connected. (50-70%). I had no searches going, so what's using all the CPU? Uploads trying to connect? btw--CPU usage as a leaf shows~ 25% open or hidden.

Upon startup LimeWire normally does eat CPU for rescanning the library. The CPU should return to normal after the counting stops in the lower left corner.

Quote:

Took this as a chance to see if I could get et voilà's reported uploads at a steady 7k--mine usually show a steady 0k. I was watching the 3-5 uploads which started very quickly to see if they'd be steadier. They weren't: same initial burst of ~30KB/s (the initial burst doesn't show in the average reported on the Monitor pane, only in the stats) and then nothing--the uploads usually end up as "interrupted." Why should the uploads stutter? Something is breaking the connection, right? If this is not LW related, then I need to get my cablemodem replaced. (LW is sure good for testing equipment limits! )

It is definitely not supposed to stutter, and does not for example on my Mac. I have one additional idea what might induce stutter in the display: if the destination node is much slower than your connection it could be possible that your LimeWire process is sending the data quickly out to the network and the routers on the way to the destination buffer the data. As the destination node is slow it does slowly drain the routers buffers. After that your LimeWire again sends a big chunk and so on.

As far as I understand the situation TCP is supposed to fix this by adapting the window size and send fewer data. But only a network sniffer trace could reveal what is happening here and who is the culprit.

Quote:

tried trap_jaw's magnet http://www.gnutellaforums.com/showth...threadid=19732 when disconnected---didn't show in the downloads pane, so chose connect, but then LWj wouldn't hide (kept coming to the front) and wouldn't allow any other window to be foremost. Had to quit. This happened when connected directly or behind the NAT.

This is a rather unfortunate problem. The Apple Java 1.4 implementation does not support AppleEvents from Java any more as the 1.3 implementation did (the JDirect subsystem is no longer available). I have no idea yet how to do AppleEvents from Java 1.4, so if anybody has any enlighting ideas I am all ears.

Quote:

Console entries are a bit different. Under the previous LW3, console would report /Applications/LimeWire/LimeWire.app/Contents/MacOS/LimeWire: kCGErrorFailure : CGTranslateCTM is obsolete; use CGContextTranslateCTM instead The similar message in LWj3 is much more specific: /Applications/LimeWire/LimeWire.app/Contents/MacOS/LimeWire: kCGErrorFailure : *** Parser error line 1, character position 52 Is this related to my setup compatibility issue or do other OSX users see this too? Here's one I've never seen before: 2003-06-08 13:22:09.154 LimeWire[942] Warning: Font LucidaSans-TypewriterBold claims fixed-pitch with 0 max advance! So, just some notes on the little I've seen so far. Thanks again for making the CVS build available. I owe you and others--can I send you a drink? Cheers--stief

The console differences are due to the fact that all of the Java engine is different in 1.4 than it was with 1.3. I do not see these on my Mac, so I what suspect that these are dependent upon installed video card and fonts.

Do not send a drink to me - just support your local neighbourhood instead. :)

voila:

2) fully agree with your suggestion regarding 'awaiting new sources'. Users should be told that they can manually re-search.

on the same issue: what does limewire do if it's waiting in more than one queue? it doesn't seem to allow to see the hosts you're trying to download from, with individual queue position. i always found it reassuring to know that i was queued with more than one host.

5) while I personally like the connections window I see your point. If it disappears, we even more ned a status bar that communicates whether
-limewire is attempting to connect
-failed (suggestions howto fix or link to faq)
-is connected
-is connected behind firewall (suggestionshow to improve, link to faq)

otherwise we have nothing but the red dot.

7) the faq. it doesn't have a 'last updated' and i don't think it reflects issues of newer versions like no more automated requeries. Who's in charge of that faq and does he/she update it regularly?

Blackbird:

the interactive introduction and help system you suggested is a great idea. it would take a lot of redundant questions off the forum.

Why not add a help button to each window, options window, etc, that leads to a specific help page, either online or file? A lot easier than wading through the FAQ and also more likely users find what theyre looking for.

osu_ama

That's another great idea. The developers should really begin implementing or at least seriously considering such an idea.

Thanks to Roger Kapsi the magnet URL stuff does work again. Also the 3.0.1 version contains more fixes regarding long run stability, I hope that the unexpected quits are now finally a thing of the past.

thanks jum (& Roger)--the magnet worked to get as far as queued (once I placed the LWj3 alone on the desktop--MSIE couldn't find it otherwise).

Replaced the LANCity modem today and still see the upload stutter. The ISP tech thought the uploads were odd but we couldn't find any buffering between my machine and the ISP's servers (usual speeds are 100-110 KB/s). I'll have to try to find how to do a "network sniffer trace" (google points me to PC apps). Thanks for that tip--I'd never considered a "too fast" possibility. He also recommended trying the T1 setting and reducing the upload limit to 100 KB/s (800 Kb) in the LWj prefs. Doesn't seem to make much difference yet.

the LimeWire[578] Warning: Font LucidaSans-TypewriterBold claims fixed-pitch with 0 max advance! is triggered by choosing "About Limewire," and that font is not installed on my system (stock--did an erase and install of the OSX partition 2 weeks ago). There are similar fonts in the java frameworks installations (and a few from MS Office X). Perhaps the DP of java installs it?

LWj3.0.1 is stable so far. I've disabled UP until I figure out the router losing all connections and the UL stutter. I've tried a few traceroutes on uploaders but hit a proxy on the way. I need to do more yet.

Cheers all--hope the help links can work.