raspopov wrote:90% of network problems caused by connection/hardware errors - check network card connectors, try to ping some hosts for example "ping -t google.com", you can also test bandwidth by http://www.speedtest.net/ site etc.
Lanigiro wrote:2. There appears to have been a huge and recent drop in the total population of hubs alright. It's as if millions of peers suddenly cried out in terror, and were suddenly silenced. But by which evil empire? The RIAA, the MPAA, or someone else? The hubs also have fewer leaf connections, which suggests the hubs that survive are having problems staying online and keep crashing for some reason. Was an update pushed out for a popular client around that time? I know it's been longer since the last Shareaza version bump (184.108.40.206 -> 220.127.116.11).
Winterkeeper wrote:Those graphs are very interesting. So there's definitely something weird going on.Lanigiro wrote:2. There appears to have been a huge and recent drop in the total population of hubs alright. It's as if millions of peers suddenly cried out in terror, and were suddenly silenced. But by which evil empire? The RIAA, the MPAA, or someone else? The hubs also have fewer leaf connections, which suggests the hubs that survive are having problems staying online and keep crashing for some reason. Was an update pushed out for a popular client around that time? I know it's been longer since the last Shareaza version bump (18.104.22.168 -> 22.214.171.124).
The graphs from that site show there is a huge increase in hubs, not drop. Which would explain the average leaves per hub also dropping drastically. And, you can see this now when connecting to hubs. The hubs that can actually maintain the connection are usually close to max capacity like 299/300 or 1023/1024. The hubs that drop all the time are way below capacity, because they are not maintaining connections (I even see many close to zero - then they get lots of new leaves - then they start dropping them). But why? Initially I had the same thought as you - that someone might be trying to poison the network.
raspopov wrote:Very bad for you, hal.dll is a hardware abstraction layer, so your computer is broken.
raspopov wrote:For getting function names instead of ordinal numbers you'll need to use corresponding debug symbol files (*.pdb) or daily build (with built-in .pdb-files).
raspopov wrote:Anyway it's driver problem, btw antivirus and fierwall also has a driver.
Lanigiro wrote:This is getting frustrating. The other threads related to connectivity issues all have drifted off onto tangents, or become moribund. So let's address this head-on.
1. How do I make my copy of Shareaza stay connected to G2? That means, how do I make individual connections last a "normal" amount of time (tens of hours) without interruption, AND how do I make Shareaza replace lost connections AUTOMATICALLY and IN A TIMELY FASHION? I want it to replace a lost connection, by itself, in a maximum of 60 seconds. How do I make this happen? Note: a valid solution must not compromise other functionality, for example it must not make any potential file sources unavailable for the purpose of downloading files from them.
2. How do I make my copy of Shareaza stay connected to a specific ED2K server? If I have pending downloads from "push" sources on, say, eMule Security #1, I can only potentially get the files if I stay connected to eMule Security #1. But if I connect to a particular ED2K server and go to sleep, I usually wake up to find that it's been connected to the wrong server for six or seven hours, uselessly spinning its wheels and unable to progress on any of the files I want that are from push sources on the first server. And then it often refuses to reconnect to the original server even if I explicitly tell it to using the hostcache. This behavior is incorrect. The major ED2K servers are up 24/7, never full, and long term stable, unlike ephemeral G1 and G2 hubs, so Shareaza should NEVER drop its connection to one without being instructed to by me and Shareaza should NEVER fail to connect to one on demand. Yet it keeps doing so. How do I prevent this undesired behavior? It's MY copy of the software, running on MY computer, so I have the absolute right to prevent this undesired behavior. I just lack the exact knowledge of how to enforce correct behavior here. (And am puzzled as to why Shareaza comes configured OOTB to behave incorrectly in this regard, instead of Just Working(tm).)
3. How do I make Shareaza not require constant nursemaiding and frequent restarts? As I've previously noted, a) it (usually) won't reconnect to G2 without manual assistance and b) it sometimes starts refusing to connect to particular ED2K servers. The latter behavior does not seem to go away without restarting Shareaza completely. I don't want to nursemaid it. I don't want to restart it every few hours. I want to "set it and forget it" and have it gradually acquire the files on its download list without my having to do anything but leave the machine switched on and hooked up to the Internet. Now someone please tell me how to configure it so that I CAN just "set it and forget it" as described.
raspopov wrote:Does your computer gets BSOD often?
dew wrote:Okay, I've PM'd the error report to you. It took about 9 minutes for Shareaza to crash.
raspopov wrote:Looks like your Shareaza just overloaded by G2 packets, it spends many time in packet parsing code and incoming connections are dropped with "503 Busy" error.
raspopov wrote:Try latest daily build r9358 please.
Users browsing this forum: Google [Bot] and 1 guest