Print

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

[davem]

It's possible there is something I am not understanding and this isn't a bug but we will see. 

Amule version: 2.3.1 (Running on Gentoo Linux)

FileHigh = Manually set to high priority
FileLow = Manually set to low priority

Requesting both files From Remote Client running eMule v0.50a.

Current status for Downloads from above remote client:

FileHigh = Asked For Another File (FileLow)
FileLow = No Needed Parts

1. Shouldn't FileHigh be requested first normally due to the higher priority?
2. Since FileLow is "No needed parts" wouldn't that be another reason to Download FileHigh instead?

What am I missing?

Notes:

1. No downloading file is currently set to auto.
2. I like to manually change priorities over time and have done so but the client has been running for over 24h since the last manual change.

[GonoszTopi]

Amule version: 2.3.1 (Running on Gentoo Linux)

FileHigh = Manually set to high priority
FileLow = Manually set to low priority

This is the upload priority of the files on the sharer side, as much as I understand, right?

Requesting both files From Remote Client running eMule v0.50a.

Current status for Downloads from above remote client:

FileHigh = Asked For Another File (FileLow)
FileLow = No Needed Parts

And this is the download status of them on the requester side.

1. Shouldn't FileHigh be requested first normally due to the higher priority?

No, unless you set their download priority as such. Since you didn't say anything about their download priority, I assume they're equal. The downloader doesn't know what is the upload priority of the requested file on the other side. (And telling it to the downloader wouldn't make any sense, since it requests only one file, and it's impossible to tell which has the highest upload priority before the request itself.)

2. Since FileLow is "No needed parts" wouldn't that be another reason to Download FileHigh instead?

Yes, that's a reason to switch to the other file. But note there's a minimum time that has to be elapsed between two file requests (reasks). There was a bug in older eMule clients that could be exploited by reasking for files very often to achieve better queue position. Current clients will mark every client with too low reask times as a bad guy and ban them.

What am I missing?

Notes:

1. No downloading file is currently set to auto.
2. I like to manually change priorities over time and have done so but the client has been running for over 24h since the last manual change.

As far as I see, your client asked first for FileLow and found out there aren't any needed parts. Now it knows it could ask for FileHigh, but asking immediately would make it banned, so it has to wait.

[davem]

GonoszTopi, thank you very much for the reply and explanation.

I should have specified that this is only the download priorities.  In fact I didn't even know amule had a way to adjust upload priorities but I see that now. <embarrassed> 

I was not aware of the issue with request intervals triggering bans.  Initially after reading your reply I had thought that this likely explained it but now after starting my client again after a break >24h I seem to be noticing the same exact behaviour as described.  I will investigate further to see if I can see what is happening and if it really is a bug before further wasting your time.  The issue with the request intervals makes it rather tricky.

[GonoszTopi]

I suggest using a network capture tool like Wireshark to see the communication between the two clients.