Print

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

[GonoszTopi]

Now try (9700 + 9548)/2 . (And always build with mmap.)

That's rev. 9624: tar.gz or zip

[GuybrushThreepwood]

Again, thanks to the both of you! I would try the SVN 9624. What I was guessing was that, considering that the 9700 works even worse than the 9852 (with the same downloads so under similar if not the same conditions), maybe that in the meantime you've applied some optimizations and this mean that I could try a version newer than the 9700 instead of an older one like the 9624... As said, it's just a guess and that's why I was asking...

[GuybrushThreepwood]

Hello and excuse me for my long absence. I've finally managed to find some time to build the 9624 as you've suggested. Nothing has changed or has improved: almost the same behaviour than the other versions tested. The only stable version remains the 9548.
I ask you for an opinion on this again:

...considering that the 9700 works even worse than the 9852 (with the same downloads so under similar if not the same conditions), maybe that in the meantime you've applied some optimizations and this mean that I could try a version newer than the 9700 instead of an older one like the 9624....

Apart from this, I'm starting to think that the problem isn't related to the CorruptionBlackBox (though it is certainly a major improvement over the 9548) or commenting some lines isn't enough to disable it. If it could help, I could send to anyone who asks for it, the files modified by me (apart from modifying PartFile.cpp to disable the BlackBox and MuleUDPSocket.cpp to disable the logging of discarded packets when the connection drops, please consider that I had to make a little modification to amule.cpp too to get the downloads over 1Gb working as said here:

http://forum.amule.org/index.php?topic=16721.msg88939#msg88939

but this modification has proved to be ok with all the versions up to 9548 that I've built). Tell me if you happen to have some ideas: in the meantime I would try to build the latest SVN and see how it behaves. Have a good day!

[Stu Redman]

If there was a regression between 9548 and 9624 you should try a version in between to narrow down what change is causing the problem.
What you should do first however is build 9548 in your current build environment and see if it still performs as well as before. Because it could also be a problem of your build environment.

[GuybrushThreepwood]

What you should do first however is build 9548 in your current build environment and see if it still performs as well as before. Because it could also be a problem of your build environment.

Already done! I've modified MuleUDPSocket.cpp to log the "discarded packet" warnings too (the 9548 originally uses a printf as you've said to me) and the 9548 is rock solid as always. The build environment is certainly fine as I've succesfully used it to build many aMule versions and many other things. I've built the latest 9960 (without commenting the calls to the BlackBox, I've only modified amule.cpp for the 1Gb issue and MuleUDPSocket.cpp to disable the logging of the "discarded packet" warnings): let's see how it behaves. I've tweaked the options a little but nothing major (I've disabled the GeoIP support). I'm not sure that using an older version is the key... I was wondering: you've said to me that the 9548 has a bug that makes sent packets corrupted: is it possible that the "cure" for this issue is the problem? I don't think...

[Stu Redman]

As long as your upload reaches your set upload rate it has no effect.

Oh, and you are using the same configure options for all your builds I hope?
GeoIP has no influence on the daemon.

[GuybrushThreepwood]

As long as your upload reaches your set upload rate it has no effect.

Yes, it does.

Oh, and you are using the same configure options for all your builds I hope?

Yes, obviously.

GeoIP has no influence on the daemon.

Thanks for telling me!

By the way, the newly built 9960 with the CorruptionBlackBox enabled isn't stable (on my router: it's clear that mine is a peculiar situation, first of all because of the very limited resources).
I've tried it three times and after more or less one hour and an half it always stops uploading and downloading, the connection doesn't drop (I've checked and the router reports the ADSL carrier being up) but I can't reach any WAN address (I can instead reach the web interface of the router and even telnet to it), the swap doesn't crash completely as with other versions tested (like the 9852 if I remember well) but it takes more than usual to do the swapoff command and (this is strange) the swap usage remains EXACTLY the same all the time after aMule starts playing up.
I've rebuilt the 9960 with the CorruptionBlackBox disabled and it has been uploading and downloading fine for two hours and an half now: let's see if it's more stable; by now I can say that it's certainly more stable than the same version, built by the same build environment and with the same options, under the same conditions (same number and type of downloads etc.). This is quite obvious as the CorruptionBlackBox is certainly "heavy" on resources but I've reported the testing results anyway for the sake of  completeness.
I will keep you updated.

[Stu Redman]

Are you watching all the time with the remotegui? I just fixed an evil core memleak when EC was active in 9963. It was introduced in 9704. (By me, yeah, but the actual bug was already lurking in the code and waiting for someone making use of incremental tags...)

[GuybrushThreepwood]

Bad news. I've left aMule working overnight (when I've left it last night everything was still working as expected) and this morning I've found it struggling: the hard drive didn't stop working a second, upload and download speeds were awful and erratic; I've checked and as expected the swap had given up, I needed to reboot the router because the swapoff command didn't help. EXACTLY as with the other versions from 9838 and so on (some of the older versions tested like the 9624 had a somewhat different behaviour as described in the previous posts but weren't stable anyway).
I can't even imagine what could make the swap crash this way (even considering that the router remains stable and the ADSL carrier up and I can reach any WAN address with no issues).
In response to your question: no, I use the remote GUI only for a couple of minutes to check how things are going on but keep it closed most of the time as I think that establishing and keeping the connection opened is another load for the poor router. I'm starting to think about giving up!
By the way, if you think that it could help, I would build the newest 9963: the bug has been introduced with 9704 and this makes sense but, again, I only use the remote GUI for a couple of minutes, sometimes over the day.
Just a last thing: the italian translation is almost fine but with 9960 (I could be wrong but I don't remember this "issue" with other versions) when I exit aMuleGUI it asks for confirmation in english. It's just a very marginal issue.

-EDIT-

Confirmed: aMuleGUI 9852 (the last before 9960 that I've built, it works so it uses the same protocol version) asks for confirmation in italian, not in english like the 9960. By the way I don't think there is the need to waste time on this.

[Stu Redman]

when I exit aMuleGUI it asks for confirmation in english

Feel free to help update the Italian translation. 

Instead of trying latest versions just return to the original plan to find out when the regression was introduced.

[GuybrushThreepwood]

Feel free to help update the Italian translation. 

I would be very happy to do it if you could tell me how.

Instead of trying latest versions just return to the original plan to find out when the regression was introduced.

I fear that I would end up with building the 9549! Just kidding! The next candidate is (9548+9624)/2=9586: excuse me for the dumb question but how could I use the aMule Git (http://repo.or.cz/w/amule.git/) to download it? Thanks!

[GuybrushThreepwood]

I reply to myself the 9586 should be this:

http://repo.or.cz/w/amule.git/snapshot/ab595d4c648cf91dd3ea55314ac26cb3ca3b3368.tar.gz

I would build it ASAP.

[Stu Redman]

I would be very happy to do it if you could tell me how.

http://wiki.amule.org/index.php/Translations

[GuybrushThreepwood]

http://wiki.amule.org/index.php/Translations

Excuse me for making another dumb question! I already know that page and I've used it to localize my remote GUI but I've completely forgotten it! Thanks!

[GonoszTopi]

The next candidate is (9548+9624)/2=9586: excuse me for the dumb question but how could I use the aMule Git (http://repo.or.cz/w/amule.git/) to download it? Thanks!

The easiest way is using git. First you have to clone the repository with

Code: [Select]

$ git clone git://repo.or.cz/amule.git
(this only has to be done once). This will put the clone into ./amule. You can name another directory to hold the mirror at the end of the command line.

Now enter the directory where your clone resides. Second, you select which revision you want to test (rev.9586 in your case) and check out that revision with

Code: [Select]

$ git checkout amule-svn-r9586

Please note that not every single revision is mirrored to git (most likely because those commits affected only other branches or svn properties not meaningful to git). In case you get an error like below, just try decreasing the version number until it succeeds.

Code: [Select]

$ git checkout amule-svn-r9953
error: pathspec 'amule-svn-r9953' did not match any file(s) known to git.