Corrupted DL files - anyone else having problems?

Forums › Off topic › Corrupted DL files - anyone else having problems?

DS248

1702 posts

Uber Geek
+1 received by user: 771

Lifetime subscriber

#60253 22-Apr-2010 22:47

TCL cable Wellington (10Mbs/50GB plan)

I occasionally DL large zip files (eg. 23 folders/subfolders, 220 files, ~1GB) from a private website hosted ex 1&1 (in US?). (Website primarily used for transfer of large 'data' files). The files are uploaded by work colleagues in the US. Generally I use FDM to minimise DL time (~15min).

A few weeks ago, for the first time I got a CRC error while attempting to extract one of the included files after DL. Error message indicated a ~4bit(byte?) discrepancy in the file size. I re-downloaded the file & extracted all files from the second DL without problem.

I encountered a similar problem this morning (only 1 / 220 files affected), but this time the second attempt at downloading the zip, also resulted in a CRC error, this time in a different file. Fortunately by combining the two, I managed to patch together a complete file set. Did not fancy yet another 1GB DL.

Question is, has anyone else (on TCL cable or otherwise) noticed any, or an increase in errors in files downloaded from international sites?

soleil24

124 posts

Master Geek
+1 received by user: 1

#322275 24-Apr-2010 00:40

I had a similar problem last year, first evident downloading Linux patches/packages (inbuilt crc checking) but then obviously affecting all kinds of d/l. (cable in Kapiti - I think there is a thread somewhere here referring to it, I'll see if I can find it again !). Tried all sorts of different source mirrors to rule out a corrupt source then when I started to see random Win d/l's from all over showing up broken, knew it wasn't source.

Also made sure my network was clean, same problem across different PCs, even swapped out my router to eliminate. Provided traces (wireshark, etc) as well as examples of hex-compared files for TCL to look at.

Finally tracked down to "faulty equipment" - never did find out exactly what, but I suspect was a dodgy routing interface, and further suspect it was closer to my end of TCL's network and not upstream (otherwise would have expected it to affect more end users).

TCL tech support were pretty good in chasing it down even if it did take a few weeks, so if you can get past first line and speak to one of the techs who knows stuff <g>. Don't think they are despatching field engineers from Manilla yet so shouldn't need to wait too long

If it's only one source causing the errors though isn't the problem more likely to be at the remote end or did I misunderstand?

If I did misunderstand and the problem does seem similar to mine then can probably dig out the fault ticket and you can provide them with that, just in case they don't use a knowledge-base system to avoid re-inventing the wheel with every fault...

And probably be better posted under TCL - hardly "off-topic"

IG

DS248

1702 posts

Uber Geek
+1 received by user: 771

Lifetime subscriber

#322277 24-Apr-2010 01:07

Thanks for the details. Will follow up in more detail if I encounter this again. Son said he recently had a similar problem (from a different source).

Put under "Off Topic" as I figured FDM was also a potential source of the problem.

But I agree - TCL forum may have been a better choice?

wazzageek

1095 posts

Uber Geek
+1 received by user: 108

ID Verified

Trusted

Lifetime subscriber

#322298 24-Apr-2010 08:50

I've had a similar problem a few years back on Telecom ADSL.

Larger files would download with a different MD5 each and every time.

It took a while to talk through with Telecom helpdesk, including testing on a different line, using three different modems.

Finally got to speak to someone who requested a port change at the exchange. Following that there was absolutely no problem.