[baloneysammich]

I'm sure this has been discussed before but I don't know how to search for it.

I was downloading a multi-part archive with parts hosted on multiple sites. My internet was interrupted, and when connection was restored JDownloader started some parts "from scratch" (from a different hoster) rather than resuming the partial download. A couple of interruptions and this basically "wasted" several GB.

I assume it's related to the fact I set Max Sim Downloads per Hoster to 1. But I'm hoping there's a way to prevent this issue without disabling that setting. Thanks.

[notice]

@baloneysammich: please be aware that most free hosters do not support resume of incomplete files. most often this feature is restricted/limited to paying premium customers. do you remember what hosts you were downloading from?

also current download core does not support resume of partial file from different host as the resume information cannot be accessed by different host/plugin at the moment. there are open tickets/pending work for this.

do you remember what host started the download and which one tried to resume it? do you have example links at hand? I've got an idea for a workarond till next download system is ready

[baloneysammich]

Most of the hosts I use support resume, at least according to JD (they show the green arrows in the Connection field). Unless that's misleading and may only apply if one has a premium account; I don't have any. In any case, it happened with files on different hosts, but one I remember for sure was Anonfiles.

Maybe I need to be more clear though. I know JD doesn't support resuming on a different host. What I'm saying is, for example, before the disconnect I was downloading several files (I had Max simultaneous Downloads set to 4 or 5), one from Anonfiles. All the files had the same several mirrors. After reconnect, JD chose a different mirror instead of picking up where it left off from the Anonfiles mirror.

Like I said, I expect this might not happen if I didn't set Max Sim Downloads per Hoster to 1. I was downloading other parts of the archive at the same time and presumably one of those started downloading from Anonfiles first, preventing JD from using it for the partial download.

IIRC some parts resumed, but others didn't. It seemed like that was pure luck, as though JD just chose a mirror at random for each part rather than deliberately trying to resume each partial. This has happened on at least three different occasions.

[notice]

@baloneysammich: Thanks for the detailed feedback. Yes, now I understand and can confirm it's current known limitation/issue that JDownloader currently cannot resume partial file from hoster X with hoster Y. I have an idea/workaround in mind that may ease/solve the problem. progress is always lost when JDownloader tries to resume file with different hoster. and with multiple mirrors existing in list, this may happen and lead to data loss/unnecessary redownload of file.
The idea/workaround in mind should not be that complicated so might be able to implement it near future.

maybe an idea for a temp. workaround could be to disable mirror detection, see
Settings->Advanced Settings->GeneralSettings.mirrordetectiondecision
and then let JDownloader auto skip, GeneralSettings.iffileexistsaction to skip and then GeneralSettings.onskipduetoalreadyexistsaction to skip and mark as finished

that way the mirrors should be skipped and JDownloader resume/continue on hoster that started the download

[baloneysammich]

Thanks, I will give your workaround a try when I can and report the outcome.

[notice]

Originally Posted by baloneysammich

Thanks, I will give your workaround a try when I can and report the outcome.

Thanks for spending your time on testing

[baloneysammich]

I configured as you suggested but it did not prevent JD from starting from scratch on new mirrors after an interruption. To test I forced an interruption by changing VPN server.

Again I'm downloading multiple parts of a multi-part archive simultaneously, 1 download per hoster. This time I'm using only hosters that support resume according to JD:

Anonfiles
Bayfiles
Clicknupload
Uppit

Is it possible the file exists detection just ignores the .part files of partial downloads?

[notice]

@baloneysammich: seems that something did not went as I thought. because there should be no other enabled mirror available anymore to pickup the download.

Originally Posted by baloneysammich

Is it possible the file exists detection just ignores the .part files of partial downloads?

That's not the reason why it doesn't work as intended.
I guess it's because of "1 download per hoster". can you please try again with this disabled. JDownloader then should start the mirror links as well and then the desired handling should happen.
with it enabled.

[baloneysammich]

I think disabling "1 download per hoster" will just push the issue back, at least to the point "Max. simultaneous Downloads" is reached. I may give it a try just to report back, but I have no intention of actually running that way in practice.

One thing I noticed is that as long as other parts got marked "Finished(Mirror)" JD wouldn't try to start them after an interruption. Screenshot:

Spoiler:

But that only happens if JD had already tried to start those mirrors before the interruption. Notice that for part 1, all three other mirrors are marked Finished. For part 2, only 2 are marked Finished. Part 3 is an exception because there's no clicknupload mirror. Part 4 doesn't either which is why part 5 was started.

I think that disabling "1 download per hoster" would make it so that only the last started part will have mirrors that aren't marked "Finished(Mirror)". So only one possibility for JD to start from scratch instead of resume. But if there were a way to automatically mark other parts as Finished even if JD didn't try to start them, I'm pretty sure it would solve the issue regardless of allowed downloads per hoster. Of course that would be problematic for people who would rather have another mirror started in case of a more long-term download problem from a certain mirror.

[notice]

@baloneysammich: Thanks for sharing your feedback. Yes, *Finished(Mirror)* is a final state and JDownloader will no longer try to download those. That was my initial idea for this *maybe* workaround. But as you already found out, it depends on the download order as well.

Originally Posted by baloneysammich

But if there were a way to automatically mark other parts as Finished even if JD didn't try to start them, I'm pretty sure it would solve the issue regardless of allowed downloads per hoster. Of course that would be problematic for people who would rather have another mirror started in case of a more long-term download problem from a certain mirror.

I think it would make more sense to provide a setting so JDownloader disables mirrors instead just making them as mirrors. The logic I asked you to disable before. That would be an easy change to implement and also help you in this situation.
I will try to add this feature for you to test by next week

Originally Posted by baloneysammich

Anonfiles
Bayfiles
Clicknupload
Uppit

It would help me a lot if you could provide set of example links? send to support@jdownloader.org

[baloneysammich]

Disabling mirrors would work for me, but people who are more interested in getting things ASAP without interaction might not like it.

IMO it really warrants special handling. For example if a file with mirrors is started on a mirror that supports resume and there's a connection issue, there should be a "grace period" in which the other mirrors remain disabled. But if the file can't be resumed after a certain time and/or a certain number of retries, then maybe JD can try another mirror.

I avoided sharing links because... y'know... reasons . But I've emailed them now. If you don't want to mess with them I understand.

[raztoki]

Originally Posted by notice

I think it would make more sense to provide a setting so JDownloader disables mirrors instead just making them as mirrors. The logic I asked you to disable before. That would be an easy change to implement and also help you in this situation.
I will try to add this feature for you to test by next week

Think that idea is more inline with what happened with the old core in 0.9 and the old nightly, but was moved away from as that also had hookup issues associated with disabling all mirrors not utilised, active mirror has error, incomplete package.

Maybe easier just to release the new download core and all the features that it adopts ;]