Beides müsste doch gehen. Der eWombat wandelt das eh nochmal in sein eigenes Format (.ccf) um. Kopier die .met einfach in den eWombat-Ordner und den Rest macht er dann von alleine. So gings bei mir.

Hi

@Edol:
Im dem Fall ist das deutsche richtiger, da sich der Absatz auf die Datenübernahme von eMules >= 0.29b (mit sui) bezieht...aber
ist eigentlich egal, beides stimmt, da der eWombat das clients.met format der eMules ohne sui (älter als 0.29b, normalerweise im Hauptverzeichniss) übernimmt und das der eMules mit sui (ab 0.29b, normalerweise im config\ Verzeichniss). Wenn jetzt aber im eWombat Verzeichniss und im eWombat\config eine clients.met ist importiert er alle beide. (erst die im Hauptverzeichniss dann die im config\)
Importiert wird aber nur wenn keinen eWombat/config/ewombat.ccf und ewombat/config/backup/ewombat.ccf.bak existieren.

cu
darkwolf

thx.
Überschreiben die sich dann gegenseitig?

Was schon seltsam manchmal ist.

so habe ich die letzten Tage pro Tag mehr als 3 GB runtergeladen.
Und heute ist mir die Kiste eingefroren. Wohl zu hoch übertaktet, bei den Temperaturen.
Auf jedenfall, seitdem so gut wie nichts.

cobrajet, da musst du dir nichts draus machen. Kenne ich auch.
Das sind dann die Tage, wo ich mal einen anderen Mod ausprobiere.

Da kontrolliert dich der Internetzählmeister.
Und der sagt : Du hast viel gedownt, jetzt biste dran mit uppen. Kontoausgleichen. :mrgreen:

wird schon werden!

Ein großes Lob an den Wombat Progger, eines der besten Mods wie ich finde.
Hier die Statistik fuer die Intressierten :)

Ratio: 1 : 2,42 (1 : 2,10)
Heruntergeladen (Session (Total)): 1,02 GB (1,26 GB)
Hochgeladen (Session (Total)): 433,81 MB (616,71 MB)
Average(5-min) DL-Rate: 32,96Kbs (50,16Kbs) UL-Rate 13,62Kbs (15,01Kbs)
œ
aktive Verbindungen (geschätzt): 184 - Zu viele Verbindungen: 2
UL-Sessions successful: 152 - failed: 69 - Avg. time: 17:56 mins
DL-Sessions successful: 581 - failed: 310 - Avg. time: 11:57 mins
Wartende Uploads: 1232
Gefundene Quellen: 1519
SUI successful: 2400 - failed: 3
Detected 38 leechers, 3 credit thieveries, 0 friendshare-mod leechers
Detected 19 suspicious compressed blocks
Programm-Laufzeit: 9:03 h
Mem used: 94,55 mb free: 1953,33 mb

Cu, SeCtUn3

Hi

@Edol, Nein, die werden wie bei dem extra ClientsCreditTool gemerget. d.h. es werden falls ein Client doppelt vorhanden ist , die neueren Credits übernommen, bzw. die mit einen s.u.i. key

@cobrajet: :wink: Versuchs mal mit einer Wasserkühlung (Athlon3200: 37Grad OnDie) :wink:

@Alle: Da ich für die 0.064er gerade ein paar Fehler suche, habt ihr schon mal mehrere brave eWombats (nicht gebannt) ihr in euren 'bekannten Clients' gesehen ?

cu
darkwolf

Na aber sicher doch, hier mal der Screenshot, sowohl die guten wie auch die bösen Buben.

http://mitglied.lycos.de/usul69/ewombatkumpel.png

Als Bonus hier meine aktuelle Statistik:

Ratio: 1 : 2,00 (1 : 2,05)
Heruntergeladen (Session (Total)): 1,01 GB (128,93 GB)
Hochgeladen (Session (Total)): 519,08 MB (62,88 GB)
Average(5-min) DL-Rate: 19,95Kbs (29,72Kbs) UL-Rate 9,99Kbs (11,43Kbs)
aktive Verbindungen (geschätzt): 304 - Zu viele Verbindungen: 0
UL-Sessions successful: 135 - failed: 57 - Avg. time: 16:11 mins
DL-Sessions successful: 340 - failed: 93 - Avg. time: 20:02 mins
Wartende Uploads: 2504
Gefundene Quellen: 3496
SUI successful: 6692 - failed: 69
Detected 152 leechers, 23 credit thieveries, 0 friendshare-mod leechers
Programm-Laufzeit: 14:47 h
Mem used: 113,24 mb free: 1934,64 mb

@darkwolf

da braucht man aber geld zu. vorher aber muß das leidige Studium zu einem Ende gebracht werden.

achja, ich habe insgesamt 4 ewombat user drin.
2 mal 0.063 (Invalid id) [das lustige hier, zweimal ich, zumindest der name und hash id]
1 mal 0.040
1 mal 0.033 catched by snafu

@Darkwolf
Eigentlich heißt es nicht catched sondern caught.
Das soll nicht lehrerhaft klingen, auch wenn es sich bestimmt so liest.
Wäre auch nur rein kosmetisch.

Leider bisher nur einen. Aber dafür zwei DarkMules die sich meinen Namen geklaut haben.

http://www.maddis.net.ms

@ Usul Wo hast du die ganzen eWombats her ?? :)

Hi so der Wombat läuft so ganz Stabil wie schon Tausend fach gesagt .

Aber die Quellen findet er sehr schlecht was muß ich einstellen das er die Quellen besser findet.

Mfg

Maddis,

heute siehts bei mir so aus:

http://mitglied.lycos.de/usul69/ewombatkumpel2.png

also auch nicht viel besser als bei dir.

@ moetschclan Bei mir findet un connectet er gut. Mit Defaulteinstellungen Beim finden hängt es denke ich aber auch stark vom Server ab.

@ Usul Eben war mein einer Wombat von oben in der Liste nicht mehr zu finden. Jetzt ist er wieder da...komisch....was mir auffällt ist das ich auch viele Shareaza Clients in der Liste habe.

Shareaza hat jetzt ne verbindung zum emule netzwerk und auch noch ein paar anderen. bittorent sogar glaube ich auch.

und wenn du nich t mehr in der liste bist hängt wohl damit zusammen, daß neu gestartet hast. weil ja nichts up und downgeloaded wurde, ist er wieder gelöscht worden. sonst wäre die client.met bald riesig groß, wenn man von jedem alles speicher.

und wenn du dann wieder da bist, da hat er sich wohl wieder mit sich selber verbinden wollen.

hab wieder ein paar eWombats neu in der Liste.

3 mal als identified und alles paletti

Hi,

Danke für die eWombat-'zählerei', ich wollte bloss sichergehen, das ich im s.n.a.f.u. keinen Bug habe, da bei mir zur Zeit irgendwie immer nur ein 'braver' eWombat und ansonsten nur gebannte eWombats zu sehen sind oder solche sachen wie 'eWombat [lsd10]'

cu
darkwolf

Mal noch nen Nachschlag zum Schäfche...äh, ich meine eWombat zählen:

http://mitglied.lycos.de/usul69/ewombatkumpel3.png

Irgendwie ist s.n.a.f.u. der Client EGOmule zum Teil durch die Lappen gegangen. Viermal der gleiche Userhash, aber nur einmal gebannt. Aber vielleicht gibt es ja eine logische Erklärung.

Ist mir auch aufgefallen, aber nur einer hat Punkte ein der Warteschlange.
So kenne ich das vom eWombat.

Hi @all
Benutze den eWombat 0.63 und bin sehr zufrieden.
Was mir aber aufgefallen ist , wenn ich eine cd Brenne geht der Download
rapiede in die höhe.Wenn dann der brand zu ende ist fällt der download ins bodenlose.
Meine frage ist woran kann das liegen und was kann man da machen.

Mein system win2000 Amd 1600+ 256 ddr 266mhz.

Hallo großer Häutpling Sitting Bull,

das liegt an der Auslastung der CPU. Da kommt es dann zu einem Buffer Overflow, oder sowas ähnliches. Da rechnet er nicht mehr richtig mit.
Nichts dabei denken, kam schon in vielen Versionen des Mulis vor, auch dem normalen.

Der Oberguru des Emules, der eWombat Programmieren hat sich dem schon angenommen!

Heil dir, Darkwolf, für so einen super Mod!

Nie abgestürzt und ein super DL/UL Verhältnis!!!

Und vor allem, nie abgestürzt!

SittingBull,

das ist nur ein Bug, der bei hoher CPU-Last zur Fehlberechung des Downloads führt. Also nur eine kosmetische Sachen ohne ernste Konsequenzen ;-) Ich schätze mal, während du brennst, ist deine CPU-Last bei 100%, kannst ja mal kontrollieren. Kann aber auch sein, das ich mich irre.

Hi,

@Usul, die vier freien Egomules müssten eigentlich mit der Zeit auch erwischt werden, da der s.n.a.f.u. (wg. CPU-Last) nicht dauernd die Userhashes checked...

@StittingBull, da hat Usul recht, wenn die CPU-Last über längere Zeit bei 100% ist, kommt die berechnung der Downloadraten aus dem Takt, da sie momentan noch auf einer Zeitbasis von 100ms basiert, und es werden extrem 'hohe' raten angezeigt. Intern läuft der Upload/download aber normal weiter.

@cobrajet, an einer Lösung dieses 'High-CPU' Bug arbeite ich...bloss momentan ist es einfach zu heiss :wink:

cu
darkwolf

Mir ist nochwas blödes aufgefallen, hier mal ein Screenshot:

http://mitglied.lycos.de/usul69/a4af.png

Man sieht einen einzelnen Download "aufgeklappt", also die einzelnen Quellen sind sichtbar und hier im Beispiel alle A4AF-Quellen. Das Dumme ist nun, wenn man die Quellen nicht aufgeklappt hat, dann denkt man, man hat 0 Quellen für diesen Download, was ja wohl so nicht stimmt. Ist das bei allen Emule-Versionen so oder ist das gar ein Bug in eWombat? Auf jeden Fall ist es irritierend, finde ich. Ich kann damit leben, aber mir wäre es doch lieber, wenn A4AF-Quellen mitgezählt würden, schließlich werden die irgendwann mal relevant.

@usul, wenn ich das bild von dir richtig interpretiere, wurde bei diesen clients nach einem anderen file gefragt (A4AF - ask for another File), somit würde das meiner meinung nach mit den 0 quellen schon irgendwie stimmen, da ja für dieses file momentan keine quellen vorhanden sind.

winki2099,

natürlich, aber es sind Quellen dafür da! Quellen bedeuten für mich, jemand anders hat diese Datei und IRGENDWANN bekomme ich sie. Das ist bei A4AF der Fall, wenn die andere Datei fertig ist, gehts mit dieser Datei weiter. Ganz zu schweigen davon, das ich mit A4AF -> "Swap all to this file" die Quellen von Hand umsortieren könnte. Die 0 bei den Quellen lässt mich aber denken, 0 Quellen, die Datei hat niemand. Sicherlich lassen sich für beide Sichtweisen Argumente finden, ich wollte nur mal wissen, ob das normal ist. Ich finde es irritierend.

okay, irritierend ist es sicher, aber wenn ich den roten balken anschaue und alle stehn auf A4AF, dann komme ich doch zu der Annahme, dass niemand mehr das file hat, denn sonst nüsste es doch blau sein. oder irre ich mich da?

winki2099,

nein, die Datei ist vorhanden, scheinbar können die vorhandenen Teile aber nicht abgefragt werden, wenn es von einer anderen Datei bereits geschehen ist. Wenn ich die Quellen zu der Datei swape, werden auch Chunks blau. Ist vielleicht die gleiche Ursache wie A4AF an sich, man kann immer nur eine Datei runterladen/Teile abfragen.

ja, man kann immer nur eine datei runterladen, das stimmt. mir wäre aber neu, dass die dann rot angezeigt wird. aber man lernt ja nie aus :wink:

Hi,

die rot angezeigten Clients einer Datei sind per A4AF zu einer anderen Datei geswappt worden und dort 'echte' Quellen. Ich habe mich schon dumm und dämlich gesucht, warum die A4AF Clients immer noch beim ursprünglichen File angezeigt werden, aber das ist beim eMule auch so (allerdings nicht rot).

Das Problem an der ganzen Sache ist, das man bei einem Client nur einmal in der Queue stehen kann. d.h. selbst wenn der Client Teile für mehrere Dateien hat, die man braucht, kann er nur für eine einzige Datei eine aktive Quelle sein, für die anderen Dateien hat er den status A4AF. Beim eWombat wird dieser A4AF Status in rot angezeigt, mit der Datei in [] bei der dieser Client eine aktive Quelle ist wobei sich das QR dann auch auf diese Datei bezieht, theoretisch könnte sogar ein download angezeigt werden...

'Swap all to this file now' setzt bei der ausgewählten Datei alle Quellen der anderen Dateien die Teile für die ausgewählte Datei haben für diese als 'aktive' Quellen und für die anderen auf den Status 'A4AF'. Der 'Auto Swap' macht dasselbe bloss automatisch alle 5 Minuten.
'Swap all to any other file' swapt die Quellen der ausgewählten Datei die Teile für andere Dateien haben zu einer von diesen Dateien.
Des weiteren werden Quellen die keine benötigten Teile oder QR=voll haben automatisch (wie beim eMule) zu einer anderen Datei geswappt, falls sie diese haben.

Leider ist die ganze swapperei noch nicht sonderlich intelligent, d.h. es wird geswappt ohne rücksicht ob der Client für die andere Datei überhaupt benötigte Teile hat, das wird aber noch überarbeitet.

cu
darkwolf

Irgendwie habe ich das Gefühl, es ist immer noch nicht klar, worauf ich eigentlich hinaus will, deswegen nochmal ausführlicher. Was für verschiedene Arten von Quellen gibt es?

1. Quellen, von denen ich gerade im Moment runterlade
2. Quellen, bei denen ich in der Warteschlange stehe (QR=xxxx)
3. Quellen, bei denen die Warteschlange voll ist, ich mich also nicht anstellen kann
4. Quellen, die keine benötigten Teile mehr haben
5. Quellen, von denen ich bereits eine andere Datei haben will (A4AF-Quellen)

Das dumme ist nun aber, das nur die Quellen 1.-4. als Quellen gezählt werden und hinter dem Download auftauchen, die A4AF-Quellen aber nicht. Aber warum? Mit einer Quelle Nr. 3 oder Nummer 4. kann ich im Moment genauso wenig anfangen wie mit Quelle Nr.5. Warum dann die Extrawurst für Nr.5? Könnte man die nicht genauso mitzählen wie alle anderen auch? Meiner Meinung nach sind die A4AF-Quellen sogar schneller nützlich als alle anderen, wenn die andere Datei fertig ist, die die Ursache für A4AF ist, dann stehen die Quellen sofort bei dem Download zur Verfügung, wo sie als A4AF aufgeführt wurden, und man steht sogar schon in der Queue weiter vorn.

Ich habe das Gefühl, das das einen ganz simplen programmtechnischen Grund hat. Wenn die Gesamtzahl aller Quellen berechnet wird, wird eventuell nur die Zahl der Quellen pro Datei addiert. Wenn jetzt A4AF-Quellen bei zwei Dateien reinzählen würden, würde das die Anzahl der Quellen insgesamt verfälschen, da die A4AF-Quellen dann mehrfach reinzählen. Vielleicht hat sich das ganze so entwickelt.

genau das vermut ich auch.

Hi

@Usul: Programmtechnisch sieht das so aus: Deine Quellen 1-4 sind direkt mit der Datei verknüpft (Deswegen aktive Quellen) und werden deshalb für diese Datei gezählt.
Bei jedem Client gibt es eine Liste in der steht welche Dateien er noch hat, die du brauchst (das sind dann die A4AFs). Wenn ich jetzt die A4AFs für eine Datei Zählen möchte, müsste ich bei jedem Client im Download diese Liste durchgehen und das wäre 'etwas' CPU Intensiv...

cu
darkwolf

Nur so ein Vorschlag von mir, da ich immer so viel Zeug in meiner Liste drin habe.

Wäre es möglich eine Rubrik reinzubringen, wann das File in die Liste aufgenommen worden ist?

Nur mal so als Anregung.

THX

C

darkwolf,

wie ist denn der Stand der Dinge bzgl. Version 0.064?

Hiho, ist es viel Aufwand deinen Code aif 0.30a zu portieren. Wegen diesem Sicherheitsloch?

also ich hab jetzt doch noch mal die 0063 drauf getan und aufeinmal läuft sie stabil und stürzt nicht mehr ab wenn man die quellen manuel kickt. aber mich würd es auch interessiern ab wann man mit der 0064 rechnen kann

also ich vermute mal schwer, daß darwolf im urlaub ist und sich die sonne auf den bauch scheinen läßt, umringt von mehreren hübschen jungen vollbusigen bikingirls, die sich darum reißen ihn bedienen zu dürfen.