Excelsium

Member
 View profile  See their activity

  • Content count

    99

  • Joined

  • Last visited

Posts posted by Excelsium

  1. Posted

    you can't know it. I've already said that the probability of corruption is stll same.

    Yes, your success rate, but it's only circumstance. For another user it can be viceversa.

    Ok but please answer the questions I posted after.

    I will automate my technique because of its success rate in dc++ normal mode and other p2p clients.

    Other users have had similar or same success rate.

    - My technique is a solution for those users with this set of circumstances.

  2. Posted

    Thats luck,maybe after a PC restart strong/apex will download everything correctly.

    Lol.. of course I've tried all the usual things. - Possibilities

    1. The client cannot repair these files at all

    2. The client cannot repair these files at all within a reasonable time period

    e.g. left running for days at 10 megabits with small files.

    *client: strong/apex.

    I've a question:

    Since we don't fall into the 'hole' 95-99%+ of the time and 95-99%+ of the users other downloads complete.

    Why dosn't the client repair the file when were not in the 'hole'?

    - I've other downloads running at the same time in strong/apex.

    - Other downloads are completing successfully whilst the failing file continues to fail.

  3. Posted

    I think you haven't understood my car story. Car A was "segmented downloading", car B was "normal downloading". And the hole on the road was a bug in memory/HDD etc. And it meant that no matter which method you will use but you will always fail if you fall into hole.

    And it won't switch to normal downloading because it's unsafe. Segmented downloading redownload corrupted chunks (maybe redownloading will never finish) but it doesn't allow to have corrupted file as finished download and that's the most important. Normal downloading has only standard TTH consistency checking but allows corrupted downloads if they get corrupted after sending data to your OS. So why your solution has never been implemented in normal downloading?

    Ahh yes but in 95-99%+ of cases we don't fall into the 'hole' therefore I refer you to my summary:

    1. My technique exists, works - and has been used successfully by myself and others many times already (Manual).

    - If it dosn't work the first time it will on the first retry (95-99%+) with the same probability of success on subsequent retries if they are required which has never been the case personally.

    My success rate in other p2p apps is 99%+ I cant remember the last time I had a problem.

    2. I will automate my technique.

  4. Posted

    I post just to check peoples understanding and give full explanations.

    - I did say its the final time I'm asking him if he understands me or not because I did not see one of his posts before I posted my last reply.

    What makes you believe there wont be corruption when you download smthng with DC++ ? There's no escape from hardware failure...

    It seems you have ignored Bittorrent etc. although I've not had a visible failure yet with normal mode.

    No visible failures yet? Probably because I only use it in 1% of cases - the times when the segmenting download technique fails and the times the files are not available elsewhere such as bittorrent.

    Thats with the old solution though, of course I'm open to the 'hole' now with my current solution - I don't have time for manually obtaining Car A any more.

    I have successfully driven Car A to Car B to my destination many times already

    - when I used to use the current segmenting download technique.

    I will automate the process of obtaining Car A.

    Also one of the 'holes' is Time waste.

    I will make a bridge over that hole.

    One of the other 'holes' is bandwidth waste.

    I will make a bridge over that hole aswell.

    The 'hole' Big Muscle refers to is a corrupted download.

    One can jump into this hole to avoid a bottomless pit called time and bandwidth waste - the manual process of obtaining Car A.

    - The hole is temporary - you have a corrupted download? try again. 95-99% it will succeed without corruption on the first retry in normal mode.

    - 95-99%+ of the users other downloads succeed without corruption so of course it will almost certainly complete without corruption on the first retry.

    You can also use bittorrent or whatever.

    One of these 'Car B' methods have always successfully brought me to my destination, 99%+ on the first try.

    Hence the 'hole' is temporary indeed. unlike the said bottomless pit.

    My original title for this thread is perfect.

    Detect corrupt file and switch download technique - Thats exactly what I've been doing all this time and successfully - I've been doing it manually - I will automate it.

    The Detect corrupt file and switch download technique will enable me to use the segmented download technique in its current form. ** Involves bittorrent etc where possible.

    - No I wont implement these other p2p clients inside the client (strong/apex) 'Car A' information I will simply feed into another p2p clients download queue (Manually). The process of obtaining 'Car A' however will be automated.

    Summary

    1. My technique exists, works - and has been used successfully by myself and others many times already (Manual).

    - I don't use it myself anymore because of the time waste caused by it being manual.

    2. I will automate my technique.

    I don't expect a long reply from Big Muscle.. even 'yes' or 'no' is enough.

    If he dosn't reply I will just refer to his last post.

  5. Posted

    I will agree to disagree with Big Muscle and have accepted he will not build the rest of my solution/feature.

    I'm also tired of writing so much.

    I will reword the opening post sometime so its easier to read and so that it includes the full details listed in recent posts. e.g. including solution 2. is not acceptable if its proven to have a low success rate.

    Maybe you will understand my reply to this - I didn't see this post:

    If couldn't understand it, I'm trying to explain it in non-computer words.

    There is some big hole on the road. You will drive car A and fall to the hole. Your solution is to use car B. You will fall to the hole too! Now understand that your solution is rubbish?

    Car A = Information

    You can use the information to download the failing file successfully using another method 'Car B.'

    - DC++ Normal mode

    - Other P2P Client: Bittorrent, eMule and so forth.

    This is the last time I'll ask if you understand or not.

    1. Car A drives you to Car B.

    2. Car B drives you to your destination.

    Now do you understand ?

  6. Posted

    Possibilities for Big Muscles situation

    -Cannot understand me or why my solution is necessary:

    - Informing the user about the problem, not fixing the problem

    (Properly Informing the user of exactly which downloads are failing and so on)

    - dont want to repost whole thing.

    -Cannot understand the problem.

    -Trying to insult me or ruin the thread.. or some such.

    - Does not want to build the rest of the feature :P

    - Already said that I or someone else will build said feature/solution.

    - Is joking around.

    (another of those defence posts...)

    I think that covers everything.. maybe wont have to post more defences.

  7. Posted

    iceman50: Have you just said you built some of the information solution I'm looking for ??

    Sorry for misunderstanding..

    what BigMuscle was saying was there are not enough experiencing the problem and really no easy way to figure out what is causing it... the spectrum is too broad and it's just one of those things you will have to live with

    So hes said hes not going to build the simple 'informing the user about the problem' solution - I will or will have a friend do it it for me.

    Or maybe someone else will :P

    - As said hes already going to build part of it - TTH in the corruption message.. first enabling part.

  8. Posted

    What do you mean by this....i have created some solutions for this problem (in pseudo code and in actual raw c++) so i will develop my own test situations on a virtual machine

    I mean we download the files that failed to complete using sdc++ segmenting mode in other p2p clients.

    - Or DC++ normal mode, where the files are only available on the DC++ network.

    Thats my old solution though, I guess others still continue to do manual detection which is a pain for them.

    Basically the detection should be automated... so we can catch the failures conveniently - add downloads to queue in normal mode or other p2p client.

  9. Posted

    yes but do you understand even informing the user is extremely futile for the exponential amount of problems it could be.... sure maybe it will stop wasted bandwidth ... but it is theoretically possible you could never find the probem so what solution do you want now? DON'T DOWNLOAD .... there is a solution for you it stops wasted bandwidth and countless retries that fail

    - In that case the user should still be informed

    As is the case I and others continue to use the client with "bugs in our machines" because of its 95-99%+ success rate.

    I forgot a key point.

    - For dealing with the 1-5% failures I will download them in normal mode in another instance of dc++ - this mode allows corruption. - if solution 2. is proven to have a low success rate.

    - Where the files are available on bittorrent/etc I and other users catch the failures in this manner.

    My current solution

    Download everything in normal mode - I dont have time for manual detection

    I'm testing an old version of Apex that may allow corruption in segmenting mode.

    My old solution

    Download everything in segmenting mode

    - Detect failures manually

    - Download failures in another instance of dc++ in normal mode or other p2p client.

  10. Posted

    so let me ask you this .... what if it is 1 Kilobyte of corrupted ram causing the bug..... you would never know (and surely never think to use memcheck to find the problem) and even if not that.... it could literally be an exponential amount of other problems causing the corruption ... .you would never know ... so no solution is fit to fix them

    - Its not a solution to fix the problem.

    - Its a solution to properly inform the user of the problem so they can do something about it.

    - It detects and stops the problematic process (The download with corrupted temporary file that is almost certainly beyond repair of the client itself (StrongDC++).

    - It stops the problem in the mean time wasting their own and others bandwidth.

    - It prevents wasting the users time by having them themselves detect the problematic process.

  11. Posted

    I don't see any need to further discuss this with Big Muscle.

    It seems the only replies to Big Muscle would be to defend myself.

    - I can see potential for massive shrinkage of this thread as 'Solution 2.' is indeed ridiculously wasteful if its proven to have a low success rate. It seems Big Muscle won't reply on 'Solution 1.'

    - I will rework the opening post.

    - I'd like to focus this thread on 'Solution 1.'

  12. Posted

    Solution 1. Is waiting for a reply.

    I'm sure I'll get a good reply eventually agreeing or disagreeing.

    If not from Big Muscle then from someone else.

    Big Muscle said hes going to build the first part of 'Solution 1.' for me (TTH in corruption message).

    I will build the rest of 'Solution 1.' myself as Big Muscle said he will not.

  13. Posted

    I have already reply but you weren't able to understand. True, I haven't replied to solution 1 but to all solution generaly.

    so again my answer THERE'S NO POINT IN OCCUPYING WITH ANY SOLUTION BECAUSE THERE'S ONLY SMALL AMOUNT OF USERS WITH CORRUPTED COMPUTER, SO THERE WILL NEVER BE ANYTHING MORE THAN REDOWNLOADING CORRUPTING CHUNK.

    IF REDOWNLOADED CHUNK IS CORRUPTED AGAIN, IT'S NOT OUR BUSINESS!!! UNDERSTAND IT??? I WILL NOT SAY THE SAME THINGS STILL ROUND.

    Solution 1. is a seperate entity to Solution 2.

    Big Muscle has not replied to Solution 1.

    So I'm requesting replies about solution 1. that do not include solution 2.

    I have already admitted I will abandon Solution 2. if the success rate is low.

    - The redownloading chunk issue is your business - the user should be given solution 1. so that in the mean time that they have problems with their machine the client does not waste bandwidth.

    - This also prevents wasting the users time - they don't have to observe the transfers window until they find the problem. (manual user detection).

  14. Posted

    Please read my post again and read solution 1. and also solution 2.

    I have modified it alot since you posted your reply and before I read your reply.

    I will repost a little here:

    If solution 2. turns out to be problematic

    I would just stick with solution 1.

    a) Present the user with dialog box with which download queue item has corrupted temporary file that is almost certainly beyond repair by the client itself (StrongDC++)

    b.) Pause the download allowing the user to "fix their machine" and come back later to resume the download.

    Reply to your post:

    About solution 2.

    Yes that would bring more waste if it wasn't for the fact that 95-99% (or higher) percentage of the users other downloads complete successfully

    - So this new restarted download will probably also succeed 95-99% (or higher).

    - The file would not have to be redownloaded 1000x like the chunk.. the chunk redownload may be infinite

    as said on a download going at full speed for a week at 10 megabits.

    - The file would probably succeed on the first redownload - 95-99%+

    - Please point out to me how this would waste more.

    Please test your own understanding.

    1. Chunk is redownloaded 1000s of times or infinitely

    2. 95-99%+ of other users downloads complete successfully

    3. Redownloading file with new temporary file has 95-99%+ success rate

    The automated process (Redownloading file) would only kick in if the same chunk(s) have been redownload many times e.g. 200

    making it almost certain the problem (redownloading chunk) is infinite or 1000s+

    - Hence redownloading file wastes less and is currently a manual process that needs to be automated - it wastes the users time.

    - If this (Solution 2.) turns out to be a dead end, can anyone argue for or against Solution 1.?

    About Solution 1. Do you agree/disagree, why?

    So on my solutions

    2. Were arguing about the success rate of restarting download

    - I say its high (95-99%)

    - Big Muscle says its low (%)

    - If it turns out the success rate is low then I will abandon this solution because it would cause even more waste as Big Muscle and others have said.

    1. I have not recieved a reply from anyone on this solution yet. - it seems it has been ignored and all the replies have been about the controversial solution 2.

    Solution 1. download is deleted or paused preventing waste.

    - If it is paused/deleted the user could "fix their machine" and come back and resume/restart download.

    a) Present the user with dialog box with which download queue item has corrupted temporary file that is almost certainly beyond repair by the client itself (StrongDC++)

    b.) Pause the download allowing the user to "fix their machine" and come back later to resume the download.

    - Dosn't have to be dialog box, can just be pausing and error in the error column.

  15. Posted

    It's not possible to specify your own definition. Bug definition has already been established and noone (even you) can change it.

    Btw I can't understand that you don't understand that your solution will bring much more waste than current solution :P

    Yes it is possible to do this:

    For ease of writing this I have defined bug to mean several things.

    - "problem, issue, lack of technique, gap in technique"

    I could replace bug with "cookiemonster"

    I could replace all the instances of the word bug and replace it with "cookiemonster"

    and everyone who read my definition of a cookiemonster would understand what I meant.

    I will change at least change the titles in the opening post - everything else would greatly increase the word count. Remember this is an anal issue of Politics and so forth.

    Current situation

    Situation a. download will never complete in reasonable time.

    * Download with corrupted temporary file that is corrupted beyond repair by the client itself (StrongDC++)

    * beyond repair means it would take weeks or would never fix it. even going at 10 megabits a second and even if the download is small e.g. 50 megabytes.

    My solution

    - My solution would bring less waste.

    Solution 1. download is deleted or paused preventing waste.

    - If it is paused the user could "fix their machine" and come back and resume download.

    Solution 2. download has a chance of completing in much less time. by automatically restarting the download with a new temporary file.

    How could it possibly increase waste more than the current situation of it download the same chunk ad infinitum?

    At the moment the user has to manually detect it and re add the download item to the queue themselves.

    - Exactly what the automated technique would do.

    If solution 2. turns out to be problematic

    I would just stick with solution 1.

    a) Present the user with dialog box with which download queue item has corrupted temporary file that is almost certainly beyond repair by the client itself (StrongDC++)

    :D Pause the download allowing the user to "fix their machine" and come back later to resume the download.

  16. Posted

    just a definition:

    A software bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from behaving as intended.

    --------

    Excelsium is still trying to refer to some bug which (according to "bug" definition) doesn't exist. Everything in segmented downloading (except the crash), including the corruption definition, works as intended.

    In this case I'm defining bug as gaps in techniques/lack of techniques that leads to said waste that can be prevented with new techniques or additions to existing techniques.

    Perhaps I will remove bug from my opening post or include my definition of it.

    - Technically maybe this could be in the feature request/feature discussion forum.

    - Then maybe everyone will be happy.

    - The thread was originally in the feature request forum I guess it was a mistake to have it moved because it does include a (non related?) crash bug.

  17. Posted

    To Greg: I feel that in this case full defence is required, so that people dont get the wrong Idea of what I am saying - also for my own reference, defence for things like an out of context quote that I think tears my thread to shreds.

    If such things are not posted I will not have to make such defences.

    Since most possible defences have been posted, I can make a short reply and refer them to existing defences.

    I've said I will defend against/reply to every post someone makes that means

    I will reply to everyones post if I feel a reply is needed.

    Personally I think Its unfortunate if the thread is locked before my reply to the last reply I think needs a reply is posted but thats the way it goes.

    I can of course save that in a private document.

    I have this thread saved to disk.

    - I'm using this thread for personal reference.

    - If it becomes a problem it can be locked/whatever.

  18. Posted

    - I have broken my agreement to not 'bump' - this was a stupid thing to agree too.

    - I've moved my reply to Big Muscle below his reply by posting here.

    - If people post more replies I will reply in new posts - because its easier for me to manage and easier for me and others to read.

    - I dont care if people think I am spamming or trying to 'push this topic'.

    - Topic can be locked or deleted - also dont care - does not affect me personally.

    - On flaming? Disagree: I'm criticizing, pointing out facts, offering suggestions.

    - A segmented downloading technique should be used in most of the dc++ network to spread the upload bandwidth load, etc etc.

    automating the detection proccess which is currently manual - done by the user.

    no, it's not. Corrupted chunks are detected and redownloaded automatically.

    Quotes me out of context to what I was reffering to

    Quotes from my opening post.

    *2*. The user is not informed which temporary file is corrupted beyond repair by itself the client (StrongDC++).

    *2*. Continually observing the transfers window and making a *Guess* which download(s) is/are not going to complete successfully due to a corrupted temporary file for that download that is corrupted beyond repair by itself the client (StrongDC++).

    This is the manual process I was referring to and will automate.

    - the other solution he is reffering to is only an addition to this automated detection technique - a feature I may require and will be made by myself or someone else, clearly not by Big Muscle.

    He ignores my automated technique and just complains about a possible addition I may or may not add to my automated technique.

    - Of course the user can decide to enable or disable any one of these deciding whether THEY think they are required for them personally.

    - On the chance of missing to complete a file - well there are times obviously when the download will never complete. - When the corrupted temporary file is beyond repair by the client itself (StrongDC++)

    - It could be set to a high number such as if the same TTH corruption message spams the log 200 times.

    - I'm reffering to my techniques which I'm not asking Big Muscle to build anymore - I'm just continuing to discuss/defend them.

    - except of course TTH in the corruption message which will be built by him as he has said - this is a necessary addition that enables the rest of my techniques to be built.

  19. Posted

    Why are you pushing this issue? i without even reading the whole thing said straight up it wont be done, nor will the segmented be dropped. If i didnt know better dare i say you are spamming.

    - I'm not trying to "push this issue" anymore, I will patiently await Big Muscles feature release.

    1. I dont want the segmenting feature to be dropped.

    2. Big Muscle has said he is going to add the TTH to the corruption message.

    2.1. Hence I can build my own solution or have someone do it for me.

    and share it with others if they require it.

    I do not want to grow this thread anymore.

    If you need a defensive type reply from me.. chances are its already in here.

    Replies to Big Muscle

    Defence posted already.

    You can have the last post in the thread if you wish. Obviously my reply will probably be defence posted already.

    This is the last post of mine - any more defences will be posted in this post so that it will not bump the thread anymore.

    Also anything extra I have to say will be posted in this post as to not bump the thread.

    Big Muscle has already offered me what I'm looking for - Thanks Big Muscle.

    I can share my solutions with others as they require it.

    - That auto delete and re add to queue is just one of them a Possible extra feature

    to the main most important feature - automating the detection proccess which is currently manual - done by the user.

    My techniques are enabled by the TTH being in the corruption message.

    - I will add a name (or at least TTH) of corrupted file to "corruption detected" message.

    and that's all.

    I guess this is satisfactory since the user can open log and copy/paste > search for tth in queue.xml

    but if possible it should be made user friendly.

    It would be trivial to build something to notice a corruption message with same TTH is spamming the log and do something automated.. e.g. popup dialog box, pause download with that TTH in queue.xml or even delete and re add to queue. - maybe I'll do it myself if I cant find someone to do it.

  21. Posted

    if you don't have arguments against, you are trying to quibble. Hmm. Better don't say anything.

    I will write it in different words: THAT THING WON'T BE IMPLEMENTED BECAUSE IT WON'T HELP IN NEARLY ALL CASES. Now you understand it?

    Have you ever written a lot of source code??? If yes, then would know that something which would be useful in 1 of 100000 cases, is totally useless and it's no point in doing it.

    Btw just a personal question: You doesn't have more useful things to do than being all day in this forum and trying to force everyone to think that there is some bug in segmented downloading?

    Personal advice: If you, instead of being in this forum, try to find a cause of your corrupted files, then you won't need to write here anymore.

    - You've just said you'll hand out the key to do it (TTH in corruption message)

    *it - do something automated to prevent said waste.

    - I can of course do this myself, others can too.

    - Hence solution is found (when/if you release this "feature") - it took awhile to get there.

    - I don't respond to insults.

    - I will say this though.. slight repeat:

    I'm not trying to force anyone to think anything.

    My only goals of this thread were to:

    1. Prevent said waste caused by said gaps in said techniques.

    - Achieved by using another download technique.

    - I will use the current segmenting technique when the "TTH in corruption message" feature is released.

    2. Build an automated process of detection that replaces manual user detection.

    (Prevents said waste using current segmenting technique)

    - when the "TTH in corruption message" feature is released.

    - I may have this automated process do something extra like automatically restart download with new temporary file. (Optional or automated)

  22. Posted

    btw purpose of what I wrote and you didn't understand:

    if wouldn't have a bug in your PC then you wouldn't need any change in corruption detection routine.

    Law of error rates in the users hw/sw as stated in full already.

    - We dont live a perfect world where these errors don't exist.

    - Other users experience this

    - The more users there are, the more users who will experience this to a significant % (1-5%)

    - Therefore the more users who require the said gaps in said techniques filled.

    I hope I dont have to repost more.

    I have suggested techniques to fill these gaps

    - You have already accepted one of them (Change the corruption message).

    So solution:

    - When I find why it crashes, I will fix the crash.

    - I will add a name (or at least TTH) of corrupted file to "corruption detected" message.

    and that's all.

    It will not erase and readd the file, because in 80% it won't help and users will not only complain that it deletes their files. These clever TTH leaves verification has been made to redownload only corrupted parts and not whole file (which will be corrupted with same probability as the first downloaded file).

    Btw, if you read my first post to your topic, you will find that I said it can be caused by software error too (not only hardware). Like in the past, ZoneAlarm caused corrupted downloads which resulted in infinite "Rollback inconsistencies" messages (only with normal downloading, not for segmented downloading!) and noone complained! They just uninstalled ZoneAlarm and everything worked then.

    1. "because in 80% it won't help": There is absolutely no way you can be sure of that percentage. - 95-99.99999999% (estimate) of the users files download successfully.

    2.

    One option instead of just pausing the download after a set number of chunk redownloads:

    - If the corruption handling technique fails to repair a corrupt temporary file it should delete the download from the queue and re add it to the queue automatically. (Starts over with a new temporary file)

    - The user could be given this option when the corruption is detected or set it to do this automatically.

    - It is optional - the automated way being disabled by default, user is presented with dialog box.

    Example dialog box "The temporary file for your download "foo.text" has probably been corrupted beyond repair, Would you like to re download it?"

    - Even if the redownloading chunk bug caused by corrupted temporary file beyond repair bug happens in for example 1 in 100000 of all downloads - this would be useful. :whistling:

    3. Moved

    4. I have acknowledged the law of software error rates already.

  23. Posted

    so? for me shareaza worked fine while utorrent wasnt. the disk bug was still there, but didnt affect all applications.

    Its clear that segmented downloading and/or normal downloading did not create your problem, nor will you insinuate to the developers to drop segmented downloading by default. your error is most likely in filesystem, maybe you should ask microsoft about the corruption error, i presume you have one of the windows's installed.

    1. I'm not trying to "insinuate to the developers to drop segmented downloading by default".

    I am trying to get Big Muscle or someone else to fill in the gaps in the corruption handling techniques. (corruption handling techniques are incomplete resulting in said consequences)

    I guess I'm happy for the bugs to be reffered to as "gaps in the corruption handling techniques"

    2. again:

    - In this case only 1-5% of all files I download with the segmenting download technique have corrupted temporary files beyond repair of itself the client (StrongDC++)

    From what I can gather other users with this issue also experience it at 1-5%.

    I'm suggesting techniques such as "Delete and re-add to queue"

    In cases that the same chunk(s) have been redownloaded "too many times".

    - Slight repost: At the very least I'm requesting that the corruption message be changed - this has been accepted by Big Muscle, he hasn't said whether he will do it or not though.

  24. Posted

    I also did not read the whole thread, its like a licence agreement, nobody reads those. anyway. i recently had a similar problem with uTorrent and downloading, everything i downloaded was corrupted, even though i recheched and redownlaoded. checked my memory it was fine, checked hdd, was working fine except something crewed it up, most likely defragmantation. i dont know if it was a filesystem error, just disk blocks rewriting each other or whatever, but OS didnt read the files properly. only solution extended format of the disk and reinstall of OS. conclusion applications that used to work right didnt just go berserk and stop working right, its probabyl the same "bug" i had.

    I agree - reading just the rewording at the of the opening post and recent replies is enough to get a jist of the bugs.

    Also I have no visible problems or issues anywhere else in my system including other p2p applications such as eMule and Bittorrent (uTorrent) in this case.

    - In this case only 1-5% of all files I download with the segmenting download technique have corrupted temporary files beyond repair of itself the client (StrongDC++)

  25. Posted

    I thought it, but your posts show something different ^_^

    1. I don't share files I download until verified by myself (TTH + Subjective tests).

    2. Of course I will use a workaround to your bugs to prevent said waste.

    yes, it's the bug, but in your PC. We won't finish the file until all chunks are 100% correct.

    OK, let's say we stop redownloading after 10 tries. But what then? The only option is that you will delete the file from queue, because we don't let you to finish it with corruption.

    I'm only interested in fixing the crash during the download. You would be helpful if you have helped us to find the bug in code. And not only spread lies about bugs in segmented downloading.

    Denial that bugs exists - Of course others and I disagree.

    The bugs are listed in the opening post and elsewhere.

    I've given all my replies already before this post, its upto Big Muscle If he wants to coverup his bugs with endless denials.

    It probably doesn't matter what I say to Big Muscle now I think Big Muscle will do anything he can to 'cover it up'.

    Anyone new/returning to the thread.. just checkout my opening post, flames and XP2s threads in this forum.

    Sorry for respost of my earlier reply but heres where Big Muscle admitted something needs to be done.

    You are right only in one sentence - the corruption message should display also filename of corrupted file and maybe it will be changed to this way.

    This is nearly the entire point of this thread.

    I see you have acknowledged the user should be informed of which temporary files are corrupted - This is a critical thing. - This prevents the waste of the users time and his own and others resources. :whistling:

    Perhaps you have accepted the waste (see opening post) is not acceptable as I have?

    yes, it's the bug, but in your PC. We won't finish the file until all chunks are 100% correct.

    OK, let's say we stop redownloading after 10 tries. But what then? The only option is that you will delete the file from queue, because we don't let you to finish it with corruption.

    I'm only interested in fixing the crash during the download. You would be helpful if you have helped us to find the bug in code. And not only spread lies about bugs in segmented downloading.

    I forgot to add a point to the reworded version I made.

    One option instead of just pausing the download after a set number of chunk redownloads:

    - If the corruption handling technique fails to repair a corrupt temporary file it should delete the download from the queue and re add it to the queue automatically. (Starts over with a new temporary file)

    - The user could be given this option when the corruption is detected or set it to do this automatically.