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