[botmtl]

(skipped the other shutdown tasks, as most of them are done under 1 minute)

--ID:11TS:1510105983617-07/11/17 8:53:03 PM - [org.appwork.shutdown.ShutdownController(log)] -> [16/29|Priority: 10000]ShutdownController: start item->ShutdownEvent: Save Downloadlist
------------------------Thread: 11931:org.appwork.shutdown.ShutdownController.log-----------------------
--ID:11931TS:1510106207790-07/11/17 8:56:47 PM - [org.appwork.shutdown.ShutdownController(log)] -> Request Shutdown: org.jdownloader.updatev2.InstallUpdatesOnExitRestartRequest@1d08a544
------------------------Thread: 11:org.appwork.shutdown.ShutdownController.log-----------------------
--ID:11TS:1510107642129-07/11/17 9:20:42 PM - [org.appwork.shutdown.ShutdownController(log)] -> [16/29|Priority: 10000]ShutdownController: item ended after->1658512
--ID:11TS:1510107642129-07/11/17 9:20:42 PM - [org.appwork.shutdown.ShutdownController(log)] -> [Done:16/29]


The problem has to do with having a big download list. While shutting down, jd seems to be checking if every file in it's download list exists of not. 75000+ System.IO.File.Exists() takes a while to run, especially in a jvm.

Is there a way to bring down that shutdown time? I have already disabled the rename file if package is renamed / move file is package is moved options in the config. In theory, with those 2 disabled, jd doesn't have to do any file io once it's done downloading a file.

Also, the links are marked disabled (doesn't seem to help any).

[Jiaz]

Can you please provide full logID?
JDownloader does not query file exists on shutdown. Did yo check these IO with any tool or just wild guessing?
Was JDownloader running or idle/non downloading? Was extraction in progress?
My guess is that either downloads or extraction was still running or something was blocking shutdown process. Need a full log to tell more

What I can think of is that your java does not have enough heap(memory) for so much files. Please check about dialog for the 3 memory infos

[botmtl]

Originally Posted by Jiaz

Can you please provide full logID?
JDownloader does not query file exists on shutdown. Did yo check these IO with any tool or just wild guessing?
Was JDownloader running or idle/non downloading? Was extraction in progress?
My guess is that either downloads or extraction was still running or something was blocking shutdown process. Need a full log to tell more

What I can think of is that your java does not have enough heap(memory) for so much files. Please check about dialog for the 3 memory infos

Not a wild guess, I had process monitor (**External links are only visible to Support Staff**procmon) running.
07.11.17 09.54.20 <--> 08.11.17 20.14.26 jdlog://5274914015941/

[botmtl]

I think I may have some clues as to what is happening. I always thought that the file checking happened at shutdown but there is something I almost always do right before exiting JD that may be the real culprit.

Before shutting down jd, I usually merge all my download packages together (by merging I mean I select all the packages in the download list and do a "move to new package" so they are all in one package). It's my "download history" package (the one with 75000+ links).

When looking at procmon, it looks like I get all the file activity after doing that.(rather than being related the shutdown event).


Just to be sure, I did a shutdown without merging any packages together and I did not get even one QueryDirectory/QueryOpen in my download folder (B:\Downloaded in the image above) confirming that this is not related to the shutdown but has something to do with the merging.

[Jiaz]

Moving/Merging Links in List will also move the files.
You can disable this via Settings-Advanced Settings-GeneralSettings.movefilesifdownloaddestinationchangesenabled

An in case the files cannot be moved, they will be copied/removed

[botmtl]

As stated in the first post, I have already disabled the two options that can result in this happening (movefilesifdownloaddestinationchangesenabled and renamefilesifdownloaddestinationchangesenabled).

The workaround of simply not merging packages in the download list is ok though.

[Jiaz]

Will check and optimize that, thanks for the feedback!
With one of the next core updates, there will be an optimization to use less IOs