eMule 0.30c Xtreme 2.2 [21.01.2005]

[Xman]

TheMatrix,
gute Frage. Das gleiche hatte ich bei der offiziellen 0.30c des öfteren. War dann froh, daß es bei meinem Mod nie auftrat.
Vielleicht findest Du ja heraus ob das irgend ein Client ist (vielleicht in der Liste bekannter Clients) oder die Statistik sagt was. Wenn Du irgendwas zum Umstand dieses Verhaltens rausfindet weiß ich wo ich suchen muß.
Denk aber das ist ein Bug der offiziellen Version.

[TheMatrix]

Alles klar ich werde die Sache beobachten und schauen ob es nochmal vorkommt.
Was ich aber jetzt schon sagen kann es ist gleich nach einem Neustart vorgekommen!

[IceOnLy]

Also ich bin sehr überascht über diesen mod ,, ich hatte in lätzter zeit sehr viele mods ausprobiert auch die standart emule version aber nix wollte so richtig laufen kahm kaum über 10 kb (bei 20 files) nun hab ich diesen mod am laufen , fing auch gleich an zu ziehn nach ca. 20 min 30kb
das ist sehr gut wie ich finde Quellen findet er auch viele und recht schnell
der upload ist auch stabiel bricht nur sehr selten ein auch nur für 30 sek. oder so ...... DLrate steigend ich glaub ich hab mein neuen Lieblinksmod n1 work.

[digitalfrost]

Bis jetzt siehts nicht gut aus

eMule v0.30c [Xtreme 2.0b2] Statistics [[MPC-Donkey.de] digitalfrost]

Transfer
Session ULL Ratio: 3.91 : 1
Cumulative ULL Ratio: 1 : 1.23

Connection
Session
General
Reconnects: 0
Active Connections (estimate): 171
Average Connections (estimate): 173
Peak Connections (estimate): 313
Max Connection Limit Reached: 0

Session
Downloaded Data: 12.13 MB
Completed Downloads: 0
Active Downloads (chunks): 2
Found Sources: 3071
Download Sessions: 41
Successful Download Sessions: 14 (34.1%)
Failed Download Sessions: 27 (65.9%)
Average Downloaded Per Session: 887 KB
Average Download Time: 4:09 Minutes
Gained Due To Compression: 29 KB
Lost Due To Corruption: 0 Bytes
Parts Saved Due To I.C.H: 0
Total Overhead (Packets): 3.11 MB (84K)

Andere Mods laufen normal, d.h. über 75% erfolgreiche Downloadsessions. Hab normales T-DSL.

[eMulist]

hi Xman,
hast da echt nen klasse mod zusammen gebastelt, hab lange auf deine upgrade zur 30c gewartet..
aber er hat leider einen kleinen bug, der auch schon in den vorherigen Xtreme1.x-versionen vorhanden war:
sobald er im transfer-fenster eine datei > ~1,8GB darstellen soll, gibt er eine fehlermeldung in ner dialogbox aus
(An invalid argument was encountered.)..
ich hoffe, du kannst den fehler noch in dieser version beheben..
wäre wirklich schade, noch einen versionssprung deines wirklich super guten mods abwarten zu müssen!!!

greetz
eMulist

[Gucky]

@ digitalfrost, lass mal als gegenbeispiel den ewombat laufen.
da werden fehlgeschlagene dl-sessions anders gezählt.

das kenne ich vom maella her so, (mein erfahrungswert), das alles was nicht
ordentlich connectet als fehlgeschlagener dl zählt. warum auch immer ? ich weiss es nicht.
mein erfahrungen sagen mir, das es auf die menge der daten ankommt und nicht auf
die anzahl der fehlgeschlagenen dl´s. parade negativ beispiel bei mir im moment
der pawcio 4.07a. streckenweise dl-transferraten von 70 und mehr.
dann schaut man mit doppelklick sich an, was da kommt. toll - jede menge
dl-speed, aber es kommt kein einziges bit.
Beispiel : client xyz = 3,5 DL-speed : 0,0 mb datentransfer und das
über einen zeitraum länger als eine minute. dann bricht der dl ab. müsste
ja auch ein fehlgeschlagener dl sein. ist es aber nicht. das habe ich schon
öfter bei pawcio beobachtet. beim Xtreme (maella) mod dürfte also
die zählroutine in ordnung sein.
ausserdem der bug der alten versionen mit qr = 1. connect zu qr 1.
es kommt nix. fehlgeschlagen.

[Xman]

Gucky,
stimmt.. genauso wird bei mir gezählt: 0 byte tranfered= fehlgeschlagen. Meinst Du wirklich der pawcio zählt da anders ? Wäre ja dumm, werd ich mir aber mal ansehen.

[xtremchopper]

Ich hab sie auch hochgeladen 0.30c-Xtreme2.0beta2

[Gucky]

so - jetzt läuft sie bei mir auch. habe mal drauf geachtet, was digitalfrost
festgestellt hat. seine werte stimmen, aber es kommt kein dl zustande.
diese werte habe ich auch. das wird sich aber nach einigen stunden betrieb
von selbst erledigen.

den mod haste sehr schön gemacht, Xman. so wenige aktive verbindungen
habe ich schon lange nicht mehr gehabt. 3.500 gefunden quellen und sie haben
sich nach knapp einer stunde laufzeit auf einen wert von 45 bis 70 mit kleinen
spitzen eingepegelt. jetzt muss er erstmal über nacht laufen und wenn dann
die aktiven verbindungen immer noch so niedrig sind, werde ich mal ein wenig
oder auch mehr das hardlimit erhöhen. ma schauen, was er mir dann erzählt.
saugen tut er auch schon. na ja - bei 25 files im dl muss ja was kommen.

ein bischen meckern ( ) die icons für edonkeys und gebannte clients
sind identisch. (roter monitor) aber du schriebst ja, "schon einige tausend codezeilen
geändert" für diesen mod. da kann so ein ausrutscher schon passieren.

morgen (heute) gibt es ein neues statement.
ich wünsche mir einen fröhlichen blus (blasen und saugen). euch auch.

[snakech]

@Xman
mir ist augefallen, dass in der Version 2.0 weniger UL-Slots geöffnet werden als in der Vorgängerversion, aktuell 8-10, vorher waren das immer so 12-14, finde ich sehr positiv.
Ansonsten:
konstanter UL, kaum CPU-Last, wenig RAM-Verbrauch.
Zum DL kann ich nichts sagen, da ich im Moment primär uppe.

Für mich im Moment der beste Mod, besten Dank

[nuky]

also , über nacht einmal nich mehr ausm tray holbar = muli überanstrengt
naja , dann halt heute abend erste ergebnisse oO

[Xman]

Gucky,
in welcher Liste sind die Icons falsch ? upload/queuelist,downloadlist sind vom 1.2, knownclients sind neu gemacht.
Ich glaube aber es ist gar kein Fehler. edonkey v61 sind kaum mehr im Einsatz. Die paar die man angeblich noch sieht sind zu gut 80% wirklich Leecher und daher auch das rote Icon. Rotes Icon heißt übrigens nicht gebannt sondenr als Leecher erkannt (aber damit auch gebannt)

nuky,
das gefällt mir nicht. Das Festplattenlämpchen leuchtete nicht gerade ? Daß er vielleicht gerade nur mal eben beschäftigt war !?
Diesen dummen Bug haben leider viele emule Versionen. Bis jetzt ist dem ganzen leider noch niemand auf die Schliche gekommen. Danke dennoch für den Bericht.

[Odinasgardson]

@ Xman, Ich habe deinen neuen auch mal zum Test angeworfen.
Ich muß sagen ich bin positiv überrascht. Er läuft gut an und auch die möglichkeiten der Einstellung finde ich gelungen.
Werde mich später nochmal melden um zu berichten.
Super Arbeit.

Könnte zu meinem Lieblingsmod werden.

mfg
Odinasgardson

[TheMatrix]

@Xman

Hier mal ein Zwischen Bericht von einem Nutzer!!
Dieser hat geschrieben:
hier mal meine erkenntnisse aus einem 10-stunden-test:

- nach 4 stunden ist das programm abgestürzt
- das finden von quellen dauert erheblich länger als bei der version 0.29c extreme 1.2
- der aufbau der verbindungen zu den gefundenen quellen dauert ebenfalls länger als beim vorgänger
- downloadrate lag unterhalb 5kb/s
- die quote der fehlgeschlagenen downloads lag bei sagenhaften 80%!

da sollte xman noch mal ein bischen nachprogrammieren.

ich bin erstmal wieder auf den vorläufer umgestiegen

[Xman]

übrigens...

Es haben ja schon einige bemerkt, daß es manchmal Clients gibt, die einen zwar eifrig Download geben aber kein Byte fertigstellen. Diesen Fehler bemerkte ich schon seit Beginn meiner emule-Zeiten in allen Versionen. Hab dies auch schon an verschiedenen Stellen gepostet.
Ich nenn diese Clients die zwar Download geben, dieser Download aber irgendwie ins Nirvana geht, Nirvane-Downloader
Nun hab ich ein kleines Feature eingebaut, mit welchen man einen einzelnen Client beim Download stoppen kann. (wundert mich warum dieses Feature noch niemand gefunden hat ). Contextmenü eines downloadeneden Clients->Stop this Client.
Dies ist dazu gedacht, um Clients eben diese Nirvana-Downloader zu stoppen. Bringt ja schließlich nichts wenn einer vielen MBs in mein Computernirvana lädt. Da soll er es lieber bleiben lassen und dem nächsten in seiner Liste uppen.
2. Vorteil dieses Features: sollten mal wieder beim letzten fehlenen Chunk 5 Clients uppen, so ist es ja meisten so, daß am Schluß ausgerechnet der langsamste übrig bleibt um den Chunk fertigzustellen. Oft bricht dann dieser auch noch ab und man darf nochmal warten. Nun kann man einfach die langsamen Clients stoppen, so daß eben dieser letzte Chunk allein von einem schnellen Client beendet wird.