![]() |
|
#1
|
||||
|
||||
|
I have extremely solid evidence that there is a defect in nod32 (v5 and v6beta) protocol filtering. When it is on, better than 50% of the daily downloads that I do of large video podcasts end up corrupted (unable to play all the way through in Windows Media Player). With it off, it doesn't happen.
I studied the nature of the corruption by re-downloading a corrupted file until I got a copy that played through to the end with no problem. Then I compared the two (byte by byte). The bad file was exactly 8,192 bytes shorter than the good one. Further, the two files were identical up to a specific offset (call it X, about halfway through the nearly 1GB file). At that point there was an 8K block of data in the good file that was not in the bad. After that point, the data in the good file exactly matched the remaining data in the bad file after offset X. The bottom line is an 8K block of data got lost somewhere. This happens more frequently the larger the file is (though I have observed it affecting smaller files as well, just not as often). This all began happening sometime within the last month or so. Prior to that I had never had any unplayable video files in over several years of downloads. How can I help to collect diagnostic information that Eset can use to help find and fix this problem? -- bc |
|
#4
|
||||
|
||||
|
Quote:
-- bc |
|
#5
|
||||
|
||||
|
Quote:
I've disabled the http protocol filter and the problem is gone. Is this the recommended workaround? Do you have any confidence that MS will fix this? I am uncomfortable running without the http filter ... -- bc |
|
#6
|
|||
|
|||
|
Quote:
|
|
#7
|
||||
|
||||
|
Quote:
-- bc |
| « Previous Thread | Next Thread » |
| Thread Tools | Search this Thread |
|
|