Hello, since it isn't the first time I face this issue, I thought of reporting it.

Basically, let's say I have a bunch of links to download from (most times from "Zippyshare's" servers), I just start the process and enable the "shutdown extension" in order it sleeps the system. Most times all the links get downloaded fine, and thus the system get asleep, as intended; but every now and then, there is this time, when a few links (usually one or two) don't get downloaded because "temporary" server side issues. When that happens, even after several retries (with 15 minutes lapses) in some hours, when I come back to the system I see they are just one or two "problematic" files which kept on the system; and curiously enough, after "resetting" the links they start downloading right away (which makes me wonder why none of the previous retries didn't work).

Anyway, could you implement some option to "limit" the retries' attempt amount? So, let's say I fix that value at just 2 attempts per link, otherwise, make JD2 proceed to execute the shutdown task.

That would allow my system get asleep, without idling unnecessarily for hours.

typical hoster issues which are caught in plugin are not user defined, a retry timer is set and core handles how many times a retry will happen before not continuing. At this time this isn't user defined at the core either.

typically JD does try multiple times, only when it exhausts this task does it set no retry. Im not aware of why it happens, I can only guess with zippyshare the server could just be overloaded with people downloading content in the same timeframe and when you wake up its now offpeak and the underlying issue has been resolved?

if dls are marked as no retry, it should allow shutdown event, only a retry event would allow timer to continue and a resumption to take place preventing shutdown.

People have made some scripts to scan for errors to auto resume (remove the error, and place dl back in queue or even reset (but you loose data dled). You can find that in the event script thread. I would possibly allow a loop to happen and prevent shutdown either further.

This happened a few times so far, and the only common characteristic I remember in all cases was
the amount of links involved; when they exceeded, let's say, 130-50, the issue was triggered. I don't know if that
was really a determinant factor in order for it to happen, or rather, a mere expectable outcome since the bigger
amount of links.

If I remember correctly, those problematic links always get stuck without even starting; they just get a "problem" related message on them.

3- I start the downloads (20 chunks/16 parts). Downloads progress normally, sometimes with "early" problematic links, but those usually end being downloaded fine. The whole process should take around "4" hours, but when I later check the system after approximately "7" hours, I found it wasn't put to sleep, because 1 or 2 problematic links that weren't started.

4- I manually reset such links, start the downloading process and they are finished alright.

That would mean none of the JD2's retries (12) attempts were successfully executed; and the precise kind of moment,
where I would like to configure JD2 in a way that it just omits problematic downloads, which didn't start
after 2 or 3 attempts, and make it proceed to sleep.

do you have to use a reset? vs resume. ? if so maybe its todo with chunking at high levels even though you restarting with the same. I know in the past there have been resuming errors which prevent dl from finishing. I'm not aware of any longer, but hey could be possible.

Out of curiosity have you tried using less chunks and see at what least total (chuks*simdl) number of connection can still (on average) max out your internet connection?

While the downloads are still being processed ("start downloads" button still active), I just pick the faulty files and
reset them, since they didn't even start; so they are resumed right away. And although I don't remember exactly, I think most probably stopping the downloads and starting the process again would produce the same result.

I didn't tried decreasing the chunks amount even more, but before I switched to 16, I was using 20. Most of the times
the downloads are processed rightly, but I think I will just create a log the next time this problem shows up, so you might be able to see what's the exact deal with it.

P.S. I see the "start downloads" button is still able to being pressed and downloads process starts, even if there isn't nothing to download. Is that by design?

OK, it happened once again just a moment ago and I was able to reproduce it:

1- After downloading 169 links correctly, there was this one, who started blocking the sleeping process:

**External links are only visible to Support Staff****External links are only visible to Support Staff**

2- At the same time, I tried to download the very same link but using another system (same JD2 configs), and although it struggled a little bit before starting, the download ended correctly:

**External links are only visible to Support Staff****External links are only visible to Support Staff**

3- Undoubtedly, JD2 is having some difficulties with this particular Zippyshare's link, here I leave you some tests I made with it:

**External links are only visible to Support Staff****External links are only visible to Support Staff**

What happened there was after starting the download process it just thrown the error message and its counter; I forwarded system's clock, it started downloading fine, I stop it and reset it; then, I started it again, the error message showed up, I reset it (this last step two times). Error message shown up again, this time with a 30' counter; I forwarded system's clock, the counter showed up again and then I stopped and started the download; it got stalled once again. I made the last reset to it, and it finally was downloaded completely.

The specific download link:

**External links are only visible to Support Staff****External links are only visible to Support Staff**

I tried a few times with IDM and it always started downloading just fine, so I doubt the above issue had to be particularly
with a Zippyshare's server being the culprit here; it seems more like on the JD2 side, although it downloaded the previous 169 links just fine.

20.01.20 01.35.43 <--> 20.01.20 01.26.55 jdlog://5469330900751/

What it would be good to have for these kind of cases, is JD2 just overriding the download process timers and simply
proceed to execute the shutdown extension's order, in case it failed 2 or 3 retries attempts for 1 or more files.

This would make everything very complex.
Sure you could say "Shutdown if no download progress is made within X minutes after last progress was made" but then again it would even shutdown if you have downloads pending which e.g. do not work at the moment because of e.g. these reasons:
- Account traffic is empty but will renew in X hours
- Multihoster currently has issues with hoster XY but it may work fine if you keep trying for several hours
- Limit reached and next download possible in X hours

If you ask me, you should make yourself a script for this as this is not a typical usecase and would cause more issues for other users than benefits ...

I see, well I have this problem only with Zyppyshare and it occurs every now and then, but when it happens it gets very annoying because it makes my computer keeps on idling for hours, and just because one file that couldn't be downloaded or finished.

As it seems it's an issue about how JD2 handles some Zippyshare's downloads, I thought off maybe some specific, optional setting could be added to its plugin, which handles this kind of cases.

Otherwise, I would have to think off some script which simply makes JD2 stop retrying after 2 or 3 failed attempts, and just execute the shutdown extension if there are no other active downloads.