Bei mir tritt es sehr oft auf und schon nach relativ kurzer Laufzeit und ich habe mehrmals gar nichts gemacht am Rechner.....also nix mit "Anwender selbst" ;)
Also inhaltlich würde es mit der Einstellung "PRIO" nach meiner bescheidenen Meinung passen. testen mag ich imo nicht... hab gerade mal seit längerem nen guten Lauf ;) wird aber nachgeholt.

ich möchte mal eine kurze Erklärung abgeben, damit ihr den Zusammenhang des Möglichen Fehlers erkennt.

Neben eurer Downloadliste die ihr sehr, gibt es auch eine Downloadliste (die filelist) die ihr nicht seht.
Bekommt ihr download läuft nun folgendes in der offiziellen Version ab:
Nacheinander werden erst die Dateien mit Hoher Prio, dann normal, dann niedrig durchgegangen und die Daten der übertragenen Clients abgeholt.
Nun kann es ja sein, daß ihr z.B. ein Downloadlimit von 20 kbs habt. Angenommen dieses Limit ist bereits nach Abarbeitung der ersten 3 Dateien erreicht, so werden von den restlichen Dateien keine Daten mehr abgeholt. Der Download bricht ab.
Anders läuft dies beim Xtreme (bzw. Maella):
Unter der Vorraussetzung man hat ein eingetragenes Downloadlimit (z.B. 20 kbs):
Nachdem die Daten der ersten Datei mit höchster Prio der Filelist abgeholt wurden, so wird dieses File ans Ende der Liste platziert. Das geht nacheinander so, bis das Downloadlimit erreicht wurde.
Beim nächsten Durchgang sind nun die Dateien oben in der Liste, von denen zuletzt kein Download abgeholt werden konnte, da Limit erreicht. Von diesen Dateien wird also beim nächsten Durchgang die übertragenen Daten eingeholt, was zur Folge hat, daß kein Download abbricht.

Nun kam seit den 0.30x Versionen Slugfillers Checkdiskspace hinzu, der bewirkt, daß falls der Plattenplatz nicht ausreichend ist, vorzeitig Dateien gestoppet werden. Natürlich sollten erste die Dateien gestoppt werden mit niedriger Prio. Aus diesem Grund wird die Filelist sobald irgendetwas an der Filepriorität geändert wird nach Priorität sortiert.
Genau diese Sortierung könnte sich mit oben beschriebenen Maella-Algorithmus beisen.

Mögliche Patches wären:
a) Falls erneut nach Prio sortiert wird, Maellas Alorithmus (abgearbeitete Files unten in die Liste hängen) für den momentanen Durchgang deaktivieren. Bin mir allerdings nicht sicher, ob das hilft. Ist allerdings für die nächste Beta Version schon mal implementiert.
b) Maellas Algorithmus deaktivieren und die offizielle Version benutzen
c) Das Sortieren nach Priorität deaktivieren. (bisherige emule-Versionen kamen auch gut ohne dieser Option aus).

@Xman

Mache wie Du es denkst nur bitte soschnell wie möglich da es echt langsam Nervt wenn dein Mod andauernd Abstürzt.

erst mal muß ich wissen ob der Fehler tatsächlich weg ist, wenn keine Auto-Downloadprio und 0 bei Downloadlimit.
Möglicherweise ist es ja auch ein Trugschluß, daß der Fehler hier liegt und ich such an falscher Stelle. Aber... Du bekommst gleich mal ne PM von mir ;-)

Hoffendlich liegt es daran!
Damit der Fehler endlich gefunden wird denn der Mod ist ja sonst erste Sahne aber das weis du ja.

Hoff'ma es ...

Aber ... etwas rall i trotzdem net:
Wenn man ein DL Limit von über 80 kB/s eingetragen hat ... die Rate wird doch kaum erreicht ... zumindest schaff ich das nie (bis auf einmal, da hatte ich für 10 Sekunden 96 :roll: :D ) Also wie kann es dann zu diesem Konflikt kommen? Es kann natürlich sein, dass ich den Begriff des Downloadlimits missversteh. :?

also sorry x-man aber momentan läuft deine letzte sehr gut durch !
25 Std. überstanden.
aber wir werden testen

Thommy,
es kommt nicht darauf an was Du erreichst, sondern was Du eingestellt hast.
Ganz simpel der Code:
Wenn Downloadlimit vorhanden, dann vertausche filelist-Listeneinträge, sonst (Dwonloadlimit=0) laß die Liste wie sie ist.

hmm, jetzt seh ich das sogar:
hab Limit auf 0 und der saugt zu Anfang nur die Dateien mit hoher Prio, vorher ging das ziemlich gemixt zu.

Xman,

bei mir ist download limit = download kapazität ( = 250 :mrgreen: ), werds mal mit 0 probieren!!!

seit letztem post ( alle prios auf normal ) läuft der mod 13,5h ohne freeze .. :D
vielleicht schaff ichs ja auch mal bis zur zt..

warum kriege ich bei der neue version jetzt ewig die meldung "your client is connecting to fast, it will get banned ?

gut habe jetzt nachrichten nur von freunden wieder aktiviert, aber interessant ist es doch schon

@ Tarod`s Son, habe ich auch bekommen. es waren immer die gleichen
clients, die diese meldung verschicken. da habe ich mir den spass gemacht,
eine send message die textseite komplett voll mit immer wieder dem gleichen satz an diesen client zu schicken.

kann natürlich sein, daß es wirklich nur einer dieser üblichen Fehlalarme war. Bischen was hab ich allerdings am Code hier geändert... allerdings sollte er damit eher langsamer/seltener verbinden ;-)

ps. wenn nachrichten an, waren es max. 3 clients, die diesen dummtext verschicken.

das Problem bei sowas ist, daß 99% aller Clients keine solchene Meldung schicken. Im Endeffekt merkt man nur, daß etwas nicht stimmt, wenn der Download schlecht ist (weil man zu viel gebannt wurde). Aber da hatte ich bisher mit meinem Mod noch nie Probleme ;-)

nee für schlechten download steht dein mod nun wirklich nicht !
wenn ich mal die chance bekomme, das er laufen kann, dann ist ein guter download gewiss !

auch wenn er erst seit einer stunde läuft so finde ich meine downfailed / 48 % und upload failed 32 % ziemlich hoch ! Downloads failed 12 und upload 6 !

als grund fast auschließlich others, da war der vorgänger aber auch am anfang niedrieger

übrigens...
es ist wirklich unfaßbar.. aber es gibt Dateien, welche jeden emule Abstürtzen lassen, wenn man sie lädt.
Hab heute soetwas im offiziellen Forum gefunden und nur noch den Kopf geschüttelt. Warum das so ist, ist allerdings sehr sehr tief in der Socketverwaltung begraben, vielleicht sogar ein MS Problem.

So, hat mir keine Ruhe gelassen und hab ihn doch angemacht.
Prio alles auf normal gestellt und Downlimit auf 0. Mal sehen was passiert ;)

So, jetzt hat es mich auch erwischt.
Nach der zweiten ZT hat sich der Esel verabschiedet.
Es kam nur die Meldung: Diese Anwendung wird ......!
Bin wieder auf 1.2 umgestiegen.
Der hat sich noch nie verabschiedet.
Gruß
digispezi

Xman,

oder so etwas: http://www.emule-web.de/board/viewto...?p=86839#86839
Ob das jetzt wirklich einen Wahrheitsgehalt hat, kann ich Dir aber nicht mit Sicherheit sagen.

Januar

@ Januar1956, die habe ich auch in meiner ip-filter.dat eingetragen.
und zwar seit dem tag, an dem dieses post zum 1. mal hier erschien.
versuch macht klug !

Gucky,
Ich glaube kaum, dass die mit festen IPs arbeiten, insofern ist das
schon wieder Schnee von gestern.

Januar

Januar1956
und wenn schon. dann verzichte ich halt eben auf ein paar clients.
und wenn nicht, auch gut.

Gucky,

Ok, hier für Dich noch eine aktuelle, Handgestrickte: http://membres.lycos.fr/meuh6879/IPfilter/IPfilter.dat

Januar

ich verwende "auto prio." und bei mir sind überall werte eingestellt. bei dem gefragten downloadlimit sind es
kapazität 192
limit 180

upload
kapazität 32
limit 18

ich verwende allerdings nicht nur "auto prio." viele files stehen auch auf "release" oder aber auf "sehr niedrig"

@ lexaiden, mit "release" oder "sehr niedrig" arbeite ich auch problemlos.
nur halt eben nicht mit "auto prio". ist doch nur für die quellenverteilung gut.
da ist für mich A4AF die bessere lösung, aber nur für den fall, das nicht genug quellen
bei einem file vorhanden sind (da nehme ich dann das automatisch zuweisen)

eMule v0.30c [Xtreme 2.0b3] Statistics

Transfer
Session UL:DL Ratio: 1 : 1.32
gesamte UL:DL Ratio: 1.07 : 1
Uploads
Session
Hochgeladen: 608.28 MB
Aktive Uploads: 6
Wartende Uploads: 2203
Upload Sessions: 146
erfolgreiche Upload-Sessions (total): 128 (87.67%) (active: 6, timeover: 19, new chunk: 73, cancelled/ended: 10, different file: 0, exception: 1, others: 19)
fehlgeschlagende Upload-Sessions (total): 18 (12.33%) (timeover: 0, new chunk: 0, cancelled/ended: 1, different file: 0, exception: 0, others: 17)
durchschnittlicher Upload pro Session: 4.75 MB
durchschnittliche Upload-Dauer: 30:23 Minuten
Totaler Overhead (Pakete): 44.89 MB (1.33M)
Gesamt
Downloads
Session
Heruntergeladen: 801.57 MB
beendete Downloads: 0
Aktive Downloads: 11
Gefundene Quellen: 3692
Download Sessions: 312
erfolgreiche Download Sessions: 254 (81.4%) (active: 11, paused: 0, no needed part: 5, corruption: 0, timeout: 53, cancelled: 0, out of part: 46, exception: 0, others: 139)
fehlgeschlagende Download Sessions: 58 (18.6%) (paused: 0, no needed part: 1, corruption: 3, timeout: 9, cancelled: 0, out of part: 3, exception: 0, others: 42)
durchschnittlicher Download pro Session: 3.16 MB
durchschnittliche Downloadzeit: 23:31 Minuten
durch Komprimierung gewonnen: 7.69 MB
durch Datenfehler verloren: 9.28 MB
Teile gerettet durch I.C.H: 1
Totaler Overhead (Pakete): 45.39 MB (1.19M)
Gesamt
Verbindung
Session
Allgemein
Erneute Serververbindungen: 0
aktive Verbindungen (geschätzt): 205
durchschnittliche Verbindungen (geschätzt): 206
Verbindungsspitze (geschätzt): 287
Verbindungs-Limit erreicht: 151 : 12/06/03 20:17:05
Upload
Download
Download-Geschwindigkeit: 35.55 KB/s
Durchschnittliche Downloadrate: 13.13 kB/s
Max Downloadrate: 45.95 kB/s
Max Downloadrate Durchschnitt: 13.13 kB/s
Programm-Laufzeit: 17:22 Stunden
Übertragungszeit: 17:22 Stunden (100.0%)
Dauer auf aktuellem Server: 17:22 Stunden (100.0%)
Dauer auf Servern: 17:22 Stunden (100.0%)

Laufzeit ~17h mit den Prios auf NORMAL (also Auto aus) und Downlimit auf 0. Noch läuft er und gar nicht mal schlecht. Spätestens heute Abend weiss ich mehr ;)

finde ich gar nicht ! deine others download failed und up failed sind genauso hoch wie bei mir ! ich lasse es normal mit pri und 0 laufen, also denke ich mal das x-man da irgendwas zu hart oder zu langsam eingestellt hat.

session 1/1.32 (allerdings nur 7 files mit gesamt 1600 quellen)

Zufall?
 

Also ich weiss nich, aber mir ist schon wieder etwas Komisches passiert, was ich zuvor noch nie hatte:
Nachdem ich das DL-Limit auf 0 und die prios auf hoch/normal gestellt habe (also autoprio aus), konnte ich nach gut 5 Stunden plötzlich keine einzige Seite mehr aufrufen. :shock: :? Sowas hab ich noch nie erlebt, ging einfach nichts mehr ... der Esel lief aber 24 Stunden durch. Hab ihn jetzt doch mal ausgemacht und system restartet, jetzt gehts wieder. Mal schaun obs nochma passiert. Schon lustisch ... :roll:

Das mit den failed (others) hab ich noch nicht so beobachtet :lol: :lol:
ABER; für mich ist der Wert bei Ups : 87,67% und Downs : 81,4% am wichtigsten. Daran hab ich mich immer orientiert, und das ist ein guter Wert :mrgreen:

Hier mal meine Stats

eMule v0.30c [Xtreme 2.0b3] Statistics [eMule0.30c.[sivka]]

Transfer
Session UL:DL Ratio: 1 : 3.69
gesamte UL:DL Ratio: 1 : 1.51
Uploads
Downloads
Session
Heruntergeladen: 501.31 MB
beendete Downloads: 4
Aktive Downloads: 36
Gefundene Quellen: 4648
Download Sessions: 290
erfolgreiche Download Sessions: 207 (71.4%)
fehlgeschlagende Download Sessions: 83 (28.6%)
durchschnittlicher Download pro Session: 2.42 MB
durchschnittliche Downloadzeit: 19:20 Minuten
durch Komprimierung gewonnen: 11.48 MB
durch Datenfehler verloren: 0 Bytes
Teile gerettet durch I.C.H: 0
Totaler Overhead (Pakete): 6.98 MB (213K)
Gesamt
:mrgreen:

wow, mein Xtreme-2.0b3 ist jetzt ~26h am laufen..!!! :mrgreen:
hat er vorher noch nie geschafft, bin schlicht sprachlos :mrgreen: :mrgreen:

und die zt scheint mein provider auch vergessen zu haben: bin schon 26h online! :shock: :roll: :lol: 8)
was solls.. bin ja noch jung.. ich kann warten!!!

@Xman,
alle prios sind auf normal, limit down steht auf 0.. das scheints echt zu reissen!!!

gute Nachrichten...
Ich bin nun ziemlich davon überzeugt, daß eure Probleme von diesem auf der letzten Seite beschriebenen Bug herrührten.
Ich hab meinem Patch nun noch den letzten Feinschliff gegeben und laß gerade mal wieder meinen emule bei mir selbst laufen um die letzten Tests zu machen. (nachdem ich meine emule-datein endlich von der kaputten Festplatte mit einer Übertragungsrate ala 56 k Modem geholt hab).

Die Beta 4 werd ich dann morgen veröffentlichen. Danach stürtz ich mich auf die 0.30d, was nicht zu viel Arbeit sein wird. Und danach gibts dann endlich neue Features ;-)

Wie ihr seht läuft die Beta4 bei mir Super ohne Probleme[Siehe Sig].

Drückt die Daumen das die Beta4 Morgen von Xman freigegeben wird denn der Mod ist wieder da wo er hingehört!

Daumen hoch Xman Super Arbeit! :D

Hrr, nice work, wenns wirklich daran lag. Freu mich schon drauf. :D

Meine läuft auch noch ;) Nun so ca 27h, ZT war auch schon. So ist aus meiner Sicht der Fehler "gefunden" worden (i hope so :lol: ) Wollen mal nicht zu schwarz malen...

Juhu freuhe mich mal auf die beta 4, bis dahin tut es auch ncoh die beta3 ihren Dienst hehe und sie leuft endlich über die 24 Stunden rüber warrum jetzt auch immer..! Aber auch UL / DL 1:2 :lol:

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

Transfer
Session UL:DL Ratio: 1 : 2.27
Cumulative UL:DL Ratio: 1 : 2.07
Time Statistics
Session
Runtime: 1 days 2:41 Hours

Xman, anscheinend hast du den Fehler wirklich gefunden :). Wenn der Mod heute noch durchläuft isses sicher, 48h hat er bei mir noch nie gepackt ;).

Bei mir lief die Beta4 48Std. also muss der Fehler gefunden worden sein.

scheint wirklich an der auto-prio gelegen zu haben, wenn ich das hier so lese.

die b2 lief bei mir am stück über eine woche. die b3 musste nach 3 tagen ein
päuschen machen, wegen dringender einstellungen im bios. kann meine
patschfinger einfach nicht davon lassen. die b4 läuft läuft seit 1 tag 17 std. mit
den mir von diesem mod her bekannt guten werten. die ul-linie hat sich beim b4
sogar noch etwas beruhigt. also hat in diesem bereich die optimierung etwas gebracht.