Never-ending eMule queue?
Posted: 04 Sep 2012 07:29I have an eMule download that never starts, being permanently queued. Over time the queue position goes down until it's near zero, then jumps up to over 2000 again, without the file ever actually downloading.
I'm using Shareaza 2.6.0.0, the latest version.
Here are the relevant entries from the Network tab for the last time it jumped back to the back of the queue:
[00:59:14] Download host 209.104.xxx.xxx is busy, waiting in queue at position #95 of 0 ("").
[01:27:55] Download host 209.104.xxx.xxx is busy, waiting in queue at position #79 of 0 ("").
[01:56:35] Download host 209.104.xxx.xxx is busy, waiting in queue at position #56 of 0 ("").
[01:59:27] Accepted an incoming connection from 209.104.xxx.xxx port 59577.
[01:59:28] Incoming connection from 209.104.xxx.xxx is an eDonkey client link.
[01:59:28] Download connection to 209.104.xxx.xxx established.
[01:59:28] Requesting download fragment (92160-126082) of "FILENAME.REDACTED" from 209.104.xxx.xxx.
[01:59:28] Requesting download fragment (0-92160) of "FILENAME.REDACTED" from 209.104.xxx.xxx.
[01:59:28] Download host 209.104.xxx.xxx is busy, waiting in queue at position #2459 of 0 ("").
[02:00:10] eDonkey client connection to 209.104.xxx.xxx was closed.
What is causing this and what do I need to do to fix it? I have had other eMule downloads complete successfully, the last just a few hours ago, so it's not protocol interference by my ISP or a misconfiguration at my end that renders eMule completely unusable to me. It may be a configuration issue that causes incompatibility with specific other clients, however.
In this instance, the client identifies itself as eMule 0.50a and is using a high port number (not 6346 or anything else that might be targeted by my ISP). My own port number is likewise high (and, again, lets me get eMule downloads from other clients).
The odd thing is, a source I've recently successfully downloaded several files from is also identifying itself as eMule 0.50a. So either something's wrong on my end that affects a specific item in my download list, or else not all eMule 0.50a sources are created equal. (Neither is a push source, by the way, and I have highID. So far as I know, having highID and the source also having highID should nearly guarantee that everything works. Apparently only "nearly", though.)
I'm using Shareaza 2.6.0.0, the latest version.
Here are the relevant entries from the Network tab for the last time it jumped back to the back of the queue:
[00:59:14] Download host 209.104.xxx.xxx is busy, waiting in queue at position #95 of 0 ("").
[01:27:55] Download host 209.104.xxx.xxx is busy, waiting in queue at position #79 of 0 ("").
[01:56:35] Download host 209.104.xxx.xxx is busy, waiting in queue at position #56 of 0 ("").
[01:59:27] Accepted an incoming connection from 209.104.xxx.xxx port 59577.
[01:59:28] Incoming connection from 209.104.xxx.xxx is an eDonkey client link.
[01:59:28] Download connection to 209.104.xxx.xxx established.
[01:59:28] Requesting download fragment (92160-126082) of "FILENAME.REDACTED" from 209.104.xxx.xxx.
[01:59:28] Requesting download fragment (0-92160) of "FILENAME.REDACTED" from 209.104.xxx.xxx.
[01:59:28] Download host 209.104.xxx.xxx is busy, waiting in queue at position #2459 of 0 ("").
[02:00:10] eDonkey client connection to 209.104.xxx.xxx was closed.
What is causing this and what do I need to do to fix it? I have had other eMule downloads complete successfully, the last just a few hours ago, so it's not protocol interference by my ISP or a misconfiguration at my end that renders eMule completely unusable to me. It may be a configuration issue that causes incompatibility with specific other clients, however.
In this instance, the client identifies itself as eMule 0.50a and is using a high port number (not 6346 or anything else that might be targeted by my ISP). My own port number is likewise high (and, again, lets me get eMule downloads from other clients).
The odd thing is, a source I've recently successfully downloaded several files from is also identifying itself as eMule 0.50a. So either something's wrong on my end that affects a specific item in my download list, or else not all eMule 0.50a sources are created equal. (Neither is a push source, by the way, and I have highID. So far as I know, having highID and the source also having highID should nearly guarantee that everything works. Apparently only "nearly", though.)