[SMS]

If JDownloader crashes shortly after adding links from the LinkGrabber to the Downloads list, those links disappear from both lists.

Maybe JDownloader first deletes the links from the LinkGrabber file and only some time later writes them into the Downloads file. The opposite order would be better, in order to not lose the links.

Thanks!

[mgpai]

You can adjust it in Advanced Settings. Keyword: savedelay.

[SMS]

savedelay yields four search results:

DownloadController: Maximum Save Delay
DownloadController: Minimum Save Delay
LinkCollector: Maximum Save Delay
LinkCollector: Minimum Save Delay

What values for them ensure that links are first written into the Downloads file and only then get deleted from the LinkCollector file? I doubt that any settings can currently ensure that. I suspect that this is still an open bug.

Note that the Downloads list might be much larger, and saving it might be arbitrarily slowed down when other programs occupy the CPU.

Saving the LinkGrabber file should start strictly after the Downloads file has finished saving, not just some time after it started saving.

[notice]

Originally Posted by SMS

Maybe JDownloader first deletes the links from the LinkGrabber file and only some time later writes them into the Downloads file. The opposite order would be better, in order to not lose the links.!

I agree with this. currently this may indeed lead to loss of links in situation like described.
I've created an internal ticket for this. Though it sounds easy to implement it's little more complex and thus can't tell when we will find time for this. writing of changed Linkgrabber list has to be delayed until the moved links to downloadlist are stored on disk.

[notice]

Originally Posted by SMS

savedelay yields four search results:
DownloadController: Maximum Save Delay
DownloadController: Minimum Save Delay
LinkCollector: Maximum Save Delay
LinkCollector: Minimum Save Delay
What values for them ensure that links are first written into the Downloads file and only then get deleted from the LinkCollector file? I doubt that any settings can currently ensure that. I suspect that this is still an open bug.

No real *solution* but by having LinkCollector higher delays than DownloadController will make sure that the writing of Download list will happen earlier than writing of LinkGrabber list. For example set LinkCollector minimum larger to max of DownloadController max should achieve this.
DownloadController: Minimum Save Delay to 5000 ( 5 secs)
DownloadController: Maximum Save Delay to 60000 (60 secs)
LinkCollector: Minimum Save Delay to 90000 (90 secs)
LinkCollector: Maximum Save Delay 180000 (180 secs)
But of course this creates larger *time gap* for possible loss of links in LinkCollector that are added within that time frame when power is lost or other
issues

[notice]

Originally Posted by SMS

If JDownloader crashes shortly after adding links from the LinkGrabber to the Downloads list, those links disappear from both lists.

JDownloader should not crash at all! Crash mean that Java/underlying OS has crashed badly and JDownloader had no time to gracefully shutdown.
We should find out the cause of the crash. Please check the JDownloader folder for hs_err files and in case there is one, please send to support@jdownloader.org

[pspzockerscene]

Sidenote:
We also gut a support article which explains those "Save list settings":
https://support.jdownloader.org/Know...nkgrabber-list

[SMS]

The article about restoring doesn't help if I move links from the LinkCollector to the Downloads list before a backup of the LinkCollector list has been made.

Thank you for the ticket!

Regarding crashes: I don't remember whether actual crashes occur where the javaw.exe process disappears, but what has been happening for years is that the UI sometimes remains unresponsive (with JDownloader using about 70% of the CPU) no matter how many hours I wait, so I have to terminate javaw.exe or reboot. In one case, this was solved by choosing the non-default option of synchronous execution of EventScripter scripts. But there are also several other causes, a new example is https://board.jdownloader.org/showthread.php?t=93125 where sometimes the UI becomes unusably slow.

[pspzockerscene]

Originally Posted by SMS

The article about restoring doesn't help if I move links from the LinkCollector to the Downloads list before a backup of the LinkCollector list has been made.

I've only linked it as it contains an explanation of those settings.

[notice]

Originally Posted by SMS

In one case, this was solved by choosing the non-default option of synchronous execution of EventScripter scripts.

In that case JDownloader is still running but the GUI can be blocked because your script has caused a deadlock situation, eg blocking/synchronous execution and then something else is waiting for script to finish and gui is waiting to access internal queues/aquire locks and voila, GUI is frozen.

I define crash = process gone/no longer running. Unresponsive UI or frozen GUI, the process is still running and a sign that something causing GUI to be slow/blocked. JDownloader auto detects frozen GUI and writes out stacktraces to log in such situation for later debugging.