[stoatwblr]

Heliotropo, on 07 May 2021 - 06:38 PM, said:

If we right-click on a friend user, shouldn't the option to remove it from the friends list appear, instead of "add to friends"?

it's a toggle

[Heliotropo]

It should work like a switch, but it doesn't work. To remove a user from the friends list you have to do it from "Messages".

[fox88]

Heliotropo, on 07 May 2021 - 08:38 PM, said:

If we right-click on a friend user, shouldn't the option to remove it from the friends list appear, instead of "add to friends"?

In this case the menu item should be disabled.
Adding "remove" makes little sense because friend status is supposed to be changed very rarely.

[Heliotropo]

Got it

Another minor matter. I have observed that when many users are suddenly removed from the upload queue (not sharing a folder, for example), the queue goes a bit crazy until it normalizes. In some cases I have found a user who remains in the queue for several minutes, although he is no longer downloading. I think other versions of emule do this in a more balanced way.

This post has been edited by Heliotropo: 09 May 2021 - 03:50 PM

[fox88]

A maintenance release 0.60c was published in Github.

This fixes several bugs and adds minor improvements.

The link is in the topmost message.

[QICKV8]

ed2k://|file|eMule0.60c.zip|4033146|469765F65C7CE6A312F4D051F097F9A9|h=FIOAXG6XKV7POH33WTLQZM3QZPCYDKEL|/

ed2k://|file|eMule0.60c_x64.zip|4628373|DF2E4E17987EA500E1DC425648AE6DD9|h=26BLXFQPSFWEAV7MXE3RUWZOWKBIMQNP|/

ed2k://|file|eMule0.60c-Installer.exe|4276075|16130D5877170BB00D820BC039C54805|h=FP23HEB6WIRSY5NSIIGWGFLBZ65OYHFP|/

ed2k://|file|eMule0.60c-Installer64.exe|4659493|18F04165013157E29FB2EBBC2934A54A|h=AT34PBQDXVCEXHP6MJBRX4FVUBJ6VBV5|/

[Capitán Hispania]

Thank you very much fox88 for all your work and patience.

[MistressAdmin]

Great work foxx88, and it is great that MediaInfo.dll version 21.03 can now be used, and can confirm details are now showing up on .mkv files

[VasiliyRus]

Hi fox88, it is good to see you are back.
Can you comment an issue posted on 09 April 2021
about 0.60 branch is being blocked by clients with antileech / fake client protection
like Morph and most likely some others as well?
I had to roll back to 0.51d since i download a lot of rare files where every source is important.

[fox88]

VasiliyRus, on 16 May 2021 - 07:35 AM, said:

about 0.60 branch is being blocked by clients with antileech / fake client protection
like Morph and most likely some others as well?

This feature has a long history of misbehaviour, and now its implementation is completely obsolete.

[stoatwblr]

fox88, on 16 May 2021 - 07:42 AM, said:

VasiliyRus, on 16 May 2021 - 07:35 AM, said:

about 0.60 branch is being blocked by clients with antileech / fake client protection
like Morph and most likely some others as well?

This feature has a long history of misbehaviour, and now its implementation is completely obsolete.

Be that as it may, it's probably worth skipping to 0.70 to stop this issue.

If general lore is that 0.6 is "bad" then that assumption will be coded in a lot of places and possibly in multiple P2P clients (not just emule). You can try to fight it or just skip the "problematic" version number

This issue is getting commentary (in a roundabout way) on several sites - several people trying out 0.60 have said they've stepped back to 0.5* because of poor/no throughput after a few MB transferred - which looks attributable to antileech mods on the sending end but they're not aware they're being blacklisted

This post has been edited by stoatwblr: 20 May 2021 - 12:57 PM

[Heliotropo]

My experience is not so negative. It is true that some morphXT users have not wanted to disable the antileech system, but others have. Also, from what I see, the number of morphXT users is even less than those of us using 0.60. If this is true, we both lose sources -and that's bad for everyone- but, except in very particular cases, it is those unfriendly users who, even if they believe otherwise, are losing more.
I take this opportunity to congratulate and thank fox88 for his work on the new update. Although we have already reported some aspects to improve, I confirm that the general behavior of this version 0.60c is better, at least for me.

This post has been edited by Heliotropo: 20 May 2021 - 01:39 PM

[p033928]

stoatwblr, on 20 May 2021 - 12:35 PM, said:

fox88, on 16 May 2021 - 07:42 AM, said:

VasiliyRus, on 16 May 2021 - 07:35 AM, said:

about 0.60 branch is being blocked by clients with antileech / fake client protection
like Morph and most likely some others as well?

This feature has a long history of misbehaviour, and now its implementation is completely obsolete.

Be that as it may, it's probably worth skipping to 0.70 to stop this issue.

If general lore is that 0.6 is "bad" then that assumption will be coded in a lot of places and possibly in multiple P2P clients (not just emule). You can try to fight it or just skip the "problematic" version number

This issue is getting commentary (in a roundabout way) on several sites - several people trying out 0.60 have said they've stepped back to 0.5* because of poor/no throughput after a few MB transferred - which looks attributable to antileech mods on the sending end but they're not aware they're being blacklisted

..i agree...

[SS1900]

@ fox88

The 0.60c release runs fine ...but many times the kad network suddenly becomes "firewalled" and i have to work hard to get it back right.
My network and the my router settings work fine ...as usual.
Win 10 x64 and no firewall installed.

[fox88]

SS1900

There are no changes in KAD or UDP networking code since 0.60b.
Do you use automatic upload limit or fixed value?

[QICKV8]

I have been running eMule 0.60 versions for 221 days 24/7 and not had 1 problem

Thanks fox88

[SS1900]

fox88, on 22 May 2021 - 05:53 PM, said:

Do you use automatic upload limit or fixed value?

A fixed value.

[Heliotropo]

Something to improve: if a message is sent to a user in the upload queue, the connection with him is often cut off.

It may be related to something already known: if the shared files are commented, the chances of the connection being cut off in the first moments they start sharing exponentially increase. This issue seems to affect aMule, Shareaza and eM Compat users less.

This post has been edited by Heliotropo: 23 May 2021 - 08:36 AM

[stoatwblr]

Observation: After a few days I'm seeing 60b and 60c grow to very large memory sizes (3GB virtual, 1.7Gb resident) but I have a LOT of files (85k entries, 23TB - and yes it takes about 90 minutes to start up)

Edit: two more days and it's up to 4.6Gb virtual/2.9Gb resident, so it looks like there are still some leaks.... :/

This post has been edited by stoatwblr: 26 May 2021 - 07:12 PM

[fox88]

SS1900, on 23 May 2021 - 11:05 AM, said:

A fixed value.

The only change that might be slightly related was in USS; otherwise there should be no difference with 0.60b.

Heliotropo, on 23 May 2021 - 11:28 AM, said:

if a message is sent to a user in the upload queue, the connection with him is often cut off.

Do I get it correctly, that the user was in the process of getting data from you, you tried to message, and then the user disconnected?