Feature Wishlist
 

habe mal als ich krank ein wenig über eMule nachgedacht und das sind die Features die mir eingefallen sind:

- Uploadsystem optimieren (1)

- Overhead reduzieren (1)

- Winsock 2.2 (2)

- Overall Hard Limit (2)

- optimale Hyperthreading Unterstützung (2)

- Releases gesondert für AMD und Intel Prozessoren kompilieren (3)

- Download und Upload besser synchronisieren in Einstellungen (3)

- DCC in IRC Client (3)

- beim Beenden minimieren (3)

- 64 Bit Unterstützung (4)


(1) = sehr wichtig
(2) = wichtig
(3) = nicht soo wichtig
(4) = zur Zeit nicht wichtig


Uploadsystem optimieren: Es muss doch möglich sein das Uploadsystem noch zu optimieren. Jedes 0.1kb Zuwachs zählt bei der Vielzahl der User.

Overhead reduzieren: Das gleiche wie oben...

Winsock 2.2: Schon ein paar Mal gehört, soll glaube ich stabiler und schneller sein und leicht zu implementieren sein (bin mir nich sicher ob schon in standard eMule integriert)

Overall Hard Limit: Statt das Hard Limit für jede Datei gleich zu setzen und so ausprobieren müssen wieviele Quellen insgesamt dabei rauskommen kann man mit Overall Hard Limit die Gesamtzahl der Quellen angeben (Bsp.: meine Leitung schafft bis 5000 gefundene Quellen). Es wird also die Zahl des Overall Hard Limit durch die Zahl der aktiven Files geteilt und dadurch ein erstes Hard Limit für jede Datei erstellt (also 1000 Quellen bei 5 Dateien bei mir). Wenn jetzt zwei Dateien nicht die Zahl der Quellen erreichen, werden den anderen Dateien noch mehr Quellen ermöglicht so dass das Maximum der Leitung so gut wie möglich ausgenutzt werden kann...

optimale Hyperthreading Unterstützung: optimierte Unterstützung für Intels Hyperthreading Technologie sehr interessant für Leute die rechenintensive Programme nutzen (Grafikrenderer, Spiele)

Releases gesondert für AMD und Intel Prozessoren kompilieren: Bin mir nicht sicher ob das einén kleinen Leistungsschub bringt, wenn ja wäre es sinnvoll und fast ohne Aufwand zu bewerkstelligen.

Download und Upload besser synchronisieren in Einstellungen: wenn man den upload wert runtersetzt, geht ja bekanntlich auch der download wert ab <10 upload runter. wenn man dann jedoch den upload wert wieder hochstellt, bleibt der download so niedrig. manchmal vergisst man das. wenn man den download trotzdem so niedrig haben möchte kann man das danach dann ja wieder manuell einstellen aber erstmal automatisch mit hochziehen lassen...

DCC in IRC Client: ist mir jetzt schon oft passiert: ich chatte mit eMule IRC und dann will mir einer ne Datei schicken per DCC. Leider hat eMule keine DCC Funktion. wäre sehr praktisch da man dann nicht zwei Programme nutzen muss

beim Beenden minimieren: optional beim Klick auf das X wird eMule minimiert (edonkey old school style ;-)

64 Bit Unterstützung: erst interessant wenn windows 64 bit final ist. dann aber bestimmt nützlich...


so das wars...gebt doch eure meinung zu den einzelnen sachen ab oder fragen...

sehr löblich, wenn sich jemanden gedanken macht, um den emule zu verbessern.
zum upload bleibt zu sagen, solange die meisten ihren upload nur auf 10kb stellen, weil sie angst um ihren ach so sehr geliebten download haben, stellt sich die frage, was da optimiert werden sollte. 10kb sind 10kb, ob optimiert oder nicht. leider sind auch die meisten dsl angebote gar nicht auf hohen upload ausgelegt, sondern eher für einen hohen download, wobei hier wieder die frage auftritt, was man mit einem hohen download anfangen soll wenn der upload das einfach nicht hergibt. allerdings besteht beim upload sicherlich für diejenigen optimierungsbedarf, die gewillt sind, mehr als die 10kb zu geben.
die 64bit unterstützung ist meines erachtens nicht notwendig. mein kleiner 450er amd k6/3 läuft einwandfrei mit dem emule, sodass hier aus meiner sicht nicht die notwendigkeit einer optimierung vor liegt. ich denke, das würde nur neue probleme zu tage bringen (Kompatibilät und dergleichen).
winsock 2.2: da kenne ich mich zu wenig aus. sollte das aber ein update auf ie6 incl. sp voraussetzen, halte ich das für die schlechtere wahl. es gibt user (so wie mich) die keinen ie nutzen. was soll ich also ein update machen für etwas, was ich weder brauche noch nutze.
overall-hard-limit: hierbei befürchte ich, dass der emule dann noch mehr mit verwalten beschäftigt ist, da er die ganze zeit überprüfen muss, welche dateien jetzt wieviel quellen hat.

bitte jetzt nicht falsch verstehen, das ganze soll jetzt keine kritik an deinen vorschlägen sein. für einen mod sind die ansätze sicher gut, für den originalen emule, der ja soviele user wie möglich anprechen soll mit der verschiedensten hardware wäre das sicher nicht von vorteil, da hier zuviel berücksichtigt werden müsste.

gruss, winki

ok danke für dein feedback. deine argumente sind logisch. bei upload optimieren hast du mich jedoch nicht richtig verstanden. ich meinte damit das wenn einer 10 kb geben will, das er dann auch konstant 10kb gibt und nicht weniger (was häufig vorkommt wenn man gerade viele verbindungen hat). also das der upload sozusagen "gepushed" wird und möglichst nahe an die 10kb rankommt auch bei vielen verbindungen oder hohem download.

Re: Feature Wishlist
 

Hab mir mal erlaubt, die Zitate etwas umzusortieren, um gebündelt antworten zu können.

Hier glaube ich allerdings, das da noch Optimierungspotential besteht. Spätestens seit Kademlia kann man eMule mit Overnet vergleichen (und vorher mit eDonkey), da beide auf dem theoretisch (um zum Teil praktisch) gleichen Protokoll basieren. Wenn ich mir aber anschaue, was Overnet hier unter Linux mit maximal 50 Verbindungen insgesamt für Leistung bringt, frage ich mich, was eMule falsch macht :roll:

Dazu kann ich mangels Wissen nix sagen, schließe mich aber Winkis bedenken an.

Darauf warte ich auch schon ewig. Würde einen Haufen Handarbeit ersparen.

Also wenn du möchtest, das mit Hyperthreading zwei verschiedene Programme nebenher arbeiten, dann ist das sowieso der Fall. Sicherlich kann man da noch was optimieren, aber bei Hyperthreading übernimmt Windows selber die Verteilung der Programme auf die (virtuellen) Prozessoren.

Ich bin der Meinung, das ist alles der Mühe nicht wert, kann aber zu Kompatibilitätsproblemen führen. Normalerweise sollte eMule bei ordentlichen, also moderaten Einstellungen nicht soooo viel CPU-Leistung schlucken, schon gar nicht bei einer CPU mit 64 Bit, dort sollte eMule im einstelligen Prozentbereich der CPU-Auslastung sein.

Ich hatte schon Mods am Start, die speziell für AMD optimiert waren, gemerkt hab ich davon nix. Auf schnelleren Prozessoren wird das noch unwichtiger.


Für mich sähe das eher so aus: Weg mit IRC ;-)

Gibts das nicht schon? Grab nochmal in den Einstellungen.

beim Beenden minimieren gibt es noch nicht. ich habe minimiert starten und zum Systemicon minimieren an aber wenn ich oben rechts auf das X klicke wird emule geschlossen...

Ausserdem noch folgendes feature zusätzlich:

HTML-Link Unterstützung für IRC

Thin- Thick Variante (bei jedem Release zwei Varianten: eine mit allen Funktionen und eine mit den nötigsten (ohne IRC, Webinterface, Zeitplaner)

Ok, dann gibts die Option wohl nur in einigen Mods. Hab die Funktion jedenfalls schon benutzt, frag mich aber nicht, in welchem Mod.

aso ok, und was hältst du /haltet ihr von thin- thick variante?

Wie wäre es denn, wenn der Muli selber den Upload in die Hand nimmt.
Ich weiss zwar nicht, ob das möglich ist aber ich stelle mir das so vor:

Der Muli füllt den kompletten nicht zum surfen o.ä. benötigten Upload voll aus. Der User selber muss nicht mehr das Limit angeben. Der Muli ermittelt beim Start die Kapazität selbstständig und regelt dann dynamisch den Upload selber.

Auf diese Weise würde sich auch die ratio Diskussion (Stadard/ZZUL etc erledigen.) Jeder gibt was er kann und mehr kann man aus meiner Sicht nicht verlangen.

Vip2002, das was du da beschreibst ist schon länger im originalen eMule drin.. :roll:
Liest du jemals changelogs!? --> USS

Über Funktion und Verbesserungswürdigkeit des Features wollen wir jetzt nicht weiter reden, da muss noch daran gearbeitet werden.
Bin der Meinung, dass man das SUC v2 oder wie das letzte von [lovelace] hiess, weiter im Auge behalten sollte..




Dazu ist das X ja auch da: X für exit.. ;)
Es sollten doch nun schon genug Optionen da sein, und wenn du versehentlich auf das X klickst und dann nicht möchtest, dass eMule sich schliesst, dann nutze die entsprechende (seit Urzeiten vorhandene) Funktion:
Sicherheitsabfrage beim Beenden. :i:

war schon v3 ;)

das lief bei mir auch etwas besser als das USS "jetzt".

Danke für die Info, war mir nicht mehr sicher.. die letzte [lovelace], die hier lief, basierte auf der 0.30e - echt schade, dass die devs sich das nicht mal genauer angesehen und übernommen bzw. weiterverbessert haben.
Interessant ist auch die Koinzidenz mit [lovelace]s "Verschwinden" nachdem er die Hoffnung hatte, dass sein SUC evtl. in die originale Version aufgenommen wird.. und es dann in der nächsten Release nicht drin war. :evil:

der morph hat das SUC noch drinne.. aber das is wohl die 1. version, oder?

die letzte lovelace war doch ne 30a?? war nur an der E dran, die nie veröffentlich wurde ??

Du hast vermutlich auch hier recht.. :P - ich konnte meine letzte genutzte [lovelace] Version nicht mehr finden.. dachte es wäre die e gewesen, aber das war wohl der Hunter Mod, der zuletzt als 0.30e rauskam, den ich auch noch getestet hatte..

Zu Morph kann ich nichts sagen, ausser dass das feature in der Version vor etwa einem Jahr nicht so gut funktionierte - seit der Morph den IE 6 voraussetzte (was er etwa seit einem Jahr tat - so wie auch der Pawcio und alle auf diesen Mods basierenden weiteren..), konnte ich ihn nicht mehr testen, da er nur noch crashte und der IE 6 kommt mir nicht aufs System.
Angeblich soll der Morph nun auch wieder ohne IE 6 auskommen, aber dies habe ich bisher erst beim Pawcio/Stormit verifizieren können - Morph wird aber auch noch getestet werden demnächst.


Und um auch noch mal so richtig OnTopic zu kommentieren:
Viele Features sind teilweise gut oder zumindest ansatzweise gut in Mods umgesetzt und die devs haben sicher alle Hände voll zu tun, das alles zu checken, zu überlegen, ob es sinnvoll ist im originalen Muli etc.
Man darf eines nie vergessen: der originale eMule muss immer auf allen Windoof-Systemen lauffähig sein - das halten die devs ein und schon das alleine ist eine grossartige Leistung.

Klar lese ich die ;-)
Das Neue /Optimierung wäre, dass der User nichts mehr einstellen muss, sondern eMule alles notwendige selbst ermittelt.

USS handelt doch nur im Rahmen der Einstellungen, und wie hier immer wieder zu lesen haben viele NewBies leider keine Ahnung welche Kapazitäten sie haben und welche Werte wann sinnvoll sind. :roll:

Es ging doch darum, wie man bereits vorhandenes optimieren könnte. Für mich heisst das userfreundlicher gestalten.

Für reine Sauger wäre das wahrscheinlich eine Verbesserung, wenn gleich ich zugebe, dass ich persönlich lieber selber die Kontrolle über die Ressourcen meines Systems habe.

aber wenn es "dächte" man brauche weniger als 10kb up und dann hat man kein unlimited down mehr obwohl es auch mit 10kb up ginge wäre blöd...

also erstmal zu thin-thick, ist in etwa das was ich damals als emule light wollte bzw, mehrfach dem plus team vorgeschlagen habe, viele features sind zum "saugen" einfach nicht noetig -> irc, chat, ... selbst auf die statistiken koennte ich verzichten (im moment sowieso ;) )

dein feature wunsch, "- beim Beenden minimieren" ist im plus mod schon sehr lange drin, (seit 0.22?) jedenfalls hat es vorlost drin!
ausserdem hat der plus mod schon laenger amd/intel optimierungen... ob und was die bringen, vermag ich nicht zu sagen :P

Clever sollte "es" schon sein. ;-)
..ratio wäre dann imho nicht mehr nötig. Jeder gibt was er kann und gut ist. Wer wann zum Zuge kommt regelt das Creditsystem.

- Winsock 2.2 (2) : Hab ich drin läuft super und bringt richtig Schwung in die Sache. Wie sich das bei Leuten ohne IE6 verhält weiß ich nicht werd's jetzt auch nicht ausprobieren ;-) .

- Releases gesondert für AMD und Intel Prozessoren kompilieren (3):
Habe ich so nicht drinne,da für solche Releases einfach die Testmöglichkeiten fehlen.Ich jedenfalls werd mir jetzt nicht extra nen Intel anschaffen ;-) . Aber vielleicht reicht ja der Ewombat [on the fly] Optimizer auch schon hin?! Gestaltet bei mir (Barton 2600XP+) das Arbeiten mit der v0.44d jedenfalls deutlich zügiger gegenüber dem Original.

- Overall Hard Limit (2)
Ist in Arbeit und ich glaube das funzt nochmal zusätzlich zu Winsock2.2 und dem Optimizer richtig rein. Hab mich da für die AutoHL Variante von Wizard entschieden die z.B. 4000 Quellen optimal über die aktiven DL's verteilt und somit auch die - Overhead reduzieren (1) Option erfüllt. Genaueres muß man dann mal testen. Wizard ist aber immer eine gute Wahl (meiner Meinung nach)

- Download und Upload besser synchronisieren in Einstellungen (3):
Das macht sogar das Original ohne USS ganz gut.Probleme gibt es vor allem mit dem Upload erst dann wenn man die Quellenanzahl deutlich überschreitet. Dies sollte sich mit Overall Hard Limit eigentlich erledigen.

- Uploadsystem optimieren (1)
Das ist der heilige Gral ;-) ein Konzept habe ich schon nur die Umsetzung in Code ist mir noch schleierhaft. Mein Plan sieht vor alles über 10kb/s für einen bzw. zwei Spezial-Slots zu reservieren und diese 2-4kb/s ausschließlich zum Downpushen von High Queue Sources zu verwenden. Das heißt um was davon zu haben muß man schonmal mehr als 10kb/s Upload frei geben. Ergänzend mit Overall Hard Limit soll diese Feauture bewirken,daß die Quellen reduziert werden und dafür aber qualitativ hochwertiger sind (LOW_Queue,möglichst viele Chunks des gesuchten Files zur Verfügung).

Wenn ich das hinbekomme dürft ihr mich wegen mir auch Modder schimpfen,aber ich denke mal bis dahin ist es noch ein weiter Weg.

MfG Max

Hallo Max,

ehrlich gesagt habe ich das noch nicht ganz verstanden. Darum frage ich einfach mal nach :-)
"Downpushen von HQ-Sources" - gezielt Quellen beliefern, bei denen ich sehr schlechte Platzierungen habe, um mit Hilfe der Kredite eine bessere Platzierung zu bekommen?

"... Quellen reduziert werden und dafür aber qualitativ hochwertiger sind (LOW_Queue,möglichst viele Chunks ...)" Ich nehme also nicht alle Quellen an (Autohardlimit) und versuche, die, die ich annehme, nützlich zu machen?

Mit freundlichen Grüßen
aalerich

Hallo aalerich,

schön das dich meine Idee zumindest soweit interessiert,daß du mit mir darüber sprechen möchtest.
Evtl. habe ich ja ein paar Aspekte noch nicht bedacht und du möchtest mit mir zusammen mal ein wenig laut darüber nachdenken ;-) .

Also zu erstens:
Prinzipiell richtig,aber warum sollte ich das bei sehr schlechten Quellen tun ich will ja möglichst schnell große Stücke downloaden ohne viel Overhead zu haben. Also versuche ich sehr schlechte Quellen möglichst wenig oder selten abzufragen und konzentriere mich auf die bei denen ich bessere Chancen habe unter die sagen wir mal ersten 50 Wartenden zu kommen.

Ich verdeutliche das mal an einem Zahlenspiel wobei die Zahlen nur als Beispiel zu werten sind.

Angenommen du hast vom Overall Hard Limit noch 300 Quellen zur Verfügung könntest aber theoretisch 456 Quellen haben. Da müßtest du auf Beispiel 100 Full Queue und 56 High Queue Quellen verzichten, also der einfach halt halber nehmen wir mal an die 56 Höchsten. Man muß die ja nicht ganz verwerfen man kann sie ja erstmal irgendwo merken oder zwischen Speichern für ein späteres Reask.

Das ist der erste Teil der Gleichung...nun der zweite....

Jetzt hast du 300 Quellen davon haben 21 einen QR-Rank von <50. Da du dich ja nun deinem Muli zuliebe von 156 Quellen getrennt hast sollte man ja wenigstens in den unteren Rängen etwas verschieben. Also sagen wir mal statt 21 Quellen <50 möchtest du 35 Quellen (erstmal wollen wir ja realistisch bleiben wir haben ja normalerweise nur 2-4kb/s zur Verfügung und wollen ja auch nicht nur ein File Pushen). Also nehmen wir die 14 Quellen mit nächst niedrigsten QR und checken ob die etwas von uns haben möchten. Diesen Check wiederholen wir so lange bis wir 14 Quellen zusammen haben an die wir auch was Uploaden können und öffnen dann 1-2 Slots bei ner dickeren DSL Leitung auch mehr und beginnen mal mit uploaden.

Jetzt wird es natürlich kniffelig was ich mit meinen Upload bewirke merke ich ja frühestens nach dem Reask und das möchte ich natürlich nicht zu oft machen und vor allem nicht in zu kurzen Zeitabständen...(Bangefahr und das mit Recht).Also halten wir uns an die vorgegebene Reask Zeit zumindest bei diesen Quellen. Damit wir jetzt nicht uploaden und uploaden kriegt jede der 14 Quellen erstmal eine Menge x an MB (muß man mal abschätzen was ca. nötig wäre um ein paar QR nach oben zu rutschen kann man ja per Eingabe den Nutzer entscheiden lassen) und es wird dann zum nächsten File übergegangen der normale Reask Zyklus bleibt davon völlig unberührt und auch die normale Upload Queue mit den 10kb/s da wir ja auch bei unseren anderen Files und bei den High Queue Sources irgendwie voran kommen wollen. Bei den gepushten Files würde ich die Reask Zeit für z.B. nicht benötigte Quellen sogar erhöhen. Merken aus der DL-Queue werfen und nach 2 h Stunden nochmal vorbei schauen ob er mittlerweile was brauchbares gesaugt hat.

Was machen wir mit den 2-4kb/s wenn wir alle gepushten Files so haben wie wir das wollten? Die 2-4kb/s zum normalen Up dazu oder lieber das nächste File auf Auto Push?

Es gibt da schon noch vieles zu überlegen,aber das müssen wir ja nicht alles heute morgen bereden. Da kann man ja nochmal drüber schlafen. Meld dich einfach hier wenn du noch Fragen hast oder was anmerken möchtest ich bin ganz Ohr oder besser Auge ;-)

Erstmal nehme ich alle an und entscheide dann welche sind nützlich und welche nicht und muß ich überhaupt welche rauswerfen oder reicht mein Overall Hardlimit gar für alle Quellen? Das sollte dann wahrscheinlich auch garnicht ins Uploadmanagement sonderen direkt ins Overall Hardlimit. In bezug auf den Overhead könnte man höchstens besonders schlechte Quellen entsprechend ihrer Qualität weniger abfragen.

[EDIT:]->Habs gerade gelesen and hat zu dem Thema ja schon was gepostet :

http://www.emule-web.de/board/showth...24&postcount=1

<-[:EDIT END]

Keine benötigten Teile alle paar Stunden,Volle im Normalen Zyklus,von 1000- x QR alle 40 min oder so,QR<1000 im Normalen Zyklus.

OK jetzt muß ich aber mir fallen gleich die Äuglein zu *fg*

MfG Max

Hallo Max,

ach so, Du meintest mit "High Queue Sources" eigentlich "High Qality Sources".

Generell muß ich sagen, daß ich kein großer Freund dieser Spielereien mit den Queuerankings bin. (Warum soll Xman der einzige sein, der mein Genörgele ertragen muß?:evil:) Das liegt einfach daran, daß die Queuerankings so furchtbar wenig aussagen; diese Zahlen haben kaum praktischen Wert. Ich habe mal in 2 1/2 Tagen eine Datei von nur einer Quelle runtergeladen, bei der ich am Anfang auf Platz 55.000 stand...

Wenn ich anhand des Queuerankings entscheide, zu wem ich hochlade, dann mache ich das in Handarbeit. Diese Entscheidung beruht dann auf sehr vielen Faktoren, sogar der Benutzername kann dabei eine wichtige Rolle spielen. Das ein Programm solche Entscheidungen vernünftig fällen kann halte ich für ausgeschlossen.

Hmmm. Wenn Menge x eine vernünftige Größe hat, dann komme ich bei vielen dieser Quellen in den Upload, bevor ich überhaupt dazu gekommen bin, mit diesen 2-4 kb/s jedem diese Menge x zu schicken. Davon abgesehen wäre die Frage, wie groß Menge x mindestens sein muß. Bei einer Größe von 2 mb z.B. wäre es mir, säße ich denn am anderen Ende, lieber, nicht zu dieser Gruppe zu gehören. Dann bekäme ich nämlich selbst ohne TFC vermutlich mehr. Es sei denn, es gibt dafür eine extra Warteschlange. Das würde aber bedeuten, daß zumindest theoretisch jemand gleichzeitig auf zwei Uploadslots sitzen kann...

Da das eine Funktion ist, die den Download gezielt beschleunigen soll und die dabei den Upload automatisch nach dem eigenen Vorteil steuert würde ich denken, daß sie auch mit einem Ratio verbunden sein sollte. Die Lösung mit dem Mindestupload von 10 ist eine ja auch in der offiziellen Version vorhandene Krücke von himmelschreiender Ungerechtigkeit. Aber das ist ein anderes Thema.

Der Beitrag zu dem Thema ist nicht von mir, sondern von and, aber das ist wirklich nicht wichtig. Aber auch diese Idee halte ich nicht für besonders gut. Es gibt viele Dateien, die relativ schnell gehen, für mich und natürlich auch für andere. Da können binnen 10 Minuten viele NNS zu nützlichen Quellen werden und warum soll ich die dann nur alle 2 Stunden abfragen? Xmans Lösung, gedroppte Quellen für 50 Minuten als Quellen zu bannen, gefällt mir da doch besser. Da entscheide nämlich ich, ob ich droppe, wann ich droppe, wen ich droppe und bei welcher Datei ich droppe.

Was ich mir allerdings wünschen würde wäre ein Uploadbann :eek: für volle, von mir gedroppte Quellen :!:

Soweit vielleicht ein paar Gedanken dazu und natürlich

freundliche Grüße
aalerich

Ups,

endschuldige bitte vielmals aalerich da sieht man mal wieder die Folgen von Dauerschlafentzug :-( . NeNe... also sowas ist mir ja noch nie passiert.

Bei mir darfst du ruhig nörgeln solange was produktives dabei rum kommt ist es sogar erwünscht :-) .

Du hast natürlich recht,daß die QR furchtbar wenig aussagen (manche Clients haben gar kein Credit System oder senden einfach keinen Rank),aber ich bin noch nicht so wirklich überzeugt,daß ein gezieltes uploaden überhaupt keine Vorteile bringen soll. Platz 55.000 *kopfkratz* Wer hat solche Warteschlangen??

Sprich... sehr viele Faktoren mag uns viel erscheinen,aber unser PC ist ja lernfähig.

.....Den Rest später jetzt muß ich los,denn wir wollen ja nicht unsere Freunde vernachlässigen. Ich liebe meinen PC,aber noch mehr liebe ich meine Mitmenschen. Besonders die welche mir sehr nahe stehen.

In diesem Sinne ...

Ciao bis morgen früh

Max

Keine Chance. Das Thema der Datei in die Beurteilung der Situation mit einzubeziehen wird einem Programm nie möglich sein.
Deutsche Shareazanutzer sind mehrheitlich Leecher, in Holland nicht. Obwohl oder weil die Dinger dort sehr populär sind (ca. 10%). Von Hand kann ich mir ein Urteil bilden, aber ein Programm?

Nur mal so zwei Beispiele. Kein Programmierer kann jemals die konkrete Situation aller mit seinem Muli herunterzuladenden Dateien bei allen Nutzern seines Mulis vorhersehen und entsprechend vorausschauend programmieren. Ich bin einfach jemand, der es liebt, alle Möglichkeiten zu haben. Je mehr Möglichkeiten ein Mod bietet, desto mehr kann man damit auch machen. Und da ich oft etwas anderes machen möchte als nur schnell runterladen bevorzuge ich Mods, die zwar alle Optionen bieten, aber von allein nichts machen. Ich bin halt ein komischer Vogel...

Mit freundlichen Grüßen
aalerich

...und Du bist nicht allein... :yes:


Januar

Ja und aus diesem Grunde werden ja alle Neuerungen AN und AB -schaltbar sein bzw. die Möglichkeit gegeben die Umgebungsvariablen nach belieben zu verändern. Sprich Overall Hard Limit kann man so weit erhöhen wie man möchte und somit den eigentlichen Sinn dieses Codes aushebeln. Was das Uploadmanagement betriff so es denn wirklich umgesetzt wird da muß ich mir noch gründlich überlegen was man verändern darf und was nicht.

Auf jeden Fall wird im Bereich unter 10Kb/s alles beim alten bleiben und wer über 10kb/s uploaden möchte ohne dieses Feauture deaktiviert es einfach. "Default" wird aus sein.

Übrigens soll es nicht bis zum Download führen so ist es nicht gedacht!! Wer in den Low QR-Bereich kommt wird wieder zurück an die normale Uploadwarteschlange übergeben. Wo dieser Bereich im günstigsten Fall liegt,wieviel MB dafür hochgeladen werden bevor man die nächste Quelle bedient und was mit dem zusätzlichen Upload passieren soll wenn man genug Low Queue Quellen hat muß man testen und analysieren...solange befindet sich diese Funktion in der Beta Phase und wenn es nichts bringt fliegt es direkt wieder raus,aber probieren werd ich es wahrscheinlich erstmal.

Ohne ausgiebigen Test wird sich wohl nicht entscheiden lassen ob es funzt.

MfG Max