When some items of package are disabled/inactive INFO writer don't create INFO-file log, and informatin abot this package is newer wrote to disk.

_________
I'm using INFO files for various archival purposes, and especially those log files are usefull for me when package get some issues.

When I grab filelinks from some blogs, there are soetimes alternatives for file download located on various hoster sites. jDownloader are performing wery well going trough download list, and when we are downloading from one source, other parallel sources become disabled (inactive). Somtimes I manually dectivate some of links, for various reasons - this feature also work very well, recalculating properly whole package size and time.

But INFO-file is not written in those situations, probably becouse jDownloader wait (infinitelly) for completion of whole package with all items in it.
_________

My sugesstion is to add possibilty to force jDownloader for re-writing INFO log after ALL succesfully finished sub-file download for given package.
The simple way will be, of course, to append the new log onto the end of the previous, and this should give us some kind of download history for package.

But IMHO there will be a good idea to add some "inteligence", and during rewriting INFO log, write to disk only new/changed data, leaving previous common information intact.

Maybe creating folder/INFO for package should be done right after adding package to download list?
_________

There will be also a good idea to expand INFO write possibilities to have more field/items about file/package insertable into INFO log.

jDownloader becoming for me to be general/main download helper, thus archival history/data will be very usefull.
For me perdonslly there will be good idea to have oryginal/real URL of all downloaded file with finshed time and date (download folder isn't so important, becouse I always moving finished files to another location).

I'll try to understand and reply to some of the issues you mention. Note that I don't use the JDInfo File Writer extension.

I use a simple text file for gathering my links, updating download workflow status and avoiding duplicate downloads.

When links are disabled, packages do no longer present accurate information to the customer. I suppose the JDInfo File Writer extension has a similar problem.

I fully agree with you that jD needs to provide more information about its downloading activities.

Could you please first read some other threads and feature requests, before we continue the discussion about some of your suggestions? :-

- Add some time & volume statistics info.

- Feature #174 : Eventmanager Rewrite.

- Feature #176: DownloadHistory.

[Jiaz]

please test the nightly version, as some changes went into the filewriter addon. check if it works better/correct in nightly (use boardsearch how to install it)

1. I like to have log-data about downloaded file (especially if this is software). If some of my past downloaders don't do it for me I was often writing this file manually by myself. And I'm also using simple text file for this purposes and don't want it to be other way... :-)

2. If some of individual download task in package become inactive, JD tick-mark package as fully downloaded, but log is never written.
So, if I entered any comment for package, I must go to JD interface and read it here - this is posible only before deleting package from JD download list.

3. Most important for me is to have record (for each downloaded file) with my own comment, original URL from where file was downloaded, and the date&time of download finish.
Record about source adress page will be also very apreciated (entered manually or generated auto-magically).

4. It will be good to have option to tell JD about writing data (mentioned above in #3) for all individual downloaded file right after each individual succesfull download.
It is acceptable for me to have individual log for any downloaded file in package, and additional log for whole package.
This way, when some of the links became inactive, one would have log for the finished files written properlly after download - even if package become incomplete.

5. If logs for individual finished files will be created as plain text file, then log for whole package can be optionally created as HTML/XML file - with hot-points working as link to individal per-file created text log.

6. Looking for threads/issues mentioned before I found very intersting two of them: #174 (Eventmanager Rewrite) and #176 (Download History).

#176: Download History - should be disabled by default (enabled only per user choice) and should have possibility to remember three lists:
A. curently on download queue (as today is done), succesfully downloaded files, all other files which become at any time on JD sight.
(All three lists should be included for backup command also...)


Greetings
eMeR Manix

I've been analysing your interesting requirements and this is my feedback :-

1) You keep information in one file manually. Why do you want the information generated by jD dispersed in so many small files?

2) Why wouldn't jD log errors on files as well? This way you can detect when downloads and packages are in error.

3) You're asking for the time the download finishes. Why don't you want to have the start time as well? (I know you can get this from the file properties)

4) Again, why have many small files if everything can be logged in one file? If jD logs to which package a download belongs, all download meta data can go to one file.

5) Why do you make it so complex? If there would be one customer oriented log in XML format, wouldn't that be sufficient?

6) If all downloads could be sorted/filtered according to their status, would that be sufficient? For the 'status' discussion I refer to this State Diagram.

Firstly I apologize for long delay in my ansver.


Ad 1)
Of course it will be better to have only one log file. But only when info file were written for all subseqent file. I simply want information/log for any file in package, but this is probably hard to get in current JD (I don't know about that)...

Ad2) Agree. Errors loging will be also usefull

Ad 3) Right! You are developer, and you are thinking about needs of all users.
But for me personally, only end-time is needed :-)

Ad 4) Agree. See also Ad 1)
Maybe the better way will be to write info/log separately for any file until package state is unknown. And after sucesfull completion of package delete all partial logs and compile information in one file?
Or make them all optional, and give mix of any possibilities tho be choosen by end-user?

Ad 5) As I wrote in Ad 1) it will be better to have some information, even in partial - than have nothing at all.
I prefer plain text logs over each-other becouse this way it is fast readable by any human without additional assumptions.
Thinking about XML like about cake and bread - text (like bread) is ordinary/everyday, XML is for niceing daily task (and can make you over-sized). :-)
Please simply forgot this...

Ad 6) I'm not sure about that...
I try show download list HISTORY states this way:
EP: Exist-in-Progress (waiting/downloading/disabled/inactivated)
EF: Exist-Finished
NF: Finished&Removed (removed from list after sucesfull download)
NU: Unfinished&Removed (removed from list before completion, seen before)
NN: New (newer seen/downloaded by JD on user behalf)

But maybe you are talking/asking about other things...?

Thanks for your feedback.

XML is human readable text that is also machine readable. XML allows all sorts of manipulations and would accommodate all sorts of requirements to be implemented outside of jD.

I would like this type of information shown inside jD as well. A few added columns, a filter and an export feature for this data would provide snapshots.

A customer oriented log is much easier to implement though and would contain the complete download history of links.

I know the history and deletion logic are missing from that diagram (these are discussed further in the thread), but I think together with a more recent Linkgrabber states discussion it provides all useful states any customer could require.

I'm dealing with XML files from time to time, but I think this format is more suitable for templates or config files than for end-user reports/logs.
But this is, of course, only my own (personal) point of view...

I cannot discuss any further JD states mentioned by you, but if history feature can be done, and when will be done, I give it a try...

You underestimate XML's importance. Please, read "http://en.wikipedia.org/wiki/XML". You'll be astonished by the versatility and applicability of XML.

The language is used in almost all software and web applications of the last decade. Hundreds of languages (XHTML, RSS, OpenDocument are among them) are based on XML.