[Xman1]

Here is something to test for you:

changelog:

Quote

xtreme 5.3 beta 1
- adapted all Xtreme features to Codebase 0.47c
- added calculation of obfuscation data to the bandwidthcontrol
- added option to choose the method how chunks are selected for downloading
+ Maella = traditional or zz = new in 0.47c
- changed: obfuscation icon is displayed for all clients which enabled it
- fixed an official bug in source-exchange (Xanatos)
- fixed few minor bugs

Download: http://www.xtreme-mod.net at the download section.

Please no mirrror or repost somewhere else until the final version is released.


remark: this beta is english language only.

[LorenzoC]

Testing, no errors so far.
Just some cosmetic suggestions: the key on the "PO enabled" icon is almost invisible on my screen, a better icon is needed
I don't get well the meaning of the icon. Does it say the other end has the PO on "enabled" or that the connection is "obfuscated"?
In my opinion, since both ends have 3 possibile options for PO, the only useful information is about the state of the connection, not about the client settings.

[Ciauz]

Testing... No probz for now... Let's test it all night long... Thanks Xman1 u r tha man... Cya

[Xman1]

I already worked on that icon and gave it a white shadow.. but only for the true-color icon. Dont know if your windows choose an icon with a lower resolution ? Can you post a screenshot ?

The key icon is displayed under following circumstances:
- we or the other client enabled obfuscation and we/the other client support it. This means, both clients always try to communicate obfuscated (also UDP-packets, which you dont see when they are sent).
- when a (TCP)connection is established the icon tell you if the communication is obfuscated or not.

[LorenzoC]

I guess you have more important things to work on, but here is the image.
You can notice there are 0.47c clients without the key in the icon... is it correct? Does it mean they have disabled it? I've got it on "enabled"...
hxxp://photos1.blogger.com/blogger/4255/574/1600/xtreme.jpg
Change xx with tt

This post has been edited by LorenzoC: 22 September 2006 - 09:06 PM

[Fred Mad]

Testing, thanks

[gav616]

kewl. testing...

...never know what slot speed to use... pfff

[Xman1]

@LorenzoC
its much easier than you think:
- with key icon: we communicate obfuscated
- without this icon: we communicate normal

and I cant see your image.

[mkol]

Quote

Xtreme Full Chunk
- it always transfers whole blocks (1 block = 180 kb)
- it transfers at least 2 MB. After reaching this 2,5 MB, Xtreme looks at the chunkboarder. Now when Xtreme see the client has finished one chunk the upload will be cancelled
- maximum transfer is like official: 9.32 MB

Isn't it better to simply use the official method (always transfer 9.32 MB)? With eMule 0.47c it's very hard to get a complete chunk from Xtreme clients.

[Xman1]

I increased the 2,5 MB to 2,8 with this version... and what I saw at my tests the 0.47c clients don´t get less than the older ones.

[LorenzoC]

Xman1, on Sep 22 2006, 10:50 PM, said:

@LorenzoC
its much easier than you think:
- with key icon: we communicate obfuscated
- without this icon: we communicate normal

and I cant see your image.

I 've put the link, you should be able to see the image copying the url in the browser.
hxxp://photos1.blogger.com/blogger/4255/574/1600/xtreme.jpg
I got It from the beginning but I also saw some 0.47c clients that don't have any key even if I am on "enabled", that means they must have PO on "disabled" otherwise the connection should be "obfuscated".

Meanwhile, I know It is a short session but I see a lot of failed uploads:
------------------------
Upload Sessions: 83
Total successful upload sessions: 53 (63.86%) (active: 9, socket: 14, completed: 17, cancelled/ended: 12, different file: 0, exception: 0,blocking: 1, others: 0)
Total failed upload sessions: 30 (36.14%) (socket: 6, completed: 0, cancelled/ended: 23, different file: 0, exception: 0,blocking: 0, others: 1)
Average Uploaded Per Session: 3.29 MB
Average upload time: 16:57 Minutes

Downloads are better:
-------------------------
Download Sessions: 42
Successful Download Sessions: 35 (83.3%) (active: 8, paused: 0, no needed part: 4, timeout: 6, socket: 12, out of part: 5, exception: 0, others: 0)
Failed Download Sessions: 7 (16.7%) (paused: 0, no needed part: 0, timeout: 1, socket: 6, out of part: 0, exception: 0, others: 0)
Average Downloaded Per Session: 3.34 MB
Average Download Time: 10:18 Minutes

This post has been edited by LorenzoC: 22 September 2006 - 09:16 PM

[Xman1]

Quote

I got It from the beginning but I also saw some 0.47c clients that don't have any key even if I am on "enabled", that means they must have PO on "disabled" otherwise the connection should be "obfuscated".

that´s strange... but there is nothing changed at Xtreme. It could be the source-exchange bug of the official emule.

Quote

Total failed upload sessions: 30 (36.14%) (socket: 6, completed: 0, cancelled/ended: 23, different file: 0, exception: 0,blocking: 0, others: 1)

everything fine here. The other clients canceled.. which mean: you don´t have anything for them. This oftenly happens when you are sharing small files.

Edit: and for the key-icon... I see I was too lazy.. have to edit also the icons with smaller resolution.

This post has been edited by Xman1: 22 September 2006 - 09:23 PM

[welldl]

Testing...

Thanks.

[aachen]

Thanks

Testing too...

[Death_Hilarious]

Working very well for me, so far.

(ISP throttled user)

[Pachnes]

Hi Xman, vielen Dank!

Läuft rund, Kad ist offen, High ID.
Ich probiere Obfuscation und zz.

Die Firewall von Windows XP SP2 bockt manchmal, wenn eine exe ausgetauscht wird.

Dann einfach in "Systemsteuerung", "Windows Firewall", "Ausnahmen" den Eintrag "eMule" löschen und neu anlegen. Dann muss die Firewall die eMule.exe neu referenzieren.

Frage zu Dateileichen in "eMuleTemp":

Ich habe vor zwei Wochen für einige Tage eMule 0.47c Standard ausprobiert. Nun habe ich mehrere Dateien *.txtsrc, zu denen es keine *.part, keine *.part.met und keine *part.met.bak mehr gibt in "eMuleTemp". Diese Downloads sind wohl in der Zeit fertig geworden, als eMule 0.47c Standard lief. Standard kennt diese Dateien nicht und bereinigt daher "eMuleTemp" nicht richtig, wenn ein Download fertig wird. Könnte ein Feature in Xtreme eingebaut werden, das solche Dateileichen findet und aufräumt?

In deinem anderen Forum ist zur Zeit kein Anmelden möglich:

10 Meine Anmeldung wird akzeptiert
20 Ich erstelle/editiere mein Posting, und werde beim Speichern aufgefordert, mich anzumelden.
30 Das mache ich.
40 Goto 10

This post has been edited by Pachnes: 24 September 2006 - 12:43 PM

[Xman1]

I reported it to the german forum...

for the feature request:
other mods generate other additional files at the temp folder... and maybe someone want keep some of them. I think the user should care himself about cleaning the temp folder.

Edit: the answer about your posting-problem at emule-web board you can read here: http://www.emule-web...html#post112103

This post has been edited by Xman1: 24 September 2006 - 12:48 PM

[Pachnes]

Hi Xman,

Xtreme 5.3 Beta 1 does run stable. You know the huge amount and the huge size of my shared files (2512 files/1.121 Terabyte) which I charge to my mule. All is very fine. Upload with zz does work fine. Thank you.

Hint for users of Xtreme 5.3 Beta 1 and members of lugdunum community:

I had disconnections to servers, which are running under lugdunum 17.13, every 20 Minutes exactly. I yesterday started to connect to servers with lugdunum 17.14 and there was no disconnect anymore. Maybe an issue in lugdunum 17.13? Did you experience the same?