net hat der soviel weiß net.. naja.. bin jetzt eh wieder auf deine version zurück. die andere hat keine quellen gefunden

Hi Gnaddelwarz,

erklaert wohl nur noch etwa 0,5% gebannte User, im Gegensatz zu 1% der Version 1.2?
Werte in Prozent zu den wartenden Clients bei mir gerechnet.

Ich vermisse die Option "Versuche ganze Chunks zu uploaden" oder so aehnlich.
Ist dies jetzt zum Standard erklaert worden?
Mir solls recht sein, weil ich diese Option immer aktiviert habe.

Minuspunkt:
die AntiComm geht mir persoenlich ab
-> bitte kein Flames von den anderen, von wegen: blablabla Du willst doch andere nur benachteiligen und all sowas

In der hardcoded "BanList" der Mods und Usernamen sind nur eine handvoll drin. Und wer sich mit dem Shice ein wenig auseinandergesetzt hat, wird wissen, dass DEIN Username auch immer bei Dir mitsaugt (z.B Don Pedro NICK, Chief NICK usw...). Also rein damit in die AntiComm, wenn die schon nicht vom Mod her gebannt werden, weil getarnter ModName, dann eben hinten anstellen.

Gruesse
Kaeptn

ich werde diesen mod auch mal testen Gnaddelwarz nehm ich immer gerne.

ich hätte mal wieder öfter vorbei schauen sollen

Hallo AdiS,

Du hast mir nicht geglaubt bzgl. einen gueltigen Client zu haben, bei dem ich keinen QR habe, einen "sauber definierten" Status besitze und dennoch nichts bekomme, obwohl dieser einen Chunk mehr hat.
Sieh selbst und urteile, warum ich die manuelle "aktualisiere Client" Funktion vermisse...
Dieser gezeigte Client hat den vollen Chunk, ich stehe mit ihm in ICQ Verbindung und er koennte ihn mir geben, wenn ich ihn woellte, aber er bekommt mich nicht rein in den FU.
Manuelles aktualisieren wuerde ihn als unknown oder sonstwas markieren, dann koennte ich ihn kicken ueber die verschiedenen Funktionen (Kick unknown, NNS, FQ usw...) aber so haengt der drin bis ultimo. Einziger Ausweg: STOP und RES des Urlaubsfilms... neuer Status, gut ist, aber das kann es nicht sein :(

http://www.cabernet.ch/jockinger/pic...der_status.gif

Und jetzt bitte ich Dich hoeflichst, diesen Effekt zu bei mir wenigstens zuzugeben und nicht als dastehen zu lassen.
Nur weil Du es nie gesehen hast, heisst es noch lange nicht, dass es bei niemandem vorkommt und damit das Thema unter den Tisch zu kehren.
Wenn man nur eine handvoll an Quellen hat, dann ist man um jede einzeln sauber definierte Quelle mehr als dankbar. Das solltest Du besser wissen als ich.

So... ich werde mich in mein kleines Schneckenhaus weiterhin zurueckziehen und mich meinen Einbildungen hingeben ;)

Bei sowas geht mir die Hutschnur hoch.... sorry... Aber der Beweis musste erbracht werden, das sowas moeglich ist... selten aber dennoch.

Gruesse
Kaeptn

@Gnaddel:
Gibt es keine Moeglichkeit, diese manuelle Aktualisierung wieder reinzunehmen oder wurde die offiziell "gebannt" bzw. als unwuerdig gebranntmarkt?

Hi AdiS,

so ein Zufall... da bist auch Du mit einem nicht definierten Zustand aufzufinden:
http://www.cabernet.ch/jockinger/pic...r_status_a.gif

Ich denke, Du weisst wo ich dran haenge und das sollte als Hinweis auch genuegen.
Kein Fake... wie auch das obere Bild.

Gruesse
Kaeptn

Uhu,
ich zweifle ja nicht an deinen Beobachtungen, erwarte aber keine hellseherischen Fähigkeiten von mir.

Ich habe ja schon vorher zugegeben, dass auch bei mir manchmal gewisse Clients 'klemmen' , nur habe ich es als Kosmetik abgetan. Eigentlich ist es auch kein Problem wenn man nur saugen will. Schliesslich weiss man auch nie ob es ein Fehler des eigenen Mulis oder des anderen ist oder sonstwas (IP-Wechsel). So auch ein paar mal bei dir - sobald ich einen FS vergeben wollte, bist du aus der Queue verschwunden. Komischerweise geht's jetzt gut.... Hast du stop&go gemacht, dass es jetzt klappt mit dem FS?

Leider kann ich den 'Fehler' nicht irgendwie eingrenzen. Er kommt selten und scheinbar beliebig vor. Kein bestimmer Client. Auffallen tut's mir nur wenn ich einen FS vergeben will, dann passiert das was ich bei dir hier oben beschrieben habe => der Client verschwindet einfach aus meiner Queue. Also Haken raus beim FS und nach einer Weile ist er wieder in meiner Queue...
Verbose meint nur lapidar: Removing client from upload list. Reason: Socket disconnect: OnClose() ----

Mal sehen ob Meister Gnaddel oder sonst wer etwas Licht ins Dunkel bringen kann, damit wir geplagten Releaser ein paar Minuten weg vom Muli können - ohne ständiges argwöhnisches Begaffen desselbigen... :lol: :wink:

Bis denne
AdiS

Hi AdiS,

den Effekt der FS Problematik habe ich auch schon oefter bemerkt... der Client kommt rein, verschwindet, kommt rein, verschwindet.
Das geht recht schnell und das steigert die "fehlgeschlagenen Uploads" immens.
An dieser Stelle warte ich eine zeitlang, lasse den gewuenschten Client ohne FS und gebe ihm spaeter (so etwa 30 Minuten) den FS. Dann klappts wunderbar.
Bei so einer FS Aktion hats mir auch mal die anderen komplett rausgeworfen und es waren alles "neue" Clients in meinem Upload drin.

Und Du hast recht, ich habe auf dem betroffenen File gestern STOP RES gemacht, damit wieder saubere Bahnen existent sind. Meinen letzten IP Wechsel habe ich (mal nachsehen) vor 2,5 Tagen gehabt.

Sorry fuers "anmaulen" in meinem vorangegangen Posting...

Gruesse
Kaeptn

Zum Thema SUQWT gibt es noch was negatives zu berichten:
Um zu sehen, ob meine SUI beim Wechsel noch gueltig geblieben ist, habe ich einen bekannten User per Fon angewiesen, ein File zu laden, das ich grad sauge (12 User haengen dran).
Er hat mich damals gefunden, meine erfolgreiche SUI bestaetigt und hat den DL dann abgebrochen.
Tage spaeter sind wir zufaellig an einem anderen File dran, er hat es definitiv erst seit 3 Stunden drin gehabt, aber seine Wartezeit betrug knapp 4 Tage.
Wohl noch aus dem Testfile resultierend... :(

Die Berechnung ist imho recht suboptimal, da dieser User sich dann den anderen vordraengt, obwohl er es imho ganz und gar nicht verdient hat.
Die anderen warteten definitiv laenger an diesem File...

Gruesse
Kaeptn

mal ein paar DetailFragen zum HOS...
Diese Einstellung versteckt ja Chunks, die schon X-mal rausgegangen sind (siehe Sivka Features in diesem Forum).
OK, die noch in der UL Queue stecken, bekommen ihn auch noch, damit kann man leben, ist auch kein Problem fuer mich.

Gilt der Wert fuer immer oder nur pro Session?
So wie ich es aus dem Source gelesen habe, wohl fuer immer?!
-> oder habe ich mich verlesen?

Gesetz den Fall, ich moechte spaeter ein File ReSharen, dann muesste ich HOS entweder erhoehen oder deaktivieren, damit da wieder was raus geht?

Ich habe grad ein File, von dem ich einen ganzen Chunk habe. Dieses File auf REL gesetzt, die Clients haben sich drum geschlagen ;)
Alles bestens...
Der Zeitpunkt des HOS (steht bei mir auf dem Wert 6) rueckte immer naeher und damit wurde es spannend.
-> Was passiert mit den restlichen Wartenden?

Die kamen auch in die UL Queue rein, haben kein Byte abbekommen, klar der Chunk ist ja auch nicht mehr ersichtlich.
Die Clients fliegen nacheinander wieder aus der UL Queue raus, kein Problem, so wie es sein sollte.
Aber der Knackpunkt kommt:
die rausgeflogenen haben sich in der Statistik bei "fehlgeschlagene Uploads" niedergeschlagen
-> damit steigt dieser Prozentanteil an :(

Frage an Gnaddel:
Waere es moeglich, die HOS Funktion auch auf einzelne Files anzuwenden, so wie es mit den Sivka-File-Settings auch einzeln moeglich ist.
Wird vermutlich CPU Last ohne Ende produzieren, da zweimal nach HOS geschaut werden muss

Gruesse
Kaeptn

//EDIT ich vergass nachzufragen, ob FU beim HOS Wert mit einbezogen werden, oder ob die dennoch aussen vor bleiben und zusaetzlich zum Wert "parallel" rausgeschoben werden
Warum ich das frage?
Ein USer schrieb mich an, ob ich das File als Releaser nicht vollstaendig haette, ein anderer User (dem ich einen FU gab) meinte, es waere vollstaendig, also muesste beim FU die HOS Regel deaktiviert sein?!

Genau das hatte ich schon nach dem ersten Testtag beobachtet und auch berichtet.
Leute, denen ich definitiv schon mal was hochgeladen habe, bekommen trotzdem immer wieder die alte Wartezeit angerechnet.
Ausserdem stimmt die Berechnung nicht. Ich hatte meinen Muli eine ganze Woche lang aus und die Tage, an denen er gar nicht lief werden trotzdem auf die Wartezeit angerechnet.

Oha, wieder neuer Stoff...

SUQWT: Mir kommen die Wartezeiten zuweilen auch verdammt hoch vor (bis 15 Tage!). Eure (Kaeptn, luka) Beobachtungen zeigen doch deutlich, dass da was nicht stimmt. Daraufhin habe ich im offiz. Forum mal bei den Code-Schnippseln nachgelesen. Einer (letzter Post) hat da eigentlich genau das behauptet was ihr gesehen habt, so dass ich auch zu behaupten wage es ist ein Bug. Anstatt die effektive Zeit in der Queue wird einfach die die gesamte Zeit genommen auch wenn der betreffende Client zwischenzeitlich gar nicht in meiner Queue war... :(
Ob der Bug inzwischen gefixt ist und in welchen Mod weiss ich leider nicht.
Wenn man SUQWT wenigstens abschalten könnte...

Full Chunk: Kaeptn hat mal nach der Funktion gefragt. Ja, ist schon länger im Gnaddel 'hardcoded' , sogar 10MB werden geuppt um bombensicher einen vollständigen Chunk abzuliefern. Ausserdem ist im Gnaddel auch das Timeout des orig. Muli von 60min auf xxmin erhöht, so dass auch langsamsauger eine Chance auf nen Full Chunk bekommen.

HideOS: Wann HideOS resetted wird würde mich auch mal interessieren. Irgendwo habe ich gelesen es würde die Verteilung gemäss Anzeige in den Spreadbars gemacht(oder bezog sich das auf das One Chunk Sharing?). Wenn dem so ist, wäre das Blockieren also nicht nur pro Session gültig. Aber 1 Chunk ist immer verfügbar, selbst wenn der eingestellte Wert von HOS erreicht wurde, das ist mal sicher.
HOS auf einzelne Files vergeben würde ich auch gerne. Was noch kewl wäre ist eine genauere Anzeige der Parts/Chunks die verteilt wurden =>kontrolle ist besser. Spreadbar ist mir da zu ungenau. Sowas in der Art von Part Selection aus dem PlusMuli oder Pawico, dabei wäre es aber nicht
unbedingt erforderlich die einzelnen Chunks blockieren zu können.
Wie das beim FU und dem Verstecken der Chunks ist weiss sich auch nicht.

Zusammenfassend kann man sagen:

- Mit SUQWT ist was faul

- Das Reasken der Source wäre in bestimmten Situationen sehr nützlich.
Abzuklären ist die 'Legalität' von offizieller Seite her.
Das zeitweise Nichtfunktioneieren des FU/FS scheint damit im
Zusammenhang zu stehen.

- Hide OS transparenter(Anzeige) und flexibler(pro File einstellbar) machen
wäre auch wunderbar.

Noch was zum Reask allgemein. Gefunden im offiz. Forum. Es ging um den LSD-Mod und seine angeblich schädlichen Funktionen.

-------
bluecow wrote:
Following is a list of "functions" which we found in eMule0.30b-LSD13b and which we judged as unfair with respect to the network.

*) Global and file selective disableing of source exchange. To make things even worse, the mod contains a feature which enables the user to ask other clients for sources but to not answer any source request from other clients. I would call this "Overhead Leeching". If a mod wants to disable source exchange (which I do NOT recommend, because it's one of the best features of eMule), it has to be done on a global basis and it has to be done by not sending the according feature tag in the Hello packet.

*) Manual Ask Server for new Sources. This function can be used (and as known from plenty of forum posts of users which are proud to use that function) to sidestep the minimum server reask time.

*) Manual Ask Client for new Sources. This function can be used (and as known from plenty of forum posts of users which are proud to use that function) to sidestep the minimum client source reask time.

*) Manual reask of clients depending on client's state (On Queue, NNS, Queue Full) This function can be used (and as known from plenty of forum posts of users which are proud to use that function) to sidestep the minimum client file reask time.

*) Several changes to the credit system (score computation).
bla
-------

Wenn ich zu oft bei einem Client zu oft nachfrage werde ich einfach gebannt, wo ist das Problem. Eigentlich also Blödsinn. Offenbar wird jetzt das automatische Reak Client nur noch alle paar Std. gemacht - was dabei rauskommen kann sieht man ja....:(

Wie auch immer, offenbar wurden die Modder angewiesen diese manuellen Sachen zu entfernen.
Btw, Source Xchange kann in unserem Gnaddel, also auch bei Sivka immer noch disabled werden.... :shock:

Hi luka,

sicherlich ist mir Dein Posting noch in Erinnerung, habe ja extra den ganzen Thread nochmal durchgelesen, damit ich auch hoffentlich nix uebersehe. Wie ich und AdiS Dich weiter untermauern koennen, waren die genannten Clients nicht mal in der Warteschleife drin.

@AdiS,

Danke fuer Deine ausfuehrlichen Erklaerungen :)
Die 10MB UP habe ich auch schon bei der 1.2er gesehen, aber hardcoded, das war mir neu. Kann ja fast nicht anderst sein, wenn diese Option nicht abschaltbar ist und ich nur jemandem etwas uppen kann, wenn der komplette Chunk da ist. Stoert mich nicht, da ich es eh eingeschaltet haette.

Zum Reask... der Meinung bin ich auch. Wenn ich es bei einem Client zu oft mache, dann werde ich dort gebannt. Mache ich es zu oft an einem Server, dann kickt der mich ebenfalls (wo habe ich das nur gelesen...?).
Ach ja... dabei ist mir auch aufgefallen, dass das fehlende manuelle Akt. eines einzelnen Clients schon auf der ersten Seite aufgefallen ist.
Ich weiss ja nicht, wieviel kb so ein reask aufs Netz rausschiesst -> Traffic ueber den Server, Traffic im P2P Netz allgemein

XS, ist in der Tat einer notwendigsten Funktionen und sollte imho ebenfalls hardcoded implementiert werden.

Nunja, gegen das offizielle ModForum kann sich wohl kaum einer stellen, ansonsten wird er als ungueltig oder gebannt erklaert?!
Also, Fahnen tief halten und lassen wir uns ueberraschen was da noch kommen wird.

Bevor wir weiter an unserem kleinen "Stammtisch" rumueberlegen und rumgruebeln, koennte sich vielleicht Gnaddel mal kurz melden.
Ich meine, etwas Aufklaerung von einem Sachverstaendigen hat noch nie geschadet.

Gruesse
Kaeptn

Nachtrag zum VGA Treiber Problem (alles einheitliche Icons):
der Original eMule 0,30e hat das gleiche Prob, liegt also nicht am GnaddelMod, also woanderst
und
mit 256 Farben funktioniert es auch mit den aktuellen NVIDIA Treibern ;)
16 und 32 bit jedoch nicht :(

Gruesse
Kaeptn

das nachfragen der clients nach quellen, erfolgt aller 18 minuten automatisch (im standart-emule)!
cyrex2001

Danke cyrex2001, leider weiss ich jetzt halt immer noch nicht ob das beim Gnaddel/Sivka das Problem ist.
Jedenfalls scheint die Reask-Geschichte bei meinem momentanen Mortillo Mod besser gelöst zu sein. Dort treten bisher keine - besser gesagt nicht lange - solche undefinierbaren Connect-Zustände auf, die werden immer mal wieder weggeputzt... 8). FS-Vergabe geht auch bisher ohne Probleme.

AdiS

ps Kaeptn, schau die auch mal den Mortillo 1.9b an, von den Funktionen her müsste der dir auch zusagen und SUQWT kann man abschalten. :wink:

Wie siehts eigentlich mit Deinem Internetexplorer aus ? Ist der auf dem aktuellsten Stand ?
Das ist auch dann wichtig, wenn du ihn gar nicht benutzt, weil Emule diesen benötigt.

Januar

Hi Januar,

MSIE: Ver. 6.0.2800.1106, 128bit
mit SP1, Q828750, Q330994, Q824145
Sollte alles in allem mit den ganzen Web-Updates die so kamen auf dem letzten Stand sein.

Gruesse
Kaeptn

Kaeptn_Sperrmuell



Version: 6.0.2800.1106. xpsp2.030422-1633
Verschlüsselungsstärke: 128-Bit
SP1; Q818529; Q330994; Q822925; Q828750; Q824145

So sieht das bei mir aus.


Gruß, Januar

Hi Januar,

ich vergass ganz zu erwaehnen, dass ich W2k Pro mit SP4 fahre. Da gibt es bei mir nicht mehr zu holen an HotFixes...

Kaeptn_Sperrmuell


Ich denke das ganz bestimmt Ganddelwarz diese Postings lesen wird. Vielleicht fällt ihm ja ein Lösungsansatz dazu ein, wobei ich es als nicht sehr warscheinlich betrachte, dass dieser Fehler "ausschliesslich" bei Dir aufgetreten ist.


Gruß und einen Guten Rutsch ins neue Jahr,


Januar

Hilferuf an Gnaddelwarz
Nachdem diverse Berechnungsfehler in Punkto SUQWT auftreten wuerde ich Dich auf Knien bitten eine Ver. 1.3.3 (oder sowas) zu coden, die es ermoeglicht genau diese Funktion optional abzuschalten, oder gar nicht drin hat.
Die sonstigen Funktionen sind imho bestens, ausser zwei Bugs die man umgehen kann (habe ich hier nicht erwaehnt) und funktionieren uach bestens -> bitte vorlaeufig nichts weiter aendern

Warum?
Ich konnte es jetzt nach einer Woche nicht mehr mitansehen, wie sich 10 User an einem File brav anstellen, ein 11ter daherkommt, der vor 6 Tagen zum letzten mal gesehen wurde und sich ganz "frech" nach vorne auf Platz 1 drueckt.

Ich habe dem Test angegangen und einen in dieem Thread angesprochenen Mod getestet und ich kann sagen... ne... gefaellt mir nicht.

Ich bin just zu diesem Zeitpunkt zu Deinem "uralten" 1.2 zurueckgekehrt.
Ich kann mir das suqwt-Spiel einfach nicht mehr laenger mit ansehen....

Einmal Gnaddel, immer Gnaddel... ich stehe dazu!
Stabiler Upload, keine zacken (27kBs)... 8-14% fehlgeschlagene Uploads machen sich beim REL bemerkbar.

Der 1.3.2 ist zweifelsohne auch aeusserst stabil darin, aber das suqwt.... :(

Gruesse
Kaeptn

/Sorry fuer die Jammermail, aber das musste ich loswerden

HILFE !!!!! Habe Probs mit Gnaddelwarz 1.3.2
 

Hi leutz !

Bei mir läuft der neue Gnaddelwarz echt nicht schlecht .... bis zu einem gewissen Zeitpunkt !

Dann nämlich baut er keine neuen Verbindungen mehr auf .... obwohl er die bestehenden Verbindungen nicht abbricht ( hält auch den server ) kommt irgendwann mal alles zum Stillstand, weil er zu den einzelnen Clients immer nur sagt : "Verbindungen werden aufgebaut" :(

Passieren tut dann gar nix mehr : 0 DL auf ewig und UL vielleicht mal 0,5 oder so .... :?

Das Problem taucht bislang ohne erkennbare zeitliche Zusammenhänge auf und die Konfiguration ( Win98 mit routerbedingter Firewall hat bislang mit der Standardversion von emule auch noch keine Probs gemacht ) !
Also meistens passierts nach 20 Std. oder so, passiert aber auch mal nach 6 Std. ( wie gesagt habe ich da noch keinen Sinn entdecken können )

Eine Neuverbindung zu einem Server funzt nicht, da er auch hier keine neuen Verbindungen aufbaut ( die Server melden time out )
Eine Lösung des Problems ist lediglich ein Neustart von emule ( runterfahren und wieder hochfahren, dann gehts wieder ) .... aber das ist definitiv keine Dauerlösung :roll:

Ich hoffe auf konstruktive Hilfe !!!

Master Kah


Ich denke das Prob ist Dein Betriebssystem.
Aber ich glaube nicht, dass ich Dir da etwas neues erzähle.
Du könntest versuchen die anfallenden Verbindungen so tief wie irgendmöglich anzusetzen. Steuern kannst Du dies über die Einstellung des Hartlimits Deines Emule.Auch die Verbindungen per 5 Sek würde ich senken um Dein BS/OS zu schonen.
Das einzige was Dir wirklich helfen würde, wäre ein BS-Wechsel auf eine aktuellere Version.

Werf mal einen Blick auf die "Speedanleitung für Emule" auf meiner Seite.


Januar

Hm, nach den Fehlern, die in 1.3.1 noch drin waren, konnte ich bei mir keine Fehler feststellen....
Also, ein Clients, der einen Upload bekommen hatte, hatte immer Wartezeit 0 beim nächsten Mal, wenn ich ihn wieder gesehen habe.
(Ich möchte Bugs hierbei natürlich nicht ausschliessen, wenn also jemand konkret etwas beobachtet......)
Bugs?
Und du bist sicher, dass das nicht Leute waren, die tatsächlich mal 6 Tage in deiner Queue zugebracht haben?
Aber wenn du das unbedingt deaktivieren möchtest, starte emule einfach so:

starte_emule_ohne_suqwt.bat:
Das entfernt vor dem Start die gespeicherten Zeiten, das sollte besser sein, als die doch schon etwas angestaubte Version 1.2 zu verwenden.

Hat das ein Nicht-Coder verstanden ? :roll:
Könnte das bitte jemand mir als Ahnungslosen noch mal detailiert erklären. :?

Hi Gnaddel,

MEGATNX fuer Deine Antwort, ich werde den Workaround mit der geaenderten BAT heute Abend mal antesten (muss gleich zum arbeiten).

ich bin mir mit den uebertriebenen Wartezeiten 100% sicher, da meine Warteschleife 1300 hat und eigentlich die 700 Warteclients die letzten Wochen nie ueberschritten hat, also immer Platz gewesen.
Gesehen bei einem aus meiner Friendlist, mit dem ich den Test der erfolgreichen SUI gemacht hatte. Der hat dann Tage spaeter nach der Umstellung zufaellig am gleichen File gesaugt wie ich.
Muss mal gucken, ob ich noch ein paar Screenshots rumliegen habe.

zu den weiteren Bugs
Im Fenster der Einstellungen kann man wunderbar alle Optionen von oben bis unten durchklicken, einstellen. Wenn man bei der untersten Option angekommen ist und die Eiinstellungen schliesst, anschliessend wieder oeffnet, sind die obersten beiden Optionen (Allgemein und Verbindung ist das imho) nicht mehr zu sehen. Man kann nicht mehr hochscrollen.
Workaround hier
Die oberste Option die zu sehen ist anklicken, "Einstellungen" schliessen.
Wieder aufmachen und man steht wieder ganz oben und kann sich nach ganz unten durchklicken.
-> Der Scrollbalken um nach oben zu gelangen fehlt, alternativ, wenn man die oberste sichtbare Option anklickt, rutsch der zuvorige nicht in den sichtbaren Bereich rein.

der andere... ist eigentlich kein Bug (?), den hat der Original eMule auch.
Bei Verbindung kann man Limit und Kapazitaet angeben.
Limit ist definitiv das Limit der Leitung und Kap. ist noetig fuer die Stats.
Mein UL Limit steht auf 27, also gebe ich bei Kap. 26 an, damit die Stats als max 30 anzeigen. Sieht gut aus, da eine gerade Zahl.
Habe ich Kap. auf 26 dann kann ich Limit bis max. 26 fahren.
Die beiden Werte sind also gekoppelt, nicht mehr unabhaengig wie es bei den frueheren Versionen war.

Ich werde heute Abend den Mod wieder umstellen!

@luka
sowie ich das lese, wird in der Eintragung die *30d.bak nach *.met "verschoben"
man haette die *.met auch vorher loeschen koennen und dann die 30d.bak in .met umbenennen koennen, waeren zwei Zeilen zum tippen gewesen...

Ich werds unbedingt machen, denn die Funktionen und Satbilitaet des 1.3.2 sind fuer meine Zwecke allerbestens geeignet.

Danke und Megagruesse
Kaeptn

Stimmt, ist bei mir auch so.

Mit den Cursortasten kommst du aber bequem wieder an alle Optionen dran.

Gruß,

Pathfinder

darauf haette ich selber kommen koennen :oops:
Habe mich im eMule noch nie mit den Cursortasten bewegt :(
Windows jedoch mache ich meistens mit den Hotkeys/Shortcuts...
Danke

Gruesse
Kaeptn

Hi Gnaddelwarz,

Bescheidene Sache am Rande:
aehm... zu Deiner Batchdatei...
Schoen und gut, dass es beim Start zurueckgesetzt wird... mein Rechner laeuft 24/7 und Mods 2-3 Wochen je nach MS Online Update.
Ich habe ja ein ZIP Backup von allem gemacht.
Ver. 1.2 bis letzte Woche, dann kam die 1.3.2 drauf...
diese Woche (wie hier zu lesen) komplett geloescht, das ZIP Backup von Ver. 1.2 wieder drauf (eine Woche Upload kann ich verschmerzen, sicher ist sicher).
Dann Dein Workaround mit der Batch, mein Posting am Freitag Morgen mit "Danke dafuer" als Inhalt.

Dann am 2.2. 19:30 wars soweit:
Installer ins gleiche Verzeichnis wie der 1.2
Bis dato war kein SUQWT im Sortiment, jetzt 8 Stunden spaeter habe ich Clients in der UL drin, die vermeintlich schon 1 Tag und 20 Stunden in meiner Queue warten???
-> Die Files stehen auf REL (kein PowerREL), meine Queue hat noch 200 Leute Platz, also kein Platzproblem

Die 1.2 hat doch nirgends Zeitangaben abgespeichert, wer wann wo war?

Zur Batch:
Die wuerde doch auch nur die Zeitangaben "resetten", sofern ein Neustart des emule angesagt ist?

Gesetz den Fall Client xy saugt an Tag a am File b
File b wird bei mir fertig, ich nehms raus
Client xy fliegt zwangsaleufig raus aus meiner Queue
3 Tage spater kommt Client wieder daher, will an File c saugen
Dieser hat (durch nichtaustauschen der .met Datei) dann dennoch eine Wartezeit von 3 Tage und ...Stunden?
-> Zeit wurde nicht resetted?
Woher auch?
Emule laeuft immer noch und es wird dennoch die damals gesopeicherte Zeit angezogen (->am Tag a an File b gewesen)?!
Dadurch bekommt er wieder nach drei Tagen "Abstinenz" einen Mega QR zugeschrieben?!

-> Mit der Abtsinenzzeit habe ich wieder einen bekannten Client telefonisch "angestachelt", der kommt in ein paar Tagen wieder "auf Abruf" rein bei mir

Ich bin mehr als verwirrt... den Code habe ich mir x-mal durchgelesen, was die Berechnung angeht, aber ich bekomme einen Drehwurm dabei.

Gruesse
Kaeptn

//EDIT ketzer check:
ups:
Rekord liegt jetzt bei 8 Tage 9 Stunden
Das File lag vorher auf "sehr niedrig", seit 2 Stunden auf REL (kein Powershare)
Und das mit einer Laufzeit von knapp 9 Stunden mit SUQWT?
-> kann es sein, dass REL+Wartezeit zu hoch multipliziert/addiert werden, oder so?
-> REL funktioniert imho bestens (steht auf 512 bei mir)

Gnaddel, ich schick Dir dieses WE eine PM mit den Screenshots zum angucken, sind keine Fakes.

Hm, ja, war ein Denkfehler meinerseits. Mein Gedanke war, dass sich die beiden verschiedenen clients.met ja nur durch SUQWT unterscheiden, ich habe aber nicht bedacht, das die Strukturen im Arbeitsspeicher die Wartezeit ja weiterhin speichern.

Also vergiss das mit der Batchdatei.
Nicht ganz. Es wird nicht gespeichert "am Tag a an File b", sondern "war irgendwann schon mal für x Stunden in der Queue", dh es wird nicht das Datum sondern die Wartezeit gespeichert. (Auch das angefragte File wird nicht mit abgespeichert)
Also:
Ein Client fragt eine (beliebige) Datei an und muss natürlich in der Queue warten (was ohne "Powershare" ja der Regelfall ist).
Er wartet z.B. 8 Stunden (ohne Upload zu bekommen) und "verschwindet" nun aus der Queue. Dafür kann es verschiedene Ursachen geben:
- man hat selber seinen Client neugestartet,
- der andere hat seinen eMule (für längere Zeit) beendet.
- der Client braucht die Datei nicht mehr (schon mit Hilfe anderer Quellen komplett)

Angenommen, der Client kommt nun nach 3 Tagen wieder um eine Datei anzufragen. Dieser Client beginnt nun nicht mit 0 sondern mit 8 Stunden Wartezeit. Das ist nur fair, dieser Client hat diese Zeit ja (irgendwann mal) in der Queue verbracht, ohne etwas dafür zu erhalten.
Nun, ich habe eine Datei auf "sehr niedrig", ein Client der diese Datei dann mal läd hat im Schnitt 15-20 TAGE Wartezeit. Die durchschnittliche Wartezeit für "normale" Dateien (Prio AUTO, kein PS) ist bei 1-2 Tagen.

Da ich eMule nie 15-20 Tage durchlaufen lasse, hätten Clients, die diese Datei haben wollen, ohne SUQWT keine Chance diese zu bekommen.
Man könnte fast behaupten, ohne SUQWT könnten wir auf Upload-Prioritäten verzichten, denn dann würde die Datei nie hochgeladen werden, also könnte ich sie auch aus dem Share ganz heraus nehmen.

Hi Gnaddel,

Danke fuer Deine aussagefaehigen Erlaeuterungen.
Irgendwie hebelt sich das SUQWT damit doch selber aus?!

Beispiel
Ich forder eine Datei an, 300 Quellen gefunden, 100 arbeiten mit SUQWT.
Lasse sie 2 Stunden laufen, bekomme dann im besten Fall bei allen 100 SUQWT Clients einen QR.
Dann breche ich den DL der Datei ab (aus welchen Gruenden auch immer).
Eine Woche spaeter starte ich den DL der Datei wieder. 80 der SUQWT Clients sind immer noch mit der Datei unterwegs, bei denen bekomme ich zwangslaeufig einen aeusserst hohen QR, da meine vermeintliche Wartezeit 7 Tage betraegt.
-> bringt anfangs einen MegaDownload

War nur so ein Gedankenspiel...

Aber lassen wir das Thema SUQWT mal, wurde imho sehr ausfuehrlich und aufklaerend diskutiert.

Wie sieht es denn aus mit dem HOS?
Wenn ich den Wert X erreicht habe, geht ja (so gut wie) nichts mehr von dem File raus. Wird der Wert irgendwann wieder auf Null zurueckgesetzt? Bleibt der ewig bestehen?
Wenn ich eine Datei mit erreichtem Wert aus dem Share nehme, Monate spaeter einen ReShare machen will, dann sit der Wert erreicht und ich kann es nicht ReSharen, ausser ich deaktiviere den HOS Wert oder erhoehe ihn?!
Ist das so korrekt von der Denkweise?
-> Der HOS Wert wurde in diesem Thread auf Seite 9 um So Dez 28, 2003 14:43 im Detail schon mal angefragt und AdiS interessiert sich auch fuer die Verfahrensweise beim HOS.

Koenntest Du da bei Gelegenheit auch sachdienliche Hinweise einbringen?

Danke und Gruesse
Kaeptn

Kaeptn_Sperrmuell, einer von uns beiden hat das mit dem SUQWT falsch verstanden... Dein Beispiel hat (meiner Auffassung nach) einen entscheidenden Denkfehler, und zwar glaube ich, dass dir nur die Zeit angerechnet wird, die du wirklich in der Schlange warst... Also hast du nach deiner Woche 2h "Gutzeit" bei den Clients die noch da sind... Falls ich falsch liege bitte korrigieren...

hubutz,

Du hast recht!
habe geistig verdraengt...
Asche auf meinen Alzheimer ;)

Gruesse
Kaeptn

Kein Problem... Aber deine Theorie wäre für mich sehr praktisch gewesen... Kann meinen Muli leider net so lange anlassen (und hab ganz selten mal so 24h Tage)... Da würde mir das nach deiner Theorie richtig viel bringen ;)

Also, wenn ich HideOS richtig verstanden habe, dann bezieht sich der Wert nicht auf die absolute Anzahl, sondern auf die Differenz zum am wenigsten gesharetem Teil.
D.h. der HideOS-Wert gibt nicht an, wie oft ein Chunk heruntergeladen werden darf, sondern wie viel öfter als andere Chunks.
Beispiel:
Chunk 1 wurde 10 mal hochgeladen, Chunk 2 12 Mal und Chunk 3 16 Mal.
Bei einem HideOS-Wert von 5 dürften nur noch die ersten beiden Chunks hochgeladen werden. Chunk 3 ist erst wieder erlaubt, nachdem Chunk 1 hochgeladen wurde.

habe mal die BoardSuche intensiv gequaelt und in diesem Thread folgendes vom Meister sivka gefunden:
Damit wirds glasklar! Siehe auch Gnaddels Uebersetzung ein Posting hoeher, mit dem aeusserst anschaulichen Beispiel.
Damit duerften meine Fragen soweit geklaert sein und ich werde versuchen nicht mehr zu nerven.
->Ansonsten laeuft der Gnaddel wie gewohnt stabil und in bester Form. :)

Gruesse
Kaeptn

Hallöchen

Danke für Eure Recherche-Arbeit.

Inzwischen bin ich aus theoretischen und praktischen Gründen zum Schluss gekommen das HideOS nicht sehr effizient ist. Da vertraue ich lieber auf die neueren Mulis, die nehmen ja heutzutage nicht mehr jeden beliebigen Chunk, sondern versuchen mit mehr oder weniger Erfolg den selteneren Chunk zu ergattern oder zu komplettieren.

Das One Chunk Sharing ist da schon viel besser, wenn man releasen will und das File komplett hat. Nachteil: Die Sauger sehen anfänglich nur Rot und das schlägt auf die Psyche.... :mrgreen: Nur die ganz Schlauen und Hartnäckigen durchschauen den Trick. :wink:

Adios
AdiS

jetzt bin ich´s schon wieder :(
Zeit zum spielen gehabt... mit der Statistik diesmal ;)

Einstellungen
Graph Verzoegerung: 200 oder 120 Sekunden
Statistik-Baum: 5 Sek. Verzoegerung

Siehe hier mit 120 Sekunden Verzoegerung:
http://www.cabernet.ch/jockinger/pic...mods/dl12h.gif

und hier mit 200 Sekunden Verzoegerung:
http://www.cabernet.ch/jockinger/pic...mods/dl20h.gif

Was faellt auf?
Andere Zeitangabe an der X-Achse, gleiche Grafik...
Stoert mich echt nicht, nur "fuer´s Protokoll", dass man da nochmal nachsehen sollte.
Dieses Phaenomen fiele bei mir unter "PRIO4" rein ;)

Gruesse
Kaeptn

@Kaeptn_Sperrmuell

das ist bei jedem Emule so. Wenn man die Skalierung der Statistik ändert, wird nicht die gesamte Grafik neu berechnet, sondern alle neu hinzukommenden Werte werden nach der neuen Skalierung eingetragen. Irgendwann stimmt dann der ganze Graph wieder, wenn alle "alten" Werte nach links rausgewandert sind. Aber sofort mit neuer Skalierung anzeigen lassen geht meines Wissens nach nicht. Vielleicht sollte man bei Änderungen an der Skalierung den gesamten Graph einfach löschen, dann würde sich niemand wundern.