Add some time & volume statistics info

It will be nice is we had some statistics info such as:

*Global - Total # of downloads (and volume) program running duration, starting times, avarage speed, total wait time

*Per bundle-download - added-on/started-on /completed times columns , elapsed time, wait time, volume, average speed

*Per part - same as above


Thanks

edit:
I would like to not see the same "finished " time for all parts, but the actual real time it was finished...
http://img32.imageshack.us/i/57663269.png/

Nice proposal.

I like statistics, because with statistics you can prove anything.

right, it can also assist in debugging. Or may be there is no need for such info when you have a perfect program like JD ...

No, seriously, managing downloads can only be conducted by measuring the downloading process. Without measuring performance you can't manage.

All the discussions about top speeds and throughput are useless without a correct measuring system that computes the true downloading performance.

yes. I'm totally with you!

yes, even if it was only in the log file, i would love to have some completed downloads info:

filename_xxxxx.rar, rapidshare, @level(3) #2, start time, end time, file size, download speed in bytes/s.

something like that. or maybe an option to put that info in the jdfolder info addon so it saves as a txt file with each download...

Good idea. Put that text file in XML format and everyone can do with the data what he/she wants.

We can load it in a data cube and slice and dice the data.

in addition to regular textual log, and on-screen data, please... and since no admin is responding, and marking this [in progress], I guess we'll have to implement it ourselves...

Yes you can, I'm sure. With the help of the event manager, maybe...

I'm sure the devs are observing this thread, but they are thinking - deeply. I can see the smoke coming out of their ears...

wait until they attend to my RSS auto-downloader thread... the smoke will be red, I'm sure..
http://board.jdownloader.org/showthread.php?t=6740

You are welcome to respond there and "promote" it...

minor glitch in 0.8:
http://img406.imageshack.us/i/90388311.png/
Time-stamps in case of one part - should be the same for the package and the part... (I should probably post it in the bug section...)

would be nice to have such infos

[Jiaz]

Originally Posted by rafi

minor glitch in 0.8:
http://img406.imageshack.us/i/90388311.png/
Time-stamps in case of one part - should be the same for the package and the part... (I should probably post it in the bug section...)

fixed

thanks

still, statistics info was the main issue in this thread... so I hope to see it "fixed" too...

any chance for the additional statistics ? maybe an entry in the bug-tracker for the farfaraway release ?...
A "started DL at" conlumn (for now...) will be much appreciated

I'm convinced a performance measuring or statistics module can be easily build when the event manager comes back.

It should implement the events for all the download link status changes.

until then, a started-on column will complement nicely the ended-on column. We could the math with our calc...

jD could have a small "data mart" module. In the fact table I would put the downloads with their download volumes (taking into account that a download can be resumed) and in the dimension tables I would put the hosts, the download start and end times/dates, statuses (including problem types), premium/non-P and file types.

This way you can determine how much you downloaded in any period of time, from which hosts, how many problems you had (needs normalisation of status concept - a reset event could delete downloaded data) and what type of data you downloaded, etc.

wishful thinking

If you would be able to get the necessary data with the new event manager, then I think it's not that difficult to build.

A lot depends on the level of detail of the status changes that provoke the events. Also the level of detail of the notification messages or the ways jD's download queue can be queried will play an important role.

A cross-reference to a very interesting thread in the German support forum : "Downloads Statistik PluGIN".

thanks. unfortunately - I'm not able to read that.. but if there is such a plugin - a link will be nice. I doubt it very much that this king of info is suitable for a plugin. It is more logical for it to be in the main program.

Doesn't your browser support translation? If it doesn't, you can always translate to your language with an on-line translation service.

I'm trying to find out from which hosts I download the most in order to find out which premium memberships I should consider, is there any way to make JD tell me?

[pspzockerscene]

@sabret00the
I had to merge your thread with the statistics thread because you didn't use the boardsearch!

GreeZ pspzockerscene

Thanks psp. From what I can gather, that Download Statistiks plugin never came out correct?

That's correct. It is a requirement that hasn't been approved.

who should be approving this ? how about just voting on it instead ? ...

I thought the whole point of a plugin was that those who want it; use it. Those that don't; wont. Thus I'm not sure what's to be approved?

The issue is that this functionality hasn't been put in the svn. It hasn't been approved by someone in the jD Team.

Do we know what the delay is? The original thread was created in April.

I mean for what I'm looking for, it could be done with php, simply take the log and count the recurrences of "new download from xxx", switching xxx for the hostnames and then displaying the data in a table or graph.

If it then said, "sabret00the, 41% of your downloads are from xxx [click here to buy premium]". I'd do it.

Not all important events are logged. The log should be enriched with a lot of other data.

sabretppthe, the answer is very simple... I started using JD at that time, and coming from the torrent world/downloaders - saw what's missing and posted this thread. Apart for being a useful source of info to the user, this can also help in test/debug JD itself. Developers don't like to admit to their bugs, so they don't like test/debug tools... So, it is in the lowest prority...

Honestly, a better individual download control is more important (look for my thread on that) , but if you ask me - it should be released together with this ...

oh, and parsing the log is not a good way to do statistics.... it should be using internal event's data/time

oh, and let me just post a screenshot of statistics available on a P2P downloader. Right, some items are not relevant, but I will settle for half of the rest...

[Think3r]

http://svn.jdownloader.org/issues/show/176
Greetz