The problem seems to be that sometimes the changesSaver requests a write (very often) and other times the downloadSaver. With the default values for changeSaver(5-60 seconds) you get lots and lots of rewrites, the downloadSaver behaves a bit more sane.
I changed my DownloadController.java to the following:
**External links are only visible to Support Staff****External links are only visible to Support Staff**
As you can see I added logger events for every possible event of changeSaver among other things.
I think the changeSaver values are far too low with 5-60 seconds. As an example see this log, where I just change package names several times. HHH is the event onDownloadControllerUpdatedData(FilePackage pkg, FilePackageProperty property), changeSaver-run means a request to changeSaver and changeSaver-delayedrun is the actual backup routine then running. This means that in those 3.5 minutes my PC wrote >1.5GB of backups and used my 4 core CPU with 25% alone. This is quite heavy for some backups...
Next see the attachment, this is a log with all the events (marked by my modified source above) - as you can see "onDownloadControllerUpdatedData(DownloadLink downloadlink, DownloadLinkProperty property)" goes full rampage with the amount of events. In this log, the frequency for changeSaver was set to 360s, 360s and minMsBetweenRuns also 360s
I fixed it for myself by just brute force denying the "private void saveDownloadLinks(final boolean ignoreShutDown)" when not x minutes have passed:
You can see in the log how often the write request was denied ("saveDownloadLinks DENIED" or permitted "saveDownloadLinks GRANTED") - keep in mind this was with 360/360 for both savers, with the original values you will get spammed with DENIED a lot(!) more.
If I may bring forward my ideas:
- changeSaver with 5s-60s is far too frequent
- downloadSaver and changeSaver do ignore each other despite basically doing the same thing resulting in the events that I wrote about earlier with back-to-back backups - this happens in the log for example at "ID:2626TS:1508926014086-25.10.17 12:06:54" both try to request a backup.
- I fixed this by just putting a hard block into the source as I don't think that many backups are necessary (one exception for that hard block would be adding the AAA event ("onDownloadControllerAddedPackage(FilePackage pkg)" to some exception as here a backup actually makes sense.
Besides that I think it would be made more elegant by
a) giving the user the option to set the min/max time for both downloadSaver and changeSaver in the advanced options, and
b) making downloadSaver and changeSaver be aware of each other so that only one runs in a timespan of x minutes (x maybe being Math.max(minChangeSaverDelay, minDownloadSaverDelay)?).