eMule-0.30e-gnaddelwarz-1.3.2 [18.12.2003]

[Januar1956]

Einmal Gnaddelwarz, immer Gnaddelwarz

Weiter vorne im Thread findest Du eine Antwort auf Deine Frage.








Januar

[hubutz]

Sorry, voll verplant, löschen kann ich den Beitrag net mehr...

Aber ich glaube du musst die clients.met.SUQWTv2.met.BAK nehmen (wenn ich mich nicht total irre)...

[Hopie]

Zitat von Januar1956

Einmal Gnaddelwarz, immer Gnaddelwarz

Weiter vorne im Thread findest Du eine Antwort auf Deine Frage.
Januar

ja, da sollte ich glaub die 30d.bak oder so nehmen.. ABER die is dann auch veraltet

[atzekalle]

ähm ... nur mal so ...

der bug mit Iplist und fakelist ist immer noch..

es wird immer noch nur in verbose angezeigt, dass man die neuste version hat. aber nicht in log. ......

[Kaeptn_Sperrmuell]

Hi atzekalle,

das manuelle Aktualisieren der beiden Listen funktioniert einwandfrei. Machst es halt manuell und Du weisst, dass es so ist.

Gruesse
Kaeptn

[Kaeptn_Sperrmuell]

Thema SUQWT
Gnaddelwarz schrieb

der Client kommt nun nach 3 Tagen wieder um eine Datei anzufragen. Dieser Client beginnt nun nicht mit 0 sondern mit 8 Stunden Wartezeit

kann ich leider nicht bestaetigen...
Ein mir bekannter User, der vor einer Woche meine Warteschleife betrat und wieder auf telefonische Anweisung sie verliess, kam heute zum ersten mal seit 7 Tagen wieder rein und siehe da:
Er hat eine Wartezeit von 12 Tagen!

Demnach ist meine Theorie mit "Ich mache mich mal publik und komme in einer Woche wieder mit einem QR1 und habe ruckzuck einen MoerderDownload" korrekt.
Dieser User hat mir am Telefon bestaetigt, dass er auch bei einem zweiten User einen QR1 hatte.
Leider habe ich keinen tel. Kontakt zur zweiten Quelle, sonst haette ich dort die "Wartezeit" angefragt.

Der mir persoenlich bekannte Client war definitiv NICHT die letzten 7 Tage in meiner Queue, da er seinen Rechner abgeschaltet hatte
Mit 8 Stunden (wie oben beschrieben koennte ich leben, da er schonmal da war, aber 12 Tage gleich zu akkumulieren ist schon heftig).

Die User die bei mir aktiv Downloaden, deren Zeit wird korrekt berechnet nach abgeschlossenem DL. -> u.U. 40 Minuten, wenns schnell geht

Kann noch jemand so etwas bestaetigen, nicht dass ich als "Dampfplauderer" dastehe???

Dies nur so am Rande.

Gruesse
Kaeptn

[luka]

Ich hatte das selbe auch ein paar Seiten vorher geschrieben.

Da ich, kurz nachdem die Version mit SUQWT erschienen ist, den Muli eine ganze Woche nicht in Betrieb hatte, konnten die Leute niemals auf eine Wartezeit von über 9 Tagen gekommen sein. Die Zeit, in der ich gar nicht online war, wurde ihnen aber angerechnet.

Ausserdem ist mir noch etwas aufgefallen. Wenn ein Client bei mir läd, der Vorgang aber nicht abgeschlossen wurde (also vor Erreichen der 10 MB Marke) bekommt er die gesamte Wartezeit wieder zugeordnet.
So habe ich hier einige Leute, die ich ständig wieder sehe, deren Download nach etwa 8,5 MB abbricht und die spätestens nach 1 Stunde wieder im Upload sind, mit einer noch höheren Wartezeit. Und so geht das immer weiter.

[atzekalle]

Zitat von Kaeptn_Sperrmuell

Hi atzekalle,

das manuelle Aktualisieren der beiden Listen funktioniert einwandfrei. Machst es halt manuell und Du weisst, dass es so ist.

Gruesse
Kaeptn

hää? ....

man ...

die AKTUALISIERUNG funktioniert doch!!!!!!

es steht halt nur im flaschen log.

gnaddel weiss was ich meine, ich hab ihm ja schon mal darauf aufmerksam gemacht. er meinte das er das in der letzten beheben würde.

nunja ...
sieht ja nicht so aus

[jazman187]

hallo

in letzter zeit erhalte ich des öfteren im verbose log die meldung:
unknown eDonkey opcode: 0x6a, size=20, data=[c8 bd 3e 4c 2f 42 6d 9a 07 c4 89 38 46 0d 61 98 45 0b 00 00 ]

ist das normal bzw. habt ihr auch solche meldungen beobachten können

gruß
jazman187

[Gnaddelwarz]

Zitat von luka

Da ich, kurz nachdem die Version mit SUQWT erschienen ist, den Muli eine ganze Woche nicht in Betrieb hatte, konnten die Leute niemals auf eine Wartezeit von über 9 Tagen gekommen sein. Die Zeit, in der ich gar nicht online war, wurde ihnen aber angerechnet.

Falls du Version 1.3.1 meinst, da war das auch alles kaputt. 1.3.2 sollte gehen, nachdem das aber wohl doch öfter vorkommt, wird SUQWT in der nächsten Version abschaltbar sein.

Ausserdem ist mir noch etwas aufgefallen. Wenn ein Client bei mir läd, der Vorgang aber nicht abgeschlossen wurde (also vor Erreichen der 10 MB Marke) bekommt er die gesamte Wartezeit wieder zugeordnet.
So habe ich hier einige Leute, die ich ständig wieder sehe, deren Download nach etwa 8,5 MB abbricht und die spätestens nach 1 Stunde wieder im Upload sind, mit einer noch höheren Wartezeit. Und so geht das immer weiter.

Eigentlich sollte die Wartezeit resettet werden, wenn der Client den Download abbricht. (Wenn wir den jedoch rausschmeissen, um z.B. Platz für einen PS-Upload zu machen, dann wird die Wartezeit beibehalten)

[Kaeptn_Sperrmuell]

[Quote Gnaddelwarz]
...wird SUQWT in der nächsten Version abschaltbar sein

Welch Ausblick!
->Hatte mit meinem zweiten Rechner mal ein File von meinem ersten Rechner angesaugt, rausgegangen, nach einer Woche (eMule lief durch) wieder testmaessig angesaugt und siehe da: QR1
Klar, Wartezeit 6,75 Tage
bei Ver. 1.3.2

Der Ansaugtest war, um zu sehen, wie das COS greift...

Nochmals:
TNX!!!!!!

Gruesse
Kaeptn

[Gnaddelwarz]

Zitat von Kaeptn_Sperrmuell

->Hatte mit meinem zweiten Rechner mal ein File von meinem ersten Rechner angesaugt, rausgegangen, nach einer Woche (eMule lief durch) wieder testmaessig angesaugt und siehe da: QR1
Klar, Wartezeit 6,75 Tage
bei Ver. 1.3.2

Der Ansaugtest war, um zu sehen, wie das COS greift...

Ok, mittlerweile bin ich überzeugt.....
Falls du noch einen anderen Test machen willst, würde mich mal interessieren:
Selber Test wie von dir beschrieben, nur umgekehrt.
(Also statt: anfragen, Downloader eine Woche deaktivieren, neu probieren
=> anfragen, Uploader eine Woche deaktivieren, neu probieren.)

Falls da dann "normale" Zeiten (also nicht eine Woche) rauskommen, weiss ich glaube ich, in welcher Richtung der Bug liegen könnte....
(Ob der dann allerdings im ursprünglichen SUQWT-Code oder im Zusammenspiel mit meiner Version liegt, keine Ahnung).

Ansonsten kommt die nächste Version dann bald.

[Kaeptn_Sperrmuell]

Hi Gnaddelwarz,

gerne bin ich fuer den Test bereit, kein Thema
Ich lasse den Testdownlaoder einen Chunk laden, damit seine Zeit auf 0 (hoffentlich zurueckgesetzt wird) und wuerde den eMule fuer 2-3 Tage mal abschalten. -> ich helfe vielen Leuten beim MitRelease

Reicht die Zeit?
Ansonsten werde ich die Zeit (1 Woche) nutzen und mal mein Kabelgewirr aufzuraeumen und die hardware ein wenig umbauen (Luefter austauschen).

Mit einer Woche abgeschaltet... wow... das wird hart... aber bei einem moemtanen DL von sagenumwobenen ~10 kBs kann ich es zur Not echt verkraften.

Gib bitte Bescheid, ob 2-3 Tage ausreichen oder >7 Tage aussagefaehiger sind. Ich machs, keine Frage, wenn Dir (und uns anderen) geholfen ist, gerne!

Mir kommt der Verdacht auf, dass eine Variable (ich nenne sie mal so) "LastSeen" anstelle von "WaitingTime" vertauscht ist.

Gruesse
Kaeptn

[twinshai]

Moin Leuts,

bin neu im Forum und muss euch Experten gleich mit ner Frage nerven. Habe die 30e-Version drauf und würde nun gerne den Gnaddelwarz-Mod aufsetzen. Muss ich den komplett neu installieren oder reicht das Austauschen der EXE-Datei?? Was ist bei der Umstellung sonst noch zu beachten

Greez und Danke

twinshai

Habe mal nen paar Mods getestet und habe mich wieder fuer den Gnaddelwarz entschieden da er das erste mal am besten lief ....

... doch nun ist mir aufgefallen das im upload nur ein Slot belegt wird ...

... dadurch schwangt mein upload sehr (zwischen 3/14) was folglich den Download beeinträchtigt.

Ist das normal oder wo kann ich die umstellen

THX im Voraus