Persistant file stats in Library?
 

Hi all,

I would really appreciate it if the Hits & Uploads stats against each file in the Library were maintained, rather than having them reset each time Limewire starts.

Sounds like a simple thing to me although as a programmer I appreciate things are not always as simple as they should be... ;)

Another nice feature would be to list shared files in order of hits or uploads. I'd like to see what my most popular files are.

sim

(Unless this can already be done and I'm just missing something??)

Persisting the information throughout various sessions is definitely something that sounds easier than it really is. Since you're a programmer, you might be able to take a look at it and make something work -- you may not know, but LimeWire is completely open source (that's actually how I started my involvement, by adding the 'time' column to downloads as an open sourcer). Check out www.limewire.org for more information (such as how to access our CVS repository and how to join mailing lists, etc..).

You already can sort the files via hits or uploads just by clicking on the column you'd like to sort. This works best if all your shared files are in the same folder, and doesn't work so well otherwise ...

Thanks.

Thanks for your reply sberlin. I will take a look at the source although I'm not sure if I have enough time from my 'official' duties to actually get in and implement a solution.

I realise that the file lists can be sorted by clicking a column heading but unfortunately I have my files sorted in to individual directories - one per album, so that doesn't work so well.

Cheers,

sim

Hi Sam,
I think it wouldn't be quite as hard to make this information persistant if you were using Kenneth's FileManager patch. I don't know if you had any plans to implement it (it's surely a month's work to make it compatible to the latest codebase and hammer out all the bugs) but since it was serializing all FileDescs it offered easier solutions for saving that kind of information. -
It also fixed some more or less annoying quirks with the library.

I never actually took a close look at Ken's file manager patch -- I was waiting for the 'finished' version to be sent in. What, exactly, was its purpose again? It seems like lots of the things I remember hearing said in some emails are already now implemented, although I could be wrong.

Strange, I don't remember what the main purpose of this patch was either. All I knew was that it fixed several problems:
* When selecting multiple files them in the library and attempting to move them, LimeWire would now actually move the files that were previously selected and not some random files from the source folder.
* You could rename and move files without having to endure the GUI freezes while LimeWire recalculates the hash, - in fact the hash wouldn't have to be recalculated at all.
* you wouldn't loose meta data when moving / renaming files from the library
* you could share / unshare folders more quickly
* metadata and urns would be saved to the same file (sharedfiles.dat) and LimeWire would create a backup copy since it might be corrupted
* when refreshing your library, LimeWire would add files with known urns first and then start calculating hashes of files with unknown urns
* it prevented LimeWire from sending 404s when the Library was being refreshed
* LimeWire would remember alt locs when refreshing the library
* I think it also ordered the folder list alphanumerically and made alternate locations persistant (very useful especially with the improved download mesh that doesn't make it necessary to expire alt-locs anymore)

Some improvements have already been implemented, e.g. the fixes for the upload code that would make LimeWire sending a 404 instead of a 503 reply when receiving an urn request for files that were not available.