Why use 1.8?
 

I just downloaded v1.8 from FileFlash. I don't get it. Why on EARTH would I use this version, with the huge advertising banner where the network information used to be, and with the (admittedly, optional, but still...) eZula spyware? >:(

Going back to 1.7...

I do not know, and I hate that the net status is hidden by that awful banner!

Two reasons to use LW 1.8:

1. Metadata. Want to see bitrates or comments about a file? Try choosing "Audio..." from the search window. When you get results, try using the "Change View" button. Also, try going to the library, selecting a file, and choosing "Annotate".

2. Media player. Check out the new library, with a built in playlist. If you want to use a 3rd party player, just choose this option from Tools->Options->Player

As for the status line...as I've explained in other posts, this line was grossly inaccurate. Horizon counts have not been accurate since BearShare implemented pong throttling. We can add SOMETHING there in future releases if people really want.

As for the ads...Greg Bildson and I have explained why we're doing this in the Beta message folder. We're just trying to cover costs and create more open-source code. Personally I think the ads are kind of pretty. :)

the ads are kind of pretty (yeah right!!!!)

if limewire is going to go the ad route, will you have the option of paying for a year's subscription say for $US10 yearly for no banner ads and quick access to technical support as some other web services do? (please no more than $US10 for us non-americans that is about bearable, especially if it means a more reliable service).

Personally, I was happy with the inacurate horizon estimation 'cause when that number was, say, below 300GB my search results were depreciated, so I knew I had to temporarily increase my number of connections.

I like the Audio search field you get when you search by type 'Audio...', but often search results aren't at all what you'd expect. Run a search for Title "iii" (or Album set to "iii") , artist "led zepplin" and you'll find pages of stuff a. not by led zepplin, b. not containing 'iii', and/or c. without any artist/album/title.

For populating these results you are to go to the Library and "Annotate" your files(??). This seems like a bad design idea; I share hundreds of files. I don't want to spend the next month creating this database of information that is elsewise right there in the ID3 tags -- it should automatically extract that info.

Finally, I am happier with xmms than LimeWire for sound playing. I would far prefer LimeWire to default to launching netscape and passing the mp3 off to it, so I can just use the MIME type to trigger xmms.

We'll look into some sort of indicator to replace the defunct horizon stats though I can't promise anything.

LW actually does parse ID3 tags automatically. You can even edit them through the library. All other metadata is stored external to the file.

There is an option to use external media player instead of the built-in MP3 player.

I Agree But More About Annotation...
 

I agree with the comments of limeuser, but I will complete it here.

My opinion is that it is better to have a rough estimation of the amount of hosts and files which are actually connected (if I know that this is only an estimation) than to know nothing about how successful a search request can be in the moment.

About Annotate...: Generally a good (because old) idea. Especially, you can use important characters (such as colons or slashes) which are not allowed in Windows filenames.

But how to fill the database is really fossil. To fill the database completely by extractions from the filename, as limeuser proposes, is fine, but I don't beleave that it is realistic. But it is realistic to support the manual work by an automaton with the filename and optionally a text file as input. The user interface for filling the database as well as the finally stored data is poor.

You don't beleave? Here a simple example:

I offer the 9 Beethoven Symphonies for downloading. I started to fill the database with the files of the 1st symphony, 4 movements and one complete version. The actual filename in my upload directory of the 1st movement is:

Beethoven Symphony No. 1 - 01 -- Leonard Bernstein, Wiener Philharmoniker.mp3

In this filename, the informations Ludwig van, C major op. 61, Adagio molto - Allegro con brio, Conductor are missing because I wanted that the downloaders can see the most important and identifying information at the left side of the name. The other data is a typical information for the database only.

It is available in an extra textfile on my computer, and so I can copy and paste the information with the mouse and CTRL/C, CTRL/V.

Can I really copy it?

In the example above, the annotation should be:

Title: Ludwig van Beethoven: Symphony No. 1 C major op. 61 mvt. 1 Adagio molto - Allegro con brio

Artist: Vienna Philharmonic Orchestra, Conductor: Leonard Bernstein
a.s.o.

I start the annotation interface. Sorry, not START but rather CALL because the form depends on the fullscreen LimeWire window in the background. This window conceals my textfile completely, so I have a to do a lot of actions to put the text parts into my clipboard and then paste it to the annotation form -- it's nearly as much work (using mixed mouse and keyboard actions) as to type the full text afresh :-o

Apart from the fact that the form width is too small (everytime you open this form you must first resize the form window to use the full width of the fields), the stored text is truncated without any warning. If you store your input and, later on at any time, you refresh the library, the remaining text does no more contain the "No. 1 C major....", only the poor "Beethoven" is left over. My impression is that you want to save twenty or thirty bytes of my disc space... :-)

Twice I filled the database with five or six of my shared files, and afterwards I lost the complete information -- unfortunately I could not yet reconstruct which action caused the data loss.

As a first idea I propose the following simple improvements:
1) display the filename in the form window in a way that every part of it can easily be copied into the clipboard whithout changing the window. If too long, split it and use more than one line but in every case show the complete filename.
2) Offer a multiline free text field (vertically scrollable if necessary) visible in every situation -- not to be stored in the database but as a buffer for clipped text.
3) As initial value, keep (or make restorable as long as the fields are virgin) the previously written form contents as new default values (but in this case offer a button to clear the prefilled fields) -- this helps to document complete albums which have a lot of similar text parts.
4) Yet better than 3) would be a function which allows you to browse the database and prefill the fields completely with the data of any other already existing contents of the database with a view to update them manually.
5) A combination of 3) and 4) could be to offer all information of the database but show the latest information uppermost, or allow to select the sort sequence (alphabetical or historical).

Any of these simple proposals could improve the user interface and decreases the effort for filling the database considerably!

Kind regards: Hermann