#41
|
|||
|
|||
I have the latest Zonealarm Pro 9.3.037 and I have no problems with it.
Installed components: Firewall , OSFirewall Advanced Download Protection is not installed. |
#42
|
||||
|
||||
it is not about zonealarm in general. its about his issues caused by zonealarm or not. as many others have similiar issues randomly and they were caused by zonealarm, i just ask to remove za , reboot and try again and see if its solved.
__________________
JD-Dev & Server-Admin |
#43
|
||||
|
||||
Quote:
I turned it back on and downloaded some more files. They worked too. What does that prove? Nothing. No one can say if the problem is "solved" or not. This error occurs with low frequency, apparently randomly, I would have to do hundreds of downloads, and monitor them all carefully, to see if there was any difference. If the log doesn't give you enough information to work this out, what can? Quote:
You are ignoring the most important part of this report: it's not "CRC errors" , it's that the download stops at 32k before completion. How can that be due to an external process? Last edited by Gweilo; 13.04.2011 at 15:28. |
#44
|
|||
|
|||
Now I'm getting very disappointed. All people in this thread have had so much patience with you, but you still don't seem to understand the importance of the test and how it needs to be conducted.
In the past you claimed to have a scientific background. This means that you should have some insight in the way the scientific method and statistics operate. The experiment you conducted is totally irrelevant if the MTBF is 100 downloaded files or more. We don't even know your MTBF. I asked you why you don't want to un-install ZA, but you just ignored this important question. It shows a complete lack of respect for people who want to help you. |
#45
|
||||
|
||||
Holy Batman, so why there are no 100.000 users complaining about lost connection with 99,9% completed??
If it was a common problem - this thread quickly will grow to 1000 pages...
__________________
--------------------- Poradnik użytkownika jD - najczęściej spotykane problemy Instalatory JD2: http://jdownloader.org/jdownloader2 |
#46
|
|||
|
|||
this is happening quite too often these days
|
#47
|
||||
|
||||
Quote:
The error is rare, it can't be stimulated to "test" remedies,. Of course I don't know the MTBF. JD doesn't have a persistent log. I'd have to start carefully archiving all of them to work that out. But as I said in my first post, I guess it about 5%. But that's on a very short sample, it could be less often. The reason I started this thread was because I had a couple of similar errors the day before, so when it happened again I captured the log and made a report. Since JD was simply restarting the RS download without intervention, it could have been happening more often without my noticing (though it would have been in the log). However, other occasions, with Megaupload, it broke off at about the same 99.9% and reported a failure. The only "test" that would make any sense would be to run it for hundreds of downloads. Which is why I asked if there was a test group of small files I could try. I don't upload files, I don't have an account at any host. Otherwise, I'd have to do it for weeks running normal downloads. Quote:
1) You have given me no reason to believe ZA to be the problem. You fail to distinguish between the firewall-only freeware product I use and the "pro" suite; and that is a major difference. The firewall simply allows programs to connect or not, it does not analyse the data packets. It does not disconnect programs once they've been whitelisted, which javaw.exe obviously was long ago. 2) I'm not going to leave my PC connected, unattended, without a firewall. So I would have to find and configure a new one, which for me would take a few hours. Then I could spend a month doing this "test", accumulating logfiles. And if I did all that, would anyone actually act on it? Quote:
Not to mention this guy implying I made it all up: It isn't a "common problem". That's why it's difficult to diagnose. |
#48
|
||||
|
||||
your logfile also shows a lot of read-timeouts.
i can provide you direct http testlinks if you want so you can run tests on your side. but that may not help as the zonealarm users in the crc thread only had issues on rapidshare+zonealarm. so it might be limited to rs only in this case too. in case you have rs premium you can try all night long as there exists no more traffic limit.
__________________
JD-Dev & Server-Admin |
#49
|
||||
|
||||
Quote:
I've only noticed this error on RS and I think MU. A real stress test would be a few dozen RS links of a few MB each. I think RS would try to block me if I repeatedly got the same file. Does anyone know a forum where they post lots of smallish (less than 10 MB) files on RS? Presumably the read timeouts have something to do with making the error more likely. Local congestion probably. In that session I think a dozen or more other files downloaded correctly, as well as the retry of the failure. And still, there is the question of why the lethal failures occur in the last 32kb of the file. |
#50
|
||||
|
||||
32kb sounds like a typical buffer size, so any application which does *anything* with the datastream could cause this. i suggest get a rs premium account (unlimited traffic) and download as much files as you can find. filesize should not matter and you can even download the same file again and again (rs no longer has any revenue share system, so they dont care)
__________________
JD-Dev & Server-Admin |
#51
|
||||
|
||||
Quote:
|
#52
|
||||
|
||||
will provide a rs testlink tomorrow
__________________
JD-Dev & Server-Admin |
#53
|
|||
|
|||
I don't remember having had to configure anything with my firewall. Sygate just asks when an application wants to connect to the Internet and remembers your answer. It takes much less time to install than you need to write one post of this thread.
|
Thread Tools | |
Display Modes | |
|
|