Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[D4rKiTo]

Hello.
I'm using this version:
Package: amule-daemon
Version: 1:2.3.2-5
Kad: ON
High ID

Problem: File downloads some megabytes and then is on queue for hours.


If I download the same file with emule 0.50a on Windows there is no queues. File completes in 2-3 minutes.

What's the problem?
Thanks. Have a nice day.

[NHLbaxter]

I'm having the exact same problem. I can easily recreate it running amule on multiple machines and sharing a file on one, downloading on the others.

Client A is sharing the file, B, C, D are downloading it. When adding the ed2k Link on B-D, they immediately start downloading a couple MB, then switch to "On Queue".
Client A isn't uploading anything at that point.
Clients B-D eventually also find each other and fetch a couple of MB from each other, then consider each other "On Queue" as well, even if the other peers still have chunks that they don't have themselves.

What's notable here is that for example, client B considers itself "On Queue" at client C, but client C says "Upload status" is "none" in "Shared files" view for client B. Both have an up-to-date view of the available chunks of the other peer. Client C knows that it have chunks that client B needs, but nothing is happening. I have 4 clients with unlimited upload speed idling around.

Unfortunately this means aMule is completely broken for my use case. Maybe it works if you only up/download popular files with many peers, but releasing a new file with aMule would take weeks even on a GBit link like this.

[hypervelocity]

Yeap, amule has always been like this for me. "On queue" when it should be downloading. But I also get amule sticking on "Asking", and mostly "Connecting" (when the source really is there).

Seen the preceding behaviour too? Top pane might be showing a download speed, but the status bar can say zero (or much less, or figure dropping). Soon the client will change to show "On Queue".

I have found restarting the client can make it jump back into life, but it is nothing very reliable - but enough of an edge that a download that should take an hour or so I can get done in a week. I have automated the restarting, watching data transfer rates, killing and restarting amule if it gets too low.

But sometimes amule will just forget about sources between executions of the client, and so I also manually manage the downloads in a text editor. If I get a source I type the IP:port into the text editor, copy the ed2k link from amule to the editor, and make an ed2k link containing the source IPs. That way I can just copy/paste links back into amule, and whilst amule will say that I am trying to download something already it does immediately add the source IP. The slow network does not have to be waited for.

It also seems that amule will write-off an IP as a valid source and just refuse to connect after a period of these failed connections. Unless the client restarted and informed of a source with an ed2k link.

I have had these connection stalls behind double NAT'd, mobile phone network tethered, LowID instances of amule. But also on a machine directly 'net facing, no NAT, proper routed IP, with a HighID. I think I have seen two of my clients also failing to communicate when they should be.

I have played with bandwidth settings, giving next to no bandwidth, too much, just below the line max, all sorts.... still the same. But one thing, maybe amule is a bit more reliable is if the line is busy otherwise, torrents or DC++ transferring mostly, so higher-latency? And if a speed limit is low then perhaps it will take a while longer before a download stops, but I am not sure that is predictable.

The bugs seem to be so reliably unreliable that even watching amule is scary. Is doing something in the UI causing this? Is leaving it alone doing something? Is there a feature on that I don't really need, that could be turned off to stop the bug being triggered? I feel I have played with every setting, sacrificed far too many animals across the keyboard, but no progress. Not even significantly pinning down what can trigger the bug to happen, let alone what can be done to not trigger it. If it is user-related, at all.


Also, amule will crash if the network gateway likely says destination net unavailable. If my tethered phone drops its connection, or is disconnected from the gateway machine, then amule will crash quite quickly.


I have been trying to search for this bug for a long time now. Had a dabble with ed2k back when ed2k was one of many burgeoning networks, but only a few years ago did I have another look and find amule. Torrents can still burst into life with patience, but keeping P2P options open makes sense.

Had this problem on Debian Stretch 32 bit, from main or contrib repo (not backports). This machine is offline right now. My P2P virtual machine was Stretch 64 bit, with the stalling problem. Now Debian Buster 64 bit, with amule 2.3.2.

I have wondered if this is something to do with Linux's NAT connection tracking? Or if amule is fickle over packet order or loss? How it crashes when a network is unavailable, or vanishes, could well be a sign that less than perfect network conditions are not handled well overall. What we are seeing could be a symptom of this.

And damn, the captchas on this site are difficult. I'm starting to think maybe I am a bot?

[stryder]

Same problem, running version 2.3.2 on BananaPiPro with Armbian Debian linux
no bandwidth problem dowloading torrents or files via http or ftp

Downloading same files with aMule on a widnows pc connected to same netowrk works fine