View Single Post
  #7  
Old 15.06.2017, 03:37
raztoki's Avatar
raztoki raztoki is offline
English Supporter
 
Join Date: Apr 2010
Location: Australia
Posts: 17,611
Default

@imagetypers

from the OP
topic 1, 5, 6, 9 are relevant.

10 but not for the reasons he stated, but related to issue 1 (so duplicated point/topic). Over the years we have had reports that chunking increases the crc corruption. As virus scanners couldn't deal with chunked data, they wanted everything in single chunk to scan from position beginning to to end in which a single chunk provides. I'm not aware of any chunking bugs in JDownloader that caused crc corruption. Typically chunking will not increase data corruption by its use.

8, probably doesn't apply now as many new versions our out since. But goes to show that issue 1 is very important.

7 deleting temp files wont influence data corruption, and "possible errors"**, very vague...

4 misconception, this never happens. Full harddrive just means no where to save. It can't save data onto components that are already full... kinda also related to issue 3. full harddrive usually means downgraded performance on write cycles.

3 I don't agree with defragging statements. fragmented harddrdive doesn't increase crc. Defragging actually increases read/write performances by moving related data closer together so the head of the physical harddrive doesn't have to seek as far during normal access. The trade offs with having nearly full harddrive is it has limited scope to where to store data. Thus more fragmentation occurs with full harddrive and performance downgrades. Defragging regularly also has downsides as it wears your device out for example; each sector on the harddrive has limited write cycles (same with SSD). If you read the warranty of the drive it will tell you typically lifespan via used hours.

2 I don't agree with this, your network hardware has QoS along with your operating system. This provides ability to share bandwidth based on pre determined algorithms. Some hardware lets you define this also. In the scheme of things, JDownloader transfers mostly over tcp/ip in which has built in error handling which deals with limited data corruption. Best practice is not to set connection settings within JDownloader higher than required (test to see the least amount of connections to max out bandwidth, for example if you have 1mbit internet, you don't need 20 chunks * 20 max sl dl = 400 downloads, you probably need 1 chunk * 1 download), otherwise this can fight hardware' QoS functions and other devices on the network or even on the same system do not get enough bandwidth and connections can suffer socket related issues.

I would expand on 9
not just memory (RAM), it can be related to other hardware like network hardware and network drivers or harddrives failing. This is quite common believe it or not.

raztoki
__________________
raztoki @ jDownloader reporter/developer
http://svn.jdownloader.org/users/170

Don't fight the system, use it to your advantage. :]

Last edited by raztoki; 15.06.2017 at 03:39.
Reply With Quote