[Crash] Apex 0.4.0

[XP2 0]

I've also suddenly been getting this error .. everything was fine lastnight but then woke upto this problem & have been getting it every couple of hours now .. rebooting the system dont help --

Code: c0000005 (Access violation)

Version: 0.4.0 (2006-12-24)

Major: 5

Minor: 1

Build: 2600

SP: 2

Type: 1

Time: 2007-01-15 00:59:26

TTH: YBP45KNMY2PE64J2ZH7A77UJFMDBI4A4FN657VI

d:\cvs\apexdc++\apexdc\client\filechunksinfo.cpp(100): FileChunksInfo::addChunkPos

d:\cvs\apexdc++\apexdc\client\chunkoutputstream.h(64): ChunkOutputStream<1>::write

d:\cvs\apexdc++\apexdc\client\downloadmanager.cpp(692): DownloadManager::on

d:\cvs\apexdc++\apexdc\client\userconnection.h(411): UserConnection::on

d:\cvs\apexdc++\apexdc\client\speaker.h(68): Speaker<BufferedSocketListener>::fire<BufferedSocketListener::X<3>=0x05FBFE00,unsigned char *=0x05FBFEA8,int>

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(260): BufferedSocket::threadRead

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(528): BufferedSocket::run

d:\cvs\apexdc++\apexdc\client\thread.h(133): Thread::starter

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(348): _callthreadstartex

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(326): _threadstartex

Code: c0000005 (Access violation)

Version: 0.4.0 (2006-12-24)

Major: 5

Minor: 1

Build: 2600

SP: 2

Type: 1

Time: 2007-01-15 13:22:00

TTH: YBP45KNMY2PE64J2ZH7A77UJFMDBI4A4FN657VI

d:\cvs\apexdc++\apexdc\client\filechunksinfo.cpp(100): FileChunksInfo::addChunkPos

d:\cvs\apexdc++\apexdc\client\chunkoutputstream.h(64): ChunkOutputStream<1>::write

d:\cvs\apexdc++\apexdc\client\downloadmanager.cpp(692): DownloadManager::on

d:\cvs\apexdc++\apexdc\client\userconnection.h(411): UserConnection::on

d:\cvs\apexdc++\apexdc\client\speaker.h(68): Speaker<BufferedSocketListener>::fire<BufferedSocketListener::X<3>=0x00FDFE00,unsigned char *=0x00FDFEA8,int>

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(260): BufferedSocket::threadRead

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(528): BufferedSocket::run

d:\cvs\apexdc++\apexdc\client\thread.h(133): Thread::starter

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(348): _callthreadstartex

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(326): _threadstartex

Code: c0000005 (Access violation)

Version: 0.4.0 (2006-12-24)

Major: 5

Minor: 1

Build: 2600

SP: 2

Type: 1

Time: 2007-01-15 15:38:56

TTH: YBP45KNMY2PE64J2ZH7A77UJFMDBI4A4FN657VI

d:\cvs\apexdc++\apexdc\client\filechunksinfo.cpp(100): FileChunksInfo::addChunkPos

d:\cvs\apexdc++\apexdc\client\chunkoutputstream.h(64): ChunkOutputStream<1>::write

d:\cvs\apexdc++\apexdc\client\downloadmanager.cpp(692): DownloadManager::on

d:\cvs\apexdc++\apexdc\client\userconnection.h(411): UserConnection::on

d:\cvs\apexdc++\apexdc\client\speaker.h(68): Speaker<BufferedSocketListener>::fire<BufferedSocketListener::X<3>=0x05E3FE00,unsigned char *=0x05E3FEA8,int>

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(260): BufferedSocket::threadRead

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(528): BufferedSocket::run

d:\cvs\apexdc++\apexdc\client\thread.h(133): Thread::starter

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(348): _callthreadstartex

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(326): _threadstartex

Code: c0000005 (Access violation)

Version: 0.4.0 (2006-12-24)

Major: 5

Minor: 1

Build: 2600

SP: 2

Type: 1

Time: 2007-01-15 17:27:30

TTH: YBP45KNMY2PE64J2ZH7A77UJFMDBI4A4FN657VI

d:\cvs\apexdc++\apexdc\client\filechunksinfo.cpp(100): FileChunksInfo::addChunkPos

d:\cvs\apexdc++\apexdc\client\chunkoutputstream.h(64): ChunkOutputStream<1>::write

d:\cvs\apexdc++\apexdc\client\downloadmanager.cpp(692): DownloadManager::on

d:\cvs\apexdc++\apexdc\client\userconnection.h(411): UserConnection::on

d:\cvs\apexdc++\apexdc\client\speaker.h(68): Speaker<BufferedSocketListener>::fire<BufferedSocketListener::X<3>=0x05E3FE00,unsigned char *=0x05E3FEA8,int>

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(260): BufferedSocket::threadRead

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(528): BufferedSocket::run

d:\cvs\apexdc++\apexdc\client\thread.h(133): Thread::starter

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(348): _callthreadstartex

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(326): _threadstartex

Code: c0000005 (Access violation)

Version: 0.4.0 (2006-12-24)

Major: 5

Minor: 1

Build: 2600

SP: 2

Type: 1

Time: 2007-01-15 17:45:29

TTH: YBP45KNMY2PE64J2ZH7A77UJFMDBI4A4FN657VI

d:\cvs\apexdc++\apexdc\client\filechunksinfo.cpp(100): FileChunksInfo::addChunkPos

d:\cvs\apexdc++\apexdc\client\chunkoutputstream.h(64): ChunkOutputStream<1>::write

d:\cvs\apexdc++\apexdc\client\downloadmanager.cpp(692): DownloadManager::on

d:\cvs\apexdc++\apexdc\client\userconnection.h(411): UserConnection::on

d:\cvs\apexdc++\apexdc\client\speaker.h(68): Speaker<BufferedSocketListener>::fire<BufferedSocketListener::X<3>=0x03FEFE00,unsigned char *=0x03FEFEA8,int>

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(260): BufferedSocket::threadRead

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(528): BufferedSocket::run

d:\cvs\apexdc++\apexdc\client\thread.h(133): Thread::starter

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(348): _callthreadstartex

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(326): _threadstartex

Code: c0000005 (Access violation)

Version: 0.4.0 (2006-12-24)

Major: 5

Minor: 1

Build: 2600

SP: 2

Type: 1

Time: 2007-01-15 17:50:19

TTH: YBP45KNMY2PE64J2ZH7A77UJFMDBI4A4FN657VI

d:\cvs\apexdc++\apexdc\client\filechunksinfo.cpp(100): FileChunksInfo::addChunkPos

d:\cvs\apexdc++\apexdc\client\chunkoutputstream.h(64): ChunkOutputStream<1>::write

d:\cvs\apexdc++\apexdc\client\downloadmanager.cpp(692): DownloadManager::on

d:\cvs\apexdc++\apexdc\client\userconnection.h(411): UserConnection::on

d:\cvs\apexdc++\apexdc\client\speaker.h(68): Speaker<BufferedSocketListener>::fire<BufferedSocketListener::X<3>=0x03FEFE00,unsigned char *=0x03FEFEA8,int>

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(260): BufferedSocket::threadRead

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(528): BufferedSocket::run

d:\cvs\apexdc++\apexdc\client\thread.h(133): Thread::starter

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(348): _callthreadstartex

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(326): _threadstartex

Code: c0000005 (Access violation)

Version: 0.4.0 (2006-12-24)

Major: 5

Minor: 1

Build: 2600

SP: 2

Type: 1

Time: 2007-01-15 18:22:40

TTH: YBP45KNMY2PE64J2ZH7A77UJFMDBI4A4FN657VI

d:\cvs\apexdc++\apexdc\client\filechunksinfo.cpp(100): FileChunksInfo::addChunkPos

d:\cvs\apexdc++\apexdc\client\chunkoutputstream.h(64): ChunkOutputStream<1>::write

d:\cvs\apexdc++\apexdc\client\downloadmanager.cpp(692): DownloadManager::on

d:\cvs\apexdc++\apexdc\client\userconnection.h(411): UserConnection::on

d:\cvs\apexdc++\apexdc\client\speaker.h(68): Speaker<BufferedSocketListener>::fire<BufferedSocketListener::X<3>=0x06B0FE00,unsigned char *=0x06B0FEA8,int>

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(260): BufferedSocket::threadRead

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(528): BufferedSocket::run

d:\cvs\apexdc++\apexdc\client\thread.h(133): Thread::starter

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(348): _callthreadstartex

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(326): _threadstartex

Code: c0000005 (Access violation)

Version: 0.4.0 (2006-12-24)

Major: 5

Minor: 1

Build: 2600

SP: 2

Type: 1

Time: 2007-01-15 18:23:41

TTH: YBP45KNMY2PE64J2ZH7A77UJFMDBI4A4FN657VI

d:\cvs\apexdc++\apexdc\client\filechunksinfo.cpp(100): FileChunksInfo::addChunkPos

d:\cvs\apexdc++\apexdc\client\chunkoutputstream.h(64): ChunkOutputStream<1>::write

d:\cvs\apexdc++\apexdc\client\downloadmanager.cpp(692): DownloadManager::on

d:\cvs\apexdc++\apexdc\client\userconnection.h(411): UserConnection::on

d:\cvs\apexdc++\apexdc\client\speaker.h(68): Speaker<BufferedSocketListener>::fire<BufferedSocketListener::X<3>=0x06B0FE00,unsigned char *=0x06B0FEA8,int>

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(260): BufferedSocket::threadRead

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(528): BufferedSocket::run

d:\cvs\apexdc++\apexdc\client\thread.h(133): Thread::starter

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(348): _callthreadstartex

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(326): _threadstartex

so i thought i'll go back to useing version 0.3 .. but still getting it --

Code: c0000005

Version: 0.3.0 (2006-11-12)

Major: 5

Minor: 1

Build: 2600

SP: 2

Type: 1

Time: 2007-01-15 19:47:23

TTH: HMG7SFF6MHOSHQMZI6IRCYSXTEFITXI4ET5276Y

d:\cvs\apexdc++\apexdc\client\filechunksinfo.cpp(403): FileChunksInfo::verify

d:\cvs\apexdc++\apexdc\client\filechunksinfo.cpp(1050): FileChunksInfo::verifyBlock

d:\cvs\apexdc++\apexdc\client\downloadmanager.cpp(687): DownloadManager::on

d:\cvs\apexdc++\apexdc\client\userconnection.h(413): UserConnection::on

d:\cvs\apexdc++\apexdc\client\speaker.h(68): Speaker<BufferedSocketListener>::fire<BufferedSocketListener::X<3>=0x0410FE00,unsigned char *=0x0410FEA8,int>

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(260): BufferedSocket::threadRead

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(528): BufferedSocket::run

d:\cvs\apexdc++\apexdc\client\thread.h(134): Thread::starter

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(348): _callthreadstartex

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(326): _threadstartex

Code: c0000005

Version: 0.3.0 (2006-11-12)

Major: 5

Minor: 1

Build: 2600

SP: 2

Type: 1

Time: 2007-01-15 21:00:23

TTH: HMG7SFF6MHOSHQMZI6IRCYSXTEFITXI4ET5276Y

d:\cvs\apexdc++\apexdc\client\filechunksinfo.cpp(100): FileChunksInfo::addChunkPos

d:\cvs\apexdc++\apexdc\client\chunkoutputstream.h(64): ChunkOutputStream<1>::write

d:\cvs\apexdc++\apexdc\client\downloadmanager.cpp(679): DownloadManager::on

d:\cvs\apexdc++\apexdc\client\userconnection.h(413): UserConnection::on

d:\cvs\apexdc++\apexdc\client\speaker.h(68): Speaker<BufferedSocketListener>::fire<BufferedSocketListener::X<3>=0x058CFE00,unsigned char *=0x058CFEA8,int>

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(260): BufferedSocket::threadRead

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(528): BufferedSocket::run

d:\cvs\apexdc++\apexdc\client\thread.h(134): Thread::starter

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(348): _callthreadstartex

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(326): _threadstartex

1 thing i have noticed on restarting the client in the status messages there's things saying "Corrution detected at position ..." and a range of numbers ... when the client crashes it might be screwing up 1 of the xml files but they look ok to me ... & i hope i dont have to wipe & reinstall the client as having to rehash 1.03TB of files aint a fun thing

Right .. found out what my problem was ... its the file [DB]_Naruto_216_[C9B6D4F2].avi

TTH : KWZX77RERY4RDPSR5QJBQJYVBMXG5YQX6QVJDIY .. although this IS a valid file there's a problem with checksums on part of the download .. everytime i try to download this file i crash , and other peeps in the hubs i use have mentioned other files doing this ... so thats going to be a hard one to sort out

[Zlobomir 3]

Just noticed it is different from http://forums.apexdc.net/index.php?showtopic=1302 , so split.

[Excelsium 0]

I have this exact same problem - is there anyway to download these problem files? someone has made a patch or workaround? or?

I have attached my crash report and included a bit of it here;

Always the same error recurring on same few TTHs.

Code: c0000005 (Access violation)

Version: 0.4.0 (2006-12-24)

Major: 5

Minor: 1

Build: 2600

SP: 2

Type: 1

Time: 2007-03-19 04:42:30

TTH: YBP45KNMY2PE64J2ZH7A77UJFMDBI4A4FN657VI

d:\cvs\apexdc++\apexdc\client\filechunksinfo.cpp(100): FileChunksInfo::addChunkPos

d:\cvs\apexdc++\apexdc\client\chunkoutputstream.h(64): ChunkOutputStream<1>::write

d:\cvs\apexdc++\apexdc\client\filteredfile.h(137): FilteredOutputStream<UnZFilter=0x02961018,1>::write

d:\cvs\apexdc++\apexdc\client\downloadmanager.cpp(692): DownloadManager::on

d:\cvs\apexdc++\apexdc\client\userconnection.h(411): UserConnection::on

d:\cvs\apexdc++\apexdc\client\speaker.h(68): Speaker<BufferedSocketListener>::fire<BufferedSocketListener::X<3>=0x03FAFE00,unsigned char *=0x03FAFEA8,int>

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(260): BufferedSocket::threadRead

d:\cvs\apexdc++\apexdc\client\bufferedsocket.cpp(528): BufferedSocket::run

d:\cvs\apexdc++\apexdc\client\thread.h(133): Thread::starter

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(348): _callthreadstartex

f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c(326): _threadstartex

exceptioninfo.txt

[Big Muscle 1]

When does this exactly happen? I'm trying to fix this crash for a long time but without success

My betatester was running the last beta version of StrongDC++ for 5 weeks without any crash/hang. But after these 5 weeks it crashed with this exceptioninfo :(

[Excelsium 0]

@Big Muscle: As far as I know It happens only when downloading those few problematic files, It occurs at random intervals whilst these problematic files are running, downloading the same chunk of the file over and over again, crashing after downloading the same chunk maybe 10 times or 100 times.

I have tried these same files in all segmenting clients I know of - always fails.

Tried these files in plain vanilla DC++ with no segmenting and it worked first time, no corruption messages, no crashes. Small possibility remains that there is a few problematic users on the hub and downloading from them with segmenting or regular client hoses the download and causes crash and that they were all offline when I tested with regular client and thats why they all worked, doubt it though.

Update: Incase you havn't encountered some problem files for testing here are some examples:

search " mushishi 03 .a" and get file with TTH: HBBAHIWV56PEJQD5H6S6J4WAFQ2J3ELRNYBMJUA magnet:?xt=urn:tree:tiger:HBBAHIWV56PEJQD5H6S6J4WAFQ2J3ELRNYBMJUA&xl=189263872&dn=%5BC1%5DMushishi_-_03%5BXviD%5D%5BF334DBDF%5D.avi

search " ghost in the shell 24 .a" and get file with TTH: FY6T6IN2MEZCXWCNDL6HMAWP4HX6I2RRXRNBY2Y

magnet:?xt=urn:tree:tiger:FY6T6IN2MEZCXWCNDL6HMAWP4HX6I2RRXRNBY2Y&xl=186181632&dn=Ghost+in+the+Shell+-+Stand+Alone+Complex+-+24+%5BLMF%5D.avi

hubs with these files:

testhub.otaku-anime.net:555

public.otaku-anime.net:555

walhalla.otaku-anime.net:555

shinto.total-anime.net:666 (requires registration to search)

[XP2 0]

the only way i found to work around this problem is to get the file via torrents ... not much help for DC ..

[Excelsium 0]

I'm still not having any problems with the regular dc++ client, is there a way to force selected files to have only one segment, will you add this feature if its not there and that is if this bug is not completly fixed.

although maybe its not a bug in segmenting but a bug elsewhere in the download process, but we wont know until we test with single segment downloading.

Otherwise I'm forever stuck using regular dc++ client because of those 3-5% of files that fail in apex, strong & revconnect.

Also the client should tell you exactly what file the corruption is detected rather than the "corruption detected at position" and having to observe the transfers and find the one thats downloading the same chunk repeatedly

then at least I could continue using the client by queuing those quickly identified corrupted files in regular dc++, it would take way too much time otherwise.

Update: Settings>Downloads>Queue>Manual number of segments "1" works to set new downloads to single segment I'll report back results later.

Idea: If the client can detect which file is corrupting then it could for example pause the file to prevent crashing or automatically erase and re add the file in single segment mode.

[Big Muscle 1]

At the weekend, I'll try to reproduce the crash and will try to fix it.

[Excelsium 0]

Great. Single segment downloads are giving the same corruption messages - no problem in regular DC++.

[Big Muscle 1]

Does it do a mess for all users or only if the segment is downloaded from one certain user?

Have you tried downloading other big file if it downloads ok?

[Excelsium 0]

Does it do a mess for all users or only if the segment is downloaded from one certain user?

Have you tried downloading other big file if it downloads ok?

1. Once "corruption is detected at positon" the download always fails from all sources, even with files with over 150 sources (users).

2. I download about 50 files a day all of those are in the 100mb-300mb range, 3-5% fail as said above.

[Big Muscle 1]

The crash must be caused by that corruption. But that corruption must be caused by some failure in your PC.

[Excelsium 0]

The crash must be caused by that corruption. But that corruption must be caused by some failure in your PC.

DC++ regular client is working (sucessfully completes all downloads) with these problem files and ALL other files without corruption messages so I have to disagree, I have zero problems with other segmenting download: http, bittorrent or anything else at all on this PC.:

So can you elaborate in full detail please on why you are so certain it "must be caused by some failure in your PC"? Obviously your claim cannot be proven or disproven until there is Lots of results from lots of testing, you havn't yourself yet, correct?

To those affected: My workaround for this is to run plain DC++ alongside strong/apex, delete the problem files from strong/apex queue and add them to your dc++ - temporarily disconnecting from hubs in strong/apex and connecting to hubs in dc++ until the strong/apex problem files complete sucessfully and then disconnect from hubs in dc++, connect to hubs in strong/apex

[Zlobomir 3]

My theory: SDC checks TTH on the fly, I was fighting with a similar case before, although not big files. And after getting the video file via HTTP and running a fixing program over it - a miracle, it was transferring Apex to Apex. btw, before fixing, I was having a still picture from it.

So, if I am right, and if this "bug" prevents from spreading crappy files over the peers, be it!

[Excelsium 0]

If your theory is correct then there needs to be a way of disabling it since Its having false positives on corruption detection or better yet, fix it.

Either way

I tested (downloaded) a set of known "problem" files in Strong and Apex - all fail

I tested (downloaded) the exact same set of files in regular DC++ in the same hubs from the same users - all succeed and are perfect copies of the files. - I have even checked the TTHs against files that are available on bittorent and have downloaded with bittorent.

So you think my perfect copy is "crappy" eh? what a joke.

And this testing continues

My Conclusions so far: any file that fails to download in strongdc also fails in apex but suceeds in regular dc++ (and is a perfect copy).

Thank goodness for the regular dc++ client - I'll download whatever files I want thankyouverymuch.

[Big Muscle 1]

DC++ regular client is working (sucessfully completes all downloads) with these problem files and ALL other files without corruption messages so I have to disagree,

DC++ and SDC+/ApexDC++ are completely different applications:

a) DC++ checks TTH tree only and does something during resume, so there's only minimum chance to figure out that the file is corrupted

StrongDC++ has different download techniques than DC++. It means that StrongDC++ accesses different HDD/memory areas, so it can walk into some corrupted part in different time than DC++.

[Zlobomir 3]

If it is a program fault, it MUST be sorted. But if my theory is right (and you are just downloading crap, except when you use SDC/Apex), I am very happy. You can download what you want, unfortunately there are many as you, some of them will reshare the crap, and we all will end in crap.

IF I am right with this explanation, it is like not supporting NMDC filelists - just for good.

[Excelsium 0]

DC++ and SDC+/ApexDC++ are completely different applications:

a) DC++ checks TTH tree only and does something during resume, so there's only minimum chance to figure out that the file is corrupted

StrongDC++ has different download techniques than DC++. It means that StrongDC++ accesses different HDD/memory areas, so it can walk into some corrupted part in different time than DC++.

Thanks we got to the bottom of it: There are solutions

- "Fix" StrongDC++'s download techniques.

- Include the standard DC++ download techniques as an option. (I'd like this to be done anyway as a backup)

Ideal solution as said above I think - if you cannot fix strongs techniques:

Detect corrupted file when it says "corruption detected at position" then erase the file and temp file then Re add it and start again using standard DC++ download techniques

Detecting the corrupt file would be easy - just see which one is downloading the same chunk over and over.

[Excelsium 0]

If it is a program fault, it MUST be sorted. But if my theory is right (and you are just downloading crap, except when you use SDC/Apex), I am very happy. You can download what you want, unfortunately there are many as you, some of them will reshare the crap, and we all will end in crap.

IF I am right with this explanation, it is like not supporting NMDC filelists - just for good.

These files people are sharing are clearly not corrupt or garbage data since I have watched them all the way through without any problems whatsoever (DivX,Xvid Avi files) and have checked the TTH against the bittorrent release where possible.

Maybe your trying to touch another topic here - "Crap" is a matter of taste. I dont want censorship in my P2P client software thanks.

[Big Muscle 1]

If it is a program fault, it MUST be sorted.

The crash is the program fault, but the file corruption is some other HW/SW failure

[Big Muscle 1]

Thanks we got to the bottom of it: There are solutions

- Include the standard DC++ download techniques as an option. (I'd like this to be done anyway as a backup)

- "Fix" StrongDC++'s download techniques.

a) it's already there

yes, I will fix the crash. But you will still get messages about corruption until you fix the problem in your PC.

[Excelsium 0]

The crash is the program fault, but the file corruption is some other HW/SW failure

Strong could be modified or features added so it dosn't corrupt files - fact.

[Excelsium 0]

a) it's already there

yes, I will fix the crash. But you will still get messages about corruption until you fix the problem in your PC.

I have tried "Manual settings of number of segments set to "1" and had the same problems.

But I don't think I've tried "Enable multi source" set to "disabled".

I'll come back with the results later.

If this works then I'd like my "Detect and switch technique" idea to be added to Strong, if you really feel you cannot fix the corruption any other way.

[Zlobomir 3]

No, by "crap" I meant just corrupted. Regardless of playing files, please run f. ex. All Media Fixer on them. If there are no errors, I am ready to look at this again. :P

[Excelsium 0]

I've finished testing "Enable multi source" set to "disabled".

Good news: No corruption messages or crashing.. all downloads completed and are perfect as tested against Bittorrent releases - remember they all fail in segmenting mode.

Problem solved I guess - I no longer have to use regular DC++ alongside strongdc or apex to catch its segmenting failings.

I'm hoping that someone builds a Detect and switch feature as I described in full earlier so others and I could use segmenting mode - Or builds a segmenting technique that is 100% instead of 95-99%

The DC++ segmenting problem has been around for years - I had the same issues in RevConnect (another segmenting DC++ client). But only recently bothered to do anything about it since the amount of files I transfer has been steadily rising.

I have changed PCs, reformatted etc several times during that period.