[buggsy]

Hi JD2 team,

I downlaoded a rar file from k2s.cc and the resulting file was reported as broken by WinRAR. A binary diff showed two rather small parts which were different. A combination of both resulted in a proper RAR archive. None of the 4 differing blocks was all-0, it has high entropy.

May there be an issue with resuming downloads? I'm happy that this is rar so I was able to detect the mistake, but for non-archive formats the error would not even be detectable I guess.

[Jiaz]

@buggsy: no changes in download system in ages/many many years and there are no known issues with resume or broken files either.
How many connections are you using? how often did you stop/resume the download? have you checked disk with smart values and also memory with memtest86. until now all reported issues where hardware/software (eg firewall, av) caused issues.
In case you can reproduce the issue, please report back so we can further look into it and find cause of it

[buggsy]

Chunks per Download is set to 1.
I did not stop/resume, JD did automatically (I guess due to reconnect)
CrystalDiskInfo says SMART is fine.

Memtest86 takes a day or two, right? Its not a flipped bit, its larger fractions.

[Jiaz]

Originally Posted by buggsy

Memtest86 takes a day or two, right? Its not a flipped bit, its larger fractions.

I had several damaged memory modules and those errors were always found within the first 1-3 minutes, never in late runs. And it's just a test.
And 4 different blocks would also mean that resume did at least take place 4 times if it would have been caused by resume when downloading with 1 chunk.
I can only repeat myself that no changes in many years, no resume errors in even more years.

[buggsy]

Sorry, I did not write explicitly that I downloaded the file twice (which is required in order to compare).
The 4 different blocks are in the two downloads of the same file. Lets say its file a and b and the differing sections are 1 and 2.

Combining a1 anb b2 formed the correct file, so a2 and b1 were faulty - one section per file. Both have been resumed at least once. If resume would messed up the files that would totally explain the observation.

I'll check metest86 later.

[Jiaz]

@buggsy: please check if you can reproduce the issue and also please provide a log from the session that resulted in damaged file, see https://support.jdownloader.org/de/k...d-session-logs
Normal resume or anything special like killing JDownloader or shutting down or anything like that?

[buggsy]

memtest86 ist much quicker than I remembered. It took about 1hour per pass, so I completed all 4 passes without any error.

As I said it was an automatic resume, I did not manually interrupt network connection or kill JD2. I assume JD2 did a reconnect before the resume because only k2s was running and k2s is known to JD2 as resumable.

I doubt I can reproduce it, but I'll try

[Jiaz]

@buggsy: Thanks for the followup. I need at least some logs from such a moment to see headers and have something to start testing on. Just report back in case it happens again and then we can try to look for and into existing logs