Excelsium

Yes it is circumstance users with this circumstance will enable my technique. - We already have done manually - it will be automated.

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.

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.

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.

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. 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.

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: 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 ?

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 - 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.

iceman50: Have you just said you built some of the information solution I'm looking for ?? Sorry for misunderstanding.. 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 - As said hes already going to build part of it - TTH in the corruption message.. first enabling part.

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.

- 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.

- 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.

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.'

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.

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).

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.

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++) Pause the download allowing the user to "fix their machine" and come back later to resume the download.

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.

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.

- 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. 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.

- 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 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.

:thumbsup:

- 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)

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). 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. - 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.

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.

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++)