Queue leer nach ASFU: Reloading...
 

Moin, moin,

bin neu mit dem Stulle und werde von den Einstellmöglichkeiten schier erschlagen.

Habe folgendes Problem:

Nach jeder Fertigstellung eines Downloads kommen im Log die Meldungen:

ASFU: Detected change on shared folders, reload of shared files in 5 seconds...
ASFU: Reloading..
Server, Sendlist: Packet size xxx

Währenddessen (oder direkt danach) verlieren die Filees im Upload-Fenster kurz Ihren Namen und zeigen währendessen ein Fragezeichen, und die Queue wird geleert. Völlig!

An welchem Schalter muss ich drehen, um das Leeren der Queue zu unterbinden?
Das automatische Reload ist schon abgeschaltet, scheint aber nicht zu wirken, wenn der Reload durch das Fertigstellen einer Datei ausgelöst wird.


TIA
carlo

Nachtrag: Nachdem ich den Muli neu gestartet habe, wird nicht mehr nach jedem fertigen Download ASFU gestartet. Der Parameter "automatisches Reload " = aus wirkt jetzt anscheinend. Ein manuller Reload bleibt ohne Folgen für die Queue.

Hast du auch eine saubere Installation gemacht?

JA SPITZE!!!!

das is doch genau das was ich wissen wollte!!!!! :clap

ich danke vielmals!!!

DJ double U

Wunsch für StulleMule: Umschalter für Download Chunk Auswahlmethode
 

Hi,

Wäre es möglich in den nächsten StulleMule einen Umschalter für die Download Chunk Auswahlmethode wie im Xtreme Mod zu integrieren?

Seit eMule v0.47c wird der runterzuladende Chunk nach zz (Fokusierung möglichst vieler Uploader auf einen Chunk) organisiert. Ich halte das für eine Netzwerkschädigende Verschlimmbesserung die für ALLE Beteiligten (Uploader und Downloader!) nur Nachteile bringt.

Der Uploader mit nur geringer UL Bandbreite wird von Clients mit hoher UL Bandbreite verdrängt und um die Möglichkeit Credits zu sammeln gebracht; der DL des Uploaders wird somit ausgebremst (wg. CS-System).

Der Downloader muss länger auf die Fertigstellung der DL-Datei warten.

Das Netzwerk wird dadurch unnötig zeitlich länger belastet, es entsteht damit natürlich auch mehr unnötiger Overhead.

Die tranditionelle Maella Methode (von jedem Uploader ein anderer Chunk) ist mMn wesentlich effizienter; für alle, ULer und DLer. Damit wird eine deutlich breitere Streuung der Chunks bewirkt wodurch sich die Datei sicher auch schneller verteilt.

Viele Grüsse, Tom

PS.: in der nächsten offiziellen eMule Version sollten die Entwickler wieder zurück zur Maella Methode kehren!

Da ich einen Plattencrash hatte....
Die Installation war nicht nur sauber, sondern rein.

Sorry, aber auf Einzelschicksale, die sich von ihrem 56k Modem nicht trennen wollen und auch ansonsten, sich zur Geiz ist Geil Gesellschaft zugehöhrig fühlen, kann leider keine Rücksicht genommen werden. :mrgreen:

Aber im Ernst, Deine Ansicht ist völlig falsch. Das Prob fürs Netzwerk, ist weder das Zzul- noch das Maella System. Das Prob liegt darin, das der normalo User den Vollchunkupload aktiviert. In diesem Modus, werden Anfragen nach Chunkteilen, also keine ganzen Chunks, erst u.U. nach vielen Stunden, oder Tagen bearbeitet. Anders im Modus "kein Vollchunkupload", hier werden solche Anfragen bevorzugt abgearbeitet. Dieses im Gesamtzusammenhang des Netzweres, mit mehreren MIO Usern, ist zu einem gigantischen Uploadprob angewachsen, dem versucht jetzt das neue System entgegenzuwirken. Der Vorteil, ist eine deutlich schnellere Verfügbarkeit, der betroffenen Chunks. Dieses neue System ist demzufolge ein Reingewinn fürs Netzwerk.

Januar

Hallo,

Diesen "bug" kann ich auch bei eingeschaltetem ASFU bestätigen, ich habe dieses Problem normalerweise nicht, allerdings habe ich momentan den Esel echt viel aufgehalst zum ziehen (was auch topp geht).
Aber mein System hat wirklich schwer zu Arbeiten (stört mich aber nicht weiter, da es ein extra Rechner nur für mule ist). Ich vermute stark, das leeren der Queue geschieht, weil das Sytem einen kurzzeitigen Hänger hat, da es ausgelastet ist. ???? Vielleicht benötigt das ASFU kurzzeitig hohe CPU , was bei starker Auslastung zum Hänger kommt ???

So würde ich es aber nicht sehen. Client wohnt 8 Kilometer vom DSL-Verteiler weg.
Er/sie haben kein ISDN und bekommen wegen der weiten Entfernung vom Verteiler kein DSL.
Tja und damit sie sie angeschmiert. Ich kenne sogar 2 Leute, wo dieses. zutrifft.

Hi,

Um die ging es mir weniger. Es gibt ja auch noch den TrickleSlot. Nach meiner Beobachtung werden recht häufig Downloads (auf einen Chunk bezogen) mit niedriger Datenrate eben von anderen Clients mit hoher Datenrate einfach verdrängt. Wenn der Client mit niedriger Datenrate (z.B. im TrickleSlot) keinen weiteren Chunk zu bieten hat, -> Abbruch, Pech für ihn (weniger Credits) und Pech für mich (weniger Download). Wenn nun aber der Client mit hoher Datenrate einen anderen Chunk beginnt hochzuladen als der mit niedriger Datenrate ist das von Vorteil für ALLE! Der im TrickleSlot laufende DL kann weiterlaufen, schaltet irgendwann in einen normalen UL, bekommt seine Credits und ich meine gewünschten Daten. Der mit hoher Datenrate beschenkt mich zeitgleich! mit einem weiteren Chunk über den ich mich freuen kann :mrgreen:
Der geschilderte Fall trat in älteren Versionen merkbar seltener auf.

Da bekomme ich jetzt aber ein Verständnis Problem.
Soweit ich weiss werden alle Dateien in Chunks mit 9,28MB Grösse aufgeteilt.
Z.B. 92,8MB Dateigrösse wären genau 10 Chunks.
Wenn nun der eigene Client möglichst nur vollständige Chunks senden soll dann habe ich es so verstanden, dass er erst dann einen Chunk zum UL freigibt wenn der Chunk auch komplett vorhanden ist. Was aber nicht heisst, dass der Empfänger von diesem Chunk nicht schon von einem anderen Client Teile bereits erhalten haben kann; er also einen unfertigen Chunk von meinem Client fertiggestellt bekommt. Möglichst vollständigen Chunk übertragen bedeutet somit lediglich dass möglichst immer 9,28MB (= Chunkgrösse) ausgehend von einem bei mir vollständig vorhandenen Chunk übertragen werden die sich dann aber auf mehrer Chunks beim Empfänger verteilen können; das entspricht auch so meinen Beobachtungen.
Warum sollten nun durch Aktivierung des Vollchunk-UL unfertige Chunks über unmässig lange Zeiträume nicht bearbeitet werden, leuchtet mir nicht ein. Der Client sollte unfertige Chunks bevorzugt anfordern, bekommt diese dann von Clients die den Chunk bereits komplett zur Verfügung stellen können und ein weiterer Chunk wird angefangen nur nicht fertiggestellt da nur 9,28MB + Blockfertigstellung übertragen werden. Ich meine man sollte eher hier ansetzen und das UL-Verhalten dahingehend ändern dass bei angefangenen Chunks grundsätzlich versucht wird diese fertigzustellen und damit das fix eingestellte UL-Limit von 9,28MB (9,28MB = Chunkgrösse aber =! "vollständiger Chunk") stattdessen dynamisch zu regeln. Dann entstehen automatisch nurnoch sehr wenige unfertige Chunks und das "Problem" erübrigt sich von selbst. Ursachenbekämpfung statt an Symptomen rum-zu-doktoren ;)
Das wäre progressiver Fortschritt/Verbesserung :yes:

Viele Grüsse, Tom

PS.: ob eine wie oben beschrieben dynamische UL Regelung machbar wäre kann ich nicht beurteilen; bin nicht vertraut mit den Interna/Protokollen von eMule. Ist als theoretische Überlegung zur Diskusion gestellt.

@ Tom-XT

Werf mal einen Blick in Deine Statistik und sieh Dir mal Deine Werte für:
a, durchschnittlicher Upload und
b, durchschnittlicher Download an,

vielleicht wirds dann verständlicher. eMule fragt niemals nach einem vollen Chunk nach, sondern nur nach ein paar kb, wenn der angefragte User aber Vollchunkupload aktiviert hat und zudem auch noch, einer von wenigen Quellen ist...ist Sanktnimmerleinstag angesagt...wenn er nicht sogar die Dat aus dem Share nimmt. Im neuen System besteht eine deutlich bessere Aussicht auf Erhalt der Dat.

Januar

Hmm, nö, der Blick in die Statistik macht mir diesbezüglich nix klarer, ich sehe nur, dass ich im Schnitt mehr Up- als Download habe.

a, durchschnittlicher Upload/Session: 9,18MB
b, durchschnittlicher Download/Session: 6,25MB

hab ich Tomaten auf den Augen, stehe auf der Leitung :?:

Wenn eMule nur ein paar KB anfragt, der angefragte Client diese paar KB in dem zugehörigem Chunk verfügbar hat, dieser Chunk beim angefragten Client dann vollständig vorhanden ist, er Vollchunkupload aktiviert hat, dann muss ich doch nicht länger warten als wenn er Vollchunkupload deaktiviert hat. Nur wenn der Client diesen Chunk NICHT vollständig hat heisst es warten da der Chunk respektive die von meinem Client gewünschten KBs nicht zum UL freigegeben sind. Oder ist das falsch?

Vollchunkupload bedeutet ja nicht dass NUR vollständige Chunks (9,28MB!) hochgeladen werden können, wenn dem so währe, würden Dateien ja teilweise NIE fertiggestellt. Z.B. Stichwort 24std Zwangstrennung die jeden UL/DL nunmal unterbricht und damit unfertige Chunks erzwingt.

Vollchunkupload bedeutet, so hab ich es jedenfalls bisher verstanden, dass nur vollständig vorhandene Chunks zum UL freigegeben werden und eben besagte 9,28MB (Chunkgrösse) versucht werden zu laden; unabhängig davon ob der Empfänger nur wenige KB/MB dieses Chunks benötigt. Was über die wenigen angefragten KB/MB hinaus geht wird, wenn möglich, von einem nächsten Chunk geladen oder der UL wird abgebrochen. Das ist was ich auch so beobachten kann.

Daher mein Verständnis-Problem.

Viele Grüsse, Tom

Nö, so ist es nicht. Vollchunkupload bedeutet, es wird jeder einzelne, schön brav, der Reihe nach abgeschickt...Vielleicht doch mal wieder eine eMulehilfe Lesestunde einlegen. :-)
Grundsätzlich landet jede Anfrage auf Platz 5.000 der Warteliste. Eine kleine Dat Nachfrage, wird bevorzugt abgearbeitet, wenn Vollchunkupload nicht eingeschaltet ist. Ist er eingeschaltet, muß sie gnadenlos durch, so lange es auch dauert und so weh es auch tut.
Daran hat sich zwar jetzt auch nix geändert, aber durch das Bedienen des einzelnen Chunk durch, wieviel auch immer User...wird diese Schmerzerfahrung gelindert.

Januar

Vollchunkupload bedeutet, es wird jeder einzelne, schön brav, der Reihe nach abgeschickt...Vielleicht doch mal wieder eine eMulehilfe Lesestunde einlegen. :-)

:mrgreen: ok, ist schon länger her...

Wenn dem so ist, dann wird die Sache schon klarer.
Kleine Dats (kleiner als 9,28MB) share ich fast nie, in der Regel sind die Dats deutlich grösser als 100MB; daher auch keine Erfahrungswerte in der Richtung. Ich beziehe mich damit auf das Sharen grösserer Dateien und die dabei verwendete Chunkbehandlung.

Dank Dir und viele Grüsse, Tom

Du hast es nicht verstanden! Es geht nicht um die ganze Dat, sondern, um jeden einzelnen Chunk.
...macht aber nix...ist eh inzwischen etwas OT. :chuckle

Januar

Hallo,

Ich habe das Problem bei mir gefunden und auch eine Lösung parat:

Bei mir war die Funktion "emule process in high priority" aktiviert (standardmäßig ist die allerdings ausgeschaltet).

Da mein Rechner momentan wirklich stark ausgelastet ist und der StulleMule sehr viele Downloads drin hat entsteht hier der Flaschenhals.

Es sieht so aus: Verschiebt man die Datei, so startet der StulleMule unverzüglich ASFU (falls aktiviert).
Auf Grund dessen, dass der StulleMule aber high priority hat und das System bei mir schon an der Leistungsgrenze ist gibt es nun hier einen Hänger, Windows verschiebt die Datei, nahezu zeitgleich mit dem Start von ASFU, die I/O Anfrage kann aber von Windows nicht direkt abgearbeitet werden, da ASFU in high priority am Arbeiten ist, nun hängt der StulleMule für einen kleinen Moment (genau dann, wenn die Datei als fertig verschoben wurde), dies hat dann zur Folge, dass die Queue schlagartig geleert wird.
Ich konnte das heute den ganzen Tag über mehrmals reproduzieren.
Ich habe den StulleMule anschließend auf "normal priority" gestellt und gleiche Versuche erneut gemacht.
Nun ist der I/O Fluss gleichmäßig und Windows kann die Datei schnell genug verschieben und ASFU wird nicht behindert und der StulleMule hängt auch nicht, die Queue bleibt weiterhin gefüllt (habe ich auch mehrere male reproduziert).
Anmerkung: Das Verschieben fand bei mir nur auf der gleichen Festplatte statt, wie es ist, wenn von einer zur anderen Festplatte verschoben wird kann ich daher nicht sagen.
ich hoffe das hilft auch bei anderen Leuten mit diesem Problem.
Wünsche eine geruhsame Nacht.

Guten Morgen Stulle,

Ich habe hier ein crash dump für Dich, hoffe das hilft weiter.

Hallo Stulle,

Hier ein weiteres crashdump.

Stuule Noob
 

Hi!
Ich hab den Mod jetzt installiert aber hab keine Server/Servermet und kann auch nicht zu manuel hinzugefügten Servern verbinden.
Bitte helft mir, ich habs nicht drauf!
sinsemillah

@sinsemillah

http://www.emule-mods.de/?servermet=show

Server mit linker Maustaste anklicken.

Schau unter "Server".

Verbinden.


Grüße

tango

Habe mal eine frage
welche datein muss ich übernehmen....von alten zum neuen esel ?
das ich auch alles habe was ich hochgeladen freunde...usw...halt nur dich wichtiggsten sachen !

@ Tom-XT:

Ich war eine Weile offline und hab' den Thread daher verpaßt. Zur Klarstellung sei aber nachträglich angemerkt, daß Januar wie so oft kompletten Unsinn geschrieben hat. Warum er das regelmäßig tut weiß ich nicht, steht aber irgendwo zz drauf erfindet er den absurdesten Unfug um es schön zu reden. Auf Details gehe ich nicht ein, glaub's mir einfach oder lasse es. Aber bitte verbreite seinen Quatsch nicht weiter...

@ Muio:

cryptkey.dat
preferences.dat
clients.met
emfriends.met

Eventuell noch die server.met (oder halt eine neue nehmen) und bei nur-Kad-Betrieb die nodes.dat.

Mit freundlichen Grüßen
aalerich

Typisch Aalerich...immer schön mit verbundenen Augen...
Ich geb ja zu, daß es meine Sichtweise ist. Aber so ganz kann ich ja nicht falsch liegen, immerhin sind mit dem offiMule und auch den darauf basierenden Mods, also rund 99.5 % aller Nutzer sehr zufrieden.
Deswegen nochmal...Zz ist die Zukunft. :mrgreen: :mrgreen: :mrgreen:

Januar

Hilf mir mal auf die Sprünge. Was soll damit gemeint sein ?

...noch Fragen ? :chuckle

Thx und "Nein Danke"

Hi,

Es gab mal eine Zeit da waren 99% der Weltbevölkerung im festen Glauben die Erde ist eine Scheibe (ihre Sichtweise). Hatten diese 99% auch recht?
Noch Fragen?

Bitte Fakten und Belege bringen, nur damit kann man überzeugen. ;-)

Mich hat es nicht überzeugt, die aus meinen Beobachtungen resultierenden Fakten sagen mir, dass sich das DL-Verhalten seit v0.47c merkbar verschlechtert hat.

Viele Grüsse, Tom

Kann ich so nicht bestätigen, weil ein Blick in meine Statistik, zeigt mir, daß ich 17,45 GB, bei einer Laufzeit von 2 Tage 16:38 Stunden runtergezogen hab.
Find ich nicht übel. :beer:

Januar

Das sagt aber nu mal nix über das allgemeine DL-Verhalten aus, was währe wenn Du unter identischen Vorraussetzungen mit Maella geladen hättest? Vieleicht hättest Du dann noch ein paar MBs mehr geladen oder auch weniger?

Eine absolute Zahl zu nennen ohne aufzuschlüsseln wie diese entstanden ist sagt null-und-nix über die tatsächliche Qualität des Systems aus.

Viele Grüsse, Tom

Eigentlich hab und wollte ich damit keinen Vergleich zwischen den Systemen zum Ausdruck bringen. Mir gings lediglich darum herrauszustellen, dass Dein Empfinden, seit 0.47c sei der Download nicht mehr so gut, nicht für jeden gillt. Im Gegenteil, immer mehr User entscheiden sich für Internetangebote, die einen höheren Ubload zulassen. Ich behaupte mal, so aus dem Bauch heraus, dass ich momentan, gut doppelt bis dreimal soviel Download habe, als noch vor einem Jahr.
Und Maella...hmm, ich denke da ist die Geschichte schon drann vorbeigegangen, aber als eine "Nische" im Gesamtkonzept...warum nicht, schliesslich soll eMule ja für alle da sein.:chuckle

Januar

Erstens geht es nicht um die Menge der heruntergeladenen Daten, sondern um die Qualität, also die Seltenheit eines Chunkes, den ich lade und damit um den "Wiederverkaufswert". Und meine Statistik meldet einen Download von 169 mb in 1 Tag, 14 Stunden mit zz. (Warum ich das eingestellt hatte weiß ich gar nicht; vermutlich noch von einem Test und dann vergessen. :oops: ) Ist ja nicht viel, ist die zz-Methode deshalb schlecht? Laut Januar muß sie ja wohl...

Zweitens unterliegt Januar unverbesserlich dem Irrtum, der Uploader würde seine Slots in Abhängigkeit dessen vergeben, was der Sauger haben möchte. Das trifft bei Prioritäten / Powershare zu, beim vollen Chunkupload nicht. Vor Jahren habe ich mich von ihm damit auch mal verwirren lassen, es dann ausgiebig und gezielt getestet und versucht, es ihm beizubringen. Vergeblich, wie man sieht.

Mit freundlichen Grüßen
aalerich

Ich behaupte mal ganz platt, es gibt nur ganz wenig User so wie Du, die jedes einzelne Fitzelchen von Bit, gezielt verteilen...und wehe, da iss einer dazwischen, der nicht sofort seine verdammte Schuld bezahlt...

Sorry, so isses bei den allermeisten nicht...wir müssen Arbeiten, weil die Kinder Hunger haben und Frauchen neue Schuhe braucht. Ergo müssen wir einen Mod nutzen, der optimalen Slotspeed, so verteilt, dass jeder ein glückliches Lächeln ins Gesicht gezaubert bekommt...und das funzt nun mal nur mit fettem Zz Upload. :mrgreen: :mrgreen: :mrgreen:

Aber immerhin, hast du das Kernproblem richtig umschrieben..."die Seltenheit eines Chunks".
Absolut richtig, nur solltest Du auch in betracht ziehen, dass selbst ein Chunk der u.U. in größerer Stückzahl im Netzt vorhanden ist, zu einem umkämpften Objekt wird, wenn, ja wenn, die Nachfrage sehr hoch ist. Aber auch hier bietet das Zz System eine, wie ich finde deutlich bessere Verfügbarkeit, allein durch die Tatsache, das oberstes Ziel ist, einen Chunk zu vervollständigen. Ich mein, wir sind geistig gar nicht so weit auseinander...bis auf das Wort: "Wiederverkaufswert" ...nochmal Sorry, aber eMule ist ein Geben und Nehmen, nicht ein Verkaufen und Kaufen.

Januar

ich requeste split für diese diskussion! 8)

Und ich requeste eine neue Funktion für den Stulle :mrgreen:
Bei der neuen Spike Version werden Xtreme-Clients von einer Reask-Zeit-Änderung ausgenommen damit man bei denen nicht aus der Warteschlange fliegt (akzeptieren ja nur 29Min). Wie wärs?

ja, ist geplant, wie auch anderes...

Da noch nicht gesplittet ist.... :whistle

Diese wenigen User heißen Releaser. Und Pusher Der Releaser hämmert durch zz nämlich immer nur den gleichen Kram raus, den eh schon fast jeder hat. Das Resultat ist dann die Kammform der Verteilung, mit sehr langen Zinken.

Man könnte als "Beweis" einen Stör-Client schreiben, der gezielt die Verteilung durch anfixen schon verteilter und einzelner, nicht verteilter Chunks stört/steuert/beeinflußt.

Der Releaser kann sich dem entziehen. Durch "hide overshare". Doch alleine die Tatsache, das nur solche Gegenstrategien, die zz gezielt aushebeln, für eine gute Verteilung (besser: Streuung) sorgen, zeigt deutlich, dass zz nicht die Lösung ist. Sondern das Problem.

zz ist nichts anderes als die Strategie, die schon die alten .2x und .3x hatten. Nicht umsonst ist man davon abgerückt. Ist mir völlig unklar, warum man dahin wieder zurückgegangen ist.

Just my 2 €-Cents
Carlo

Hi,

Nun gut, wenn die Diskusion doch hier weitergeführt wird, na dann... :grin:

Zz sorgt zuverlässig dafür, dass von Xtreme Mods wg. "Xtreme Full Chunk" weitestgehend nur noch Chunk Fetzen übertragen werden (es drängeln sich teils 5-und-mehr Clients auf einem Chunk); was den Xtreme für mich momentan zu einem der [Ironie]beliebtesten Share-Partner[/Ironie] macht. (sorry X-Man ;))

Wenn DAS oberstes Ziel sein soll, dann ist dies aber sauber verfehlt worden!
Ich kann bei leibe keine Abnahme der unvollständigen Chunks erkennen. Im Gegenteil, seit zz wird der letzte fehlende Chunk einer Datei regelmässig nicht fertiggestellt, es bleibt oft ein Fetzen von wenigen KBs!!! offen auf die man dann teilweise sogar Stunden bis zur Fertigstellung warten muss.
Mit Maella war das die Ausnahme, seit zz ist es fast schon zur Regel geworden.

Dazu sei noch erwähnt, die meisten von mir geshared-ten Dateien haben weniger als 50 Quellen, gehören also zu den seltenen Vertretern. Für eher seltene Dateien ist zz ein klarer Rückschritt, eine echte Performance-Bremse.

Viele Grüsse, Tom

Rename/Mass rename
 

Ist vermutlich keine Stulle-"Feature", aber...

Das Renaming von Dateien blockiert das Maultier. Das ist umso ärgerlicher, da das Rename (im Vergleich zur .46c) sehr langsam geworden ist.

Wenn in einem Mass Rename genug Dateien gewählt werden, brechen alle Up- und Downloads ab.

Dieses Verhalten ist umso unverständlicher (zumindest für mich), da der Reload einer extern umbenannten Datei den Esel nicht blockiert.

Externes Umbenennen setzt aber die Prios auf den Default, von daher ist das kein brauchbarer Workaround.

Gruss
Carlo

@ Tom-XT

So, jetzt iss aber auch wieder gut. Bitte lese die eMuleHilfe, weil jetzt wirds ansonsten Lächerlich.
Selbstverständlich versucht eMule ""grundsätzlich"" >>>immer<<< einen ganzen Chunk hochzuladen. Ob Du das eingeschaltet hast, oder nicht. Wenn das nicht gemacht werden kann, kann das auch kein anderer "Zaubermod".
Es ging mir lediglich darum, darauf hinzuweisen, dass bei aktiviertem Vollchunkupload, kleine Dateiateile nicht mehr bevorzugt bearbeitet werden...und das dieses Prop, weitestgehend, durch das neue Zz-Uploadsystem "anders" gelöst ist...PUNKT.
Welcher Chunk nun angefordert wird, hängt davon ab, wie Du Deine Prios gesetzt hast und welche Prio, Dein Gegenüber eingestellt hat. Einige aktuelle Leechermods, liefern übrigens immer die Info, die Datei ist nicht vollständig vorhanden...und mit welchem Namen, die bei Dir auftauchen....ist Einstellungssache.

Januar

Anleitung?
 

Hallo zusammen,:mrgreen:
zuerst einmal möchte ich erwähnen, dass ich schon seit Jahren mit dem Esel unterwegs bin und ich die normale Benutzung auswendig kenne (hoffe ich jedenfalls).:wink:

Da nun aber schon lange nichts mehr von der originalen Eselcru gekommen ist und ich eine Abneigung gegen Lecher hab, bin ich aufs Eis gegangen und hab mir mal den Stullemule installiert.:think

Nun gehöre ich aber zu den Leuten, die wenig Englisch können aber gerne Anleitungen lesen (und eine Anleitung braucht man bei der Vielzahl der Einstellungen wirklich) und so google ich schon seit Tagen nach einer Anleitung der Zusatzfunktionen der Mod. :???

Bitte entschuldigt, das ich nun nicht alle 38! Seiten dieses Threat durchlese, ich brauch ab und zu mal Nahrung und alle par Stunden mal Schlaf.:roll:

Lange Rede kurze Frage:
Gibt es zu den „Speziellen“ Funktionen der Mod irgendwo eine deutsche FAQ oder eine deutsche Anleitung? :think

Wäre nett wenn mir einer ’nen Tipp geben könnte:dance
Danke

@Frank Meyer

Eventuel könnte dir die FAQ auf der StulleMule Homepage weiterhelfen.

eMule StulleMule mod unter "FAQ"
Dort sind einige Features Stichwortartig erklärt.