NNS

[dimicchh]

Ich hab mal mehrere fragen zum thema NNS, bitte alle die denken qualifiziert dazu zu sein, stellung zu nehmen

-Warum behält emule die NNS in den queues? Das blockiert doch nur den slot und den könnte mein client evtl. zum downloaden einer anderen datei bei diesem user nutzen. Ich denke nicht, dass emule prüft ob A4AF möglich ist, sondern behält die NNS pauschal in der queue.

-Was bitte bringt NNS timer, wenn er wie im 42g mod frühestens bei 50% des HL anspringt? Wenn ich das richtig deute heisst das folgendes: erst wenn die NNS 50% des HL betragen, fängt er an zu dropen. Selbst das ist aber schon ein ausnahmefall, schliesslich hab ich bei einem durchschnittlichen download nie und nimmer 175 NNS (hab HL 350). Also werden im normalfall die 0-174 NNS dringelassen und blockieren slots wie oben beschrieben.

- Gibt es eine andere möglichkeit, NNS zu droppen ohne es manuel machen zu müssen (ausser NNS timer natürlich, der wie schon oben bemerkt nicht viel bringt)?
@Sivka: warum kann ich NNS-% nicht frei wählen sondern nur 50 aufwärts?



NNS=not needed sources
HL=hard limit

thx

[Pathfinder]

Willkommen an Board, dimicchh!

Zu den NNS gibt es zwei Argumente, die das Verhalten von Sivkas MOD rechtfertigen.

Zum einen ist es die Tatsache, dass Quellen ohne benötigte Teile diesen Zustand auch recht schnell wieder verlieren können. Stell dir jemanden vor, der derzeit nichts für dich hat aber gerade einen Chunk der dir fehlt zu 90% runtergeladen hat. Sobald er diesen vollständig hat wird er seinen Zustand wechseln und wieder als gültige Quelle zur Verfügung stehen. Daher ist es sinnvoll die NNS als Quellen stehen zu lassen und regelmäßig anzufragen.

Zum anderen ist das Problem von zu vielen aktiven Verbindungen ein Hemmschuh des automatischen Dropping. Je größer die Differenz zwischen HardLimit und tatsächlicher Quellenzahl, desto intensiver sucht eMule nach neuen Quellen. Droppst du nun eine größere Zahl NNS aus deiner Liste wird eMule sofort nach neuen Quellen suchen, dabei werden sehr viele der NNS unmittelbar wiedergefunden und neu abgefragt. Das verursacht einen Anstieg der aktiven Verbindungen, deren Overhead dann deinen Upload beschneidet. Daher ist von agressivem Dropping abzuraten. Sivka hat das auf Grund der Erfahrungen mit den Vorversionen mit einem %-Wert von 50+ gelöst, damit nicht ständig gedroppt wird.

Hast du einen Download mit recht vielen NNS, kannst du das HardLimit bei dieser Datei auch einfach ein wenig höher stellen um noch ein paar gültige Quellen zu finden.

[dimicchh]

Danke für deine kompetente antwort! Was du beschrieben hast klingt sehr plausibel und klärt einiges auf für mich.

Jedoch bleibt noch ein punkt der denke ich trotz allem ein agressives NNS droping rechtfertigt. Dazu ein kleines beispiel, der auslöser meiner gedanken:

Zur zeit lade ich eine serie runter, 10-15 folgen gleichzeitig. Nun ist mir auch durch experimentieren mit A4AF folgendes aufgefallen: jeder serienteil besitzt ca. 20-50 autonome quellen, ein grossteil der quellen (ca. 200) jedoch ist gemeinsam, will heissen jeweils 50 user haben nur eine der folgen auf dem rechner, 200 dagegen haben mind. 2 oder mehr folgen. Das ganze erscheint mir auch sehr logisch und dieses verhalten treffe ich auch bei mir selbst wieder: bei manchen serien zB die aktuell laufen habe ich nur 1-2 folgen (die neusten), bei anderen wo ich die komplette season runterlade hab ich natürlich mehrere.

Jetzt zur NNS problematik: lade ich sagen wir 15 teile einer serie runter, mit der verteilung wie ich sie oben beschrieben habe. Dann habe ich auf meine 15 downloads verteilt vielleicht 20% NNS und diese blockieren downloadslots! Ein einfaches beispiel: teil 1 der serie hat 25 NNS, 15 davon könnten vielleicht bei teil 3, 5 und 11 als gültige queues genutzt werden, geht aber nicht da sie hier blockiert werden. Oder anders gesagt: teil 3, 5 und 11 haben jeweils 5 quellen mit status A4AF(teil1). Schade nur dass teil1 diese quellen gar nicht braucht weil sie NNS sind.

In diesem fall macht es also durchaus sinn, regelmässig die NNS zu droppen um den anderen dl´s die aus den quellen was sinvolles machen können die möglichkeit zu geben, an sie ranzukommen.
Was noch viel sinnvoller wäre, wenn es eine "drop NNS to A4AF" funktion geben würde, eine schleife die prüft ob NNS evtl bei anderen dateien gebrauch werden könneten und sie dann zuweist.
Vielleicht ein verbesserungsvorschlag für die nächste version

[Pathfinder]

In diesem Falle geht es weniger um eine verbessertes NNS-Handling als vielmehr um eine günstigere Erkennung von A4AF-Quellen. Häufiges Dropping um die NNS-Quellen zufällig einem anderen File zuweisen zu können erscheint mir nicht erstrebenswert und ist eher die "Holzhammermethode".

Wenn du häufig Serien lädst kann ich dir einen Blick auf den Morph-MOD und seine Ableger raten, dort ist die A4AF-Behandlung weiter entwickelt als im Sivka-MOD. Es gibt dort die Möglichkeit diese Quellen linear auf eine Folge nach der anderen zu kumulieren (Stacking) oder sie gleichmäßig auf alle Folgen zu verteilen (Balancing).
Das wäre imho der sinnvollere Wunsch für Sivka's Featureliste.

[cosmic girl]

Oder aber man macht es so, wie es eigentlich eh empfehlenswert ist:
Pro season nur 2-3 episodes gleichzeitig laden - damit erledigen sich die Probleme von selbst.

[dimicchh]

Zitat von cosmic girl

Oder aber man macht es so, wie es eigentlich eh empfehlenswert ist:
Pro season nur 2-3 episodes gleichzeitig laden - damit erledigen sich die Probleme von selbst.

tut mir leid aber das kann keine lösung sein. nicht was die akademische seite, auch nicht was die praktische seite betrifft. wenn es nach diesem argument geht kannst du auch gleich sagen "lad am besten gar nix runter, dann hast du auch kein problem" ausserdem gibt es wie gesagt bei jedem teil eine nicht geringe anzahl an autonomen quellen. bei 10 dl´s betragen die autonomen quellen in etwa 200% der A4AF quellen, derjeniger also die mehrere teile haben. und ganz ehrlich... es sind zwar nur 35 quellen pro dl aber diese 350 quellen will ich trotz dem nicht missen.

Zitat von Pathfinder

Häufiges Dropping um die NNS-Quellen zufällig einem anderen File zuweisen zu können erscheint mir nicht erstrebenswert und ist eher die "Holzhammermethode".

Da muss ich dir leider auch wiedersprechen. Es ist zwar eine ziemlich agressieve methode jedoch denke ich nicht, dass es nicht erstrebenswert ist. Das zeigt zumindest die erfahrung die ich gemacht habe:
Wenn bei einem dl der sagen wir 150 brauchbare, 40 NNP und 0 A4AF quellen hat (ein beispiel von grad eben bei mir) ich manuel alle 40 NNP droppe dann sieht man wie im gleichen moment die brauchbaren quellen der anderen dateien aus der serie ansteigen. nach einer weile habe ich dann bei meinem dl nunmehr 150 brauchbare 0 NNP und 40 A4AF.
Das heisst nix anderes als dass alle 40 quellen die ich gepropt habe bei meinen anderen dl´s untergekommen sind da sie ja jetzt hier als A4AF erscheinen!!! Und das ist genau der gewünschte efekt!
Natürlich sind diese zahlen etwas gerundet und es werden sich auch nicht immer alle quellen optimal unter den anderen dl´s verteilen aber die effektivität ist auf jeden fall um einiges gestiegen!

[edit by Pathfinder: Doppelposts zusammengefasst. Board-Rules beachten!]

Das problem bei dieser methode ist, dass nicht bei jedem dropping alle quellen wieder meinem client zugeordnet werden sodern es können sich andere leute welche "ermogeln". Umgehen kann man dies in dem man mir A4AF die quellen hin und her "wirft". Dadurch findet eine natürliche verteilung statt da die NNS koplett übernommen werden. Aber wer hat schon bock und zeit sich die ganze zeit mit seinem muli zu beschäftigen. Daher mein vorschlag:

Zitat von dimicchh

Was noch viel sinnvoller wäre, wenn es eine "drop NNS to A4AF" funktion geben würde, eine schleife die prüft ob NNS evtl bei anderen dateien gebrauch werden könneten und sie dann zuweist.

[cosmic girl]

Zitat von dimicchh

tut mir leid aber das kann keine lösung sein. nicht was die akademische seite, auch nicht was die praktische seite betrifft. wenn es nach diesem argument geht kannst du auch gleich sagen "lad am besten gar nix runter, dann hast du auch kein problem" ausserdem gibt es wie gesagt bei jedem teil eine nicht geringe anzahl an autonomen quellen. bei 10 dl´s betragen die autonomen quellen in etwa 200% der A4AF quellen, derjeniger also die mehrere teile haben. und ganz ehrlich... es sind zwar nur 35 quellen pro dl aber diese 350 quellen will ich trotz dem nicht missen.

Du kannst dich auf den Kopf stellen und mit den Füssen wackeln - es ändert immer noch nichts an der Tatsache, dass die Praxis einfach anders ausschaut. Typischerweise haben series eben keine 350 Quellen pro episode und daher auch keine "autonomen" in der Grössenordnung, die ein gleichzeitiges Laden von mehr als 4 files rechtfertigen könnte.
Als jemand, der die Anfangszeiten mit dem eDonkey erlebt hat, kann ich dir sagen, der Zufall (so wie beim eDonkey damals noch meistens alles geregelt war) ist manchmal der allerbeste Freund..
Sieht man doch daran, dass man den allercleverst getuneten Mod nutzen kann und auf lange Sicht damit keine besseren Raten erzielt als mit einer einfachen (evtl. auch älteren) Version. (Dies ist nicht nur meine Erfahrung!)
Es gibt auch Stimmen, die sagen, dass der eDonkey derzeit wieder wesentlich besser läuft als die Mulis.. wie erklärts man sich das z.B.!? Vielleicht zu viel Geschraube und Manipulation und daher weniger Erfolg?

Zitat von dimicchh

Da muss ich dir leider auch wiedersprechen. Es ist zwar eine ziemlich agressieve methode jedoch denke ich nicht, dass es nicht erstrebenswert ist.

Doch - aus Gründen der Netzwerkfreundlichkeit ist so etwas nicht erstrebenswert!

Zitat von dimicchh

Das problem bei dieser methode ist, dass nicht bei jedem dropping alle quellen wieder meinem client zugeordnet werden sodern es können sich andere leute welche "ermogeln". Umgehen kann man dies in dem man mir A4AF die quellen hin und her "wirft". Dadurch findet eine natürliche verteilung statt da die NNS koplett übernommen werden. Aber wer hat schon bock und zeit sich die ganze zeit mit seinem muli zu beschäftigen. Daher mein vorschlag:

Bin mir nicht sicher, aber sollte das nicht das Auto A4AF genau so machen!? Ok, bei den meisten Mulis kann man die Auto A4AF wohl nur je einem einzigen file zuordnen - um es anders zu regeln müsste man in der Lage sein einzelne file Gruppen definieren zu können, innerhalb derer Muli dann mit den Quellen jonglieren kann.
Aber wie gesagt, aus Trafficgründen ist zuviel wiederholtes Anfragen eben nicht erwünscht.
Und wenn du dir mal anschaust, dass es inzwischen einige Mods gibt, die clients mit zu schneller Folge der Anfragen bannen, dann weisst du, dass es keinen Sinn macht, denn die bannen nicht aus Spass, sondern eben um die Belastung zu unterbinden, die durch Verhalten dieser Daueranfrager bei einer queue von 5000 oder mehr eben entsteht (über Sinn und Unsinn einer q von 5000 oder mehr wollen wir jetzt aber hier bitte nicht diskutieren).
Dieser thread von sivka sei an dieser Stelle zur Lektüre empfohlen: http://www.emule-web.de/board/viewtopic.php?t=8750

[dimicchh]

Tut mir leid, ich glaube du hast mich in einigen sachen nicht vertsanden, bzw. nicht das gelesen was da stand.

Zitat von cosmic girl

Du kannst dich auf den Kopf stellen und mit den Füssen wackeln - es ändert immer noch nichts an der Tatsache, dass die Praxis einfach anders ausschaut. Typischerweise haben series eben keine 350 Quellen pro episode und daher auch keine "autonomen" in der Grössenordnung, die ein gleichzeitiges Laden von mehr als 4 files rechtfertigen könnte.

Lies mein post bitte genauer, du hast ihn sogar zitiert!!!! Ich sprach nich von 350 quellen pro episode, ich schrieb 35 quellen pro episode im durchschnitt, das sind bei 10 downloads 350 quellen. Klar sinkt die relative effektivität je mehr episodes man runterläd (wen kümmerts??), die absolute effizienz steigt dagegen, es ist eine einfache rechenaufgabe (die zahlen sind nicht fiktiv sondern stammen aus meinen aktuellen downloads):
wir nehmen zur einfachheit an, wir haben per A4AF alle gemeinsamen quellen episode_1 zugeordnet und alle anderen episoden besitzen nur noch ihr autonomen quellen

dein beispiel:
episode_1 200 quellen (autonome+A4AF)
episode_2 35 (autonome)
episode_2 35 (autonome)
episode_2 35 (autonome)
--------------------------
summe: 305 quellen

mein beispiel:
episode_1 200 quellen (autonome+A4AF)
episode_2 35 (autonome)
episode_3 35 (autonome)
episode_4 35 (autonome)
episode_5 35 (autonome)
episode_6 35 (autonome)
episode_7 35 (autonome)
episode_8 35 (autonome)
episode_9 35 (autonome)
episode_10 35 (autonome)
--------------------------------
summe : 515 quellen

Bin mir nicht sicher, aber sollte das nicht das Auto A4AF genau so machen!? Ok, bei den meisten Mulis kann man die Auto A4AF wohl nur je einem einzigen file zuordnen - um es anders zu regeln müsste man in der Lage sein einzelne file Gruppen definieren zu können, innerhalb derer Muli dann mit den Quellen jonglieren kann.]

Nein, das was ich vorgeschlagen hab mach das A4AF nicht.
A4AF angewendet auf beispieldatei "A", ordnet alle quellen die der client gefunden hat und die er vorher, je nach prioritätshöhe der einzelnen downloads, anderen dateien B, C, D und F zugeordnet hat nun dieser datei A hinzu.

Ausführlich heist das: da man von einer quelle jeweils nur eine datei in der warteschlange haben kann erscheinen bei datei A einige quellen wie folgt:
A4AF (datei_B)
A4AF (datei_C)
A4AF (datei_D)
A4AF (datei_B)
A4AF (datei_F)
das heisst das diese quellen den jeweiligen anderen dateien (B, C, D etc.) zugeordnet sind da die quellen sowohl datei A als auch B (und/oder C etc.) besitzen, der client die quelle aber NUR einer datei zuordnen kann. wenn man bei datei A also "alle quellen dieser datei zuordnen" anclickt, werden diese 5 als beispiel angeführten A4AF den anderen dateien "weggenommen" und der datei A zugeordnet.

Nicht mehr und nicht weniger. NNS spielen hierbei keine rolle. nur insofern dass du zufällig den gewünschten effekt erzielen kannst wenn nämlich folgende quellenzuordnung
A4AF (datei_D)
bei der datei D zwar drinsteht aber dort als NNS geführt ist. Dann kannst du durch A4AF umweisung auf A, der datei D diese quelle wegnehmen (die sie eh nicht braucht da sie keine teile mehr für D besitzt) und darauf hoffen dass sie bei A noch gebraucht wird.
Eine derartige automatische prüfung und umsetzung schlage ich vor.


Grad eben bin ich in einem anderen forum auf folgendes gestossen: ein mod behauptet, dass emule alle sich in der liste befindenden downloads prüft, erst wenn keiner der downloads einen teil benötigt wird sie irgendeiner datei als NNS zugewiesen, mit anderen worten bezieht sich das "not needed sources" nicht auf das bestimmte file sondern auf alle files die sich in der downloadliste befinden. wenn das stimmt wäre diese diskusion hier für die katz aber das kann ich nicht ganz glauben, es stimmt nicht mit meinen beobachtungen überein.
wenn das der fall wäre dann müssten ja bei einer A4AF zuweisung die meisten vorhandenen NNS nunmehr in dieser datei auffindbar sein und aus den anderen verschwinden (im falle dass er die NNS mitnimmt bei der A4AF zuweisung) bzw. alle NNS sich immer nich dort befinden wo sie vorher waren (im falle dass er sie nicht mitnimmt). die summe aller sich im emule befindenden NNS müsste demnach so oder so die selbe bleiben. dies ist nach meinen beobachtungen nicht der fall. die NNS werden weniger, was daraufhindeutet, dass er die NNS nicht nur "mitnimmt" sondern auch dort wo er sie "mithinnimmt" zu brauchbaren quellen umwandelt. das könnte nicht der falls sein, wenn er von vornhinein alle anderen dateien nach brauchbarkeit untersucht hätte.

zum thread siehe hier: http://www.emuleforum.net/t37763.html


puuh.... bald kann ich ne doktorarbeit darüber schreiben *g*

[Micha38162]

Zitat von dimicchh

Wenn ich das richtig deute heisst das folgendes: erst wenn die NNS 50% des HL betragen, fängt er an zu dropen. Selbst das ist aber schon ein ausnahmefall, schliesslich hab ich bei einem durchschnittlichen download nie und nimmer 175 NNS (hab HL 350). Also werden im normalfall die 0-174 NNS dringelassen und blockieren slots wie oben beschrieben.

Diesem Irrtum bin ich bis vor kurzem auch unterlegen bis ich mal ein wenig damit experimentiert habe. (Übrigens auch bei einer Serie.

Er fängt nicht an zu droppen wenn Du 50% NNS hast sondern die gefundenen Quellen (alle) 50% des HL betragen.

Ich finde bei mir sagen wir mal 50 Quellen wovon 10 NNS sind.
Stelle ich mein HL nun auf 80 Und dropNNS auf 50% dann werden alle 10 gedroppt denn die Routine beginnt bei 50% von 80 =40 zu arbeiten.

Beim droppen wird zuerst geprüft ob die Quelle einer anderen Datei zugeordnet werden kann und erst wenn das nicht der fall ist fliegt Sie ganz raus. (Zumindest hab ich das mal in einer Erläuterung der Funktion gelesen)

Hast Du nun also ein HL von 350 eingestellt und 50% wird bei 175 gefundenen (Gesamtquellen) begonnen NNS zu droppen und bei einer Serie ist die Wahrscheinlichkeit ziemlich groß das Sie anderen Dateien zugeordnet werden können.

Das Problem ist nur unter 25 gefundenen Quellen funzt das nicht mehr
(wg HL min 50, davon 50%=25)
Bei Dateien mit nur 10 Quellen kannst Du also nur noch manuell droppen.

[Micha38162]

Ich hab nochmal ein Foto gemacht und wie man sieht keine einzige NNS zu sehen dafür jede Menge A4AF.

Ich hab allerdings mal ne Frage zu den Zahlen in der Kategorie.

Was sollen die ersten Zahlen bei SRC und HL bedeuten?

Also SRC (???/1527) und HL (???/5040)

Auch sind mir unter HL die ersten zwei Werte zu jeder Datei bisher noch ein Rätsel!

[dimicchh]

Danke Micha38162 für diese aufklärung. So wie du es beschreibst macht es tatsächlich viel mehr sinn.

Zitat von Micha38162

Beim droppen wird zuerst geprüft ob die Quelle einer anderen Datei zugeordnet werden kann und erst wenn das nicht der fall ist fliegt Sie ganz raus. (Zumindest hab ich das mal in einer Erläuterung der Funktion gelesen)

Auch das macht sinn, wenngleich ich da noch so meine zweifel habe. Ist es tatsächlich so, dann ist ja die von mir geforderte "drop NNS to A4AF" funktion schon indirekt implementiert. Kannst du mir bitte sage wo genau du das nachgelesen hast?

Was deine frage betrifft kann ich dir leider keine antwort geben, ich weiss es selbst nicht. Ich weiss nur was die zahlen hinter den dateien unter SRC bedeuten:
(123/34/41) (1) heisst dass 123 anderen dateien zugewiesen sind (A4AF), 34 brauchbare quellen existieren, 41 quellen insegesammt existieren (34 brauchbare, 7 NNS) und dass von 1 quelle grade geladen wird.
Aber das wusstest du wahrschleinlich schon.


Noch ein nachtrag zu meinem post: die A4AF gelten definitiv nur für einen download, nämlich dem dem sie zugeordnet sind und nicht für alle aus der liste. Ich habe es heute nachgeprüft, in dem ich manuel eine bestimmte quellen hin und her geschoben habe, bei der einen datei war sie NNS, bei der anderen brauchbar. Gut man kann jetzt zwar behaupten, dass zum zeitpunkt wo sie der einen als NNS zugeordnet wurde, sie auch bei der anderen NNS war, als ich verschoben habe hatte der emule auf der anderen seite den part inzwischen runtergeladen, deshalb konnte die dann wieder gebraucht werden.... naja n bischen seeehr unwahrscheinlich, vorallem wenn man es bei mehren nachprüft.

[Micha38162]

Ich hatte vorhin schon versucht den Beitrag zu finden und siehe da es war tatsächlich hier im Forum.

Zu lesen hier Sivka-FAQ

Da steht unter Punkt 6:

Vor jedem auto-droppen wird versucht, A4AF-quellen den anderen dateien zu übergeben. es wird nur noch 1 NNS pro zeiteinheit gedropped, bei 0 werden alle NNS gleichzeitig rausgeworfen

Ob das alles so stimmt weiß ich nicht da sich die Erklärung auf ne ältere Version bezieht aber Sinn macht es schon.

Vielen Dank aber die Bedeutung dieser Zahlen kannte ich wirklich schon!

[Pathfinder]

Zitat von dimicchh

Grad eben bin ich in einem anderen forum auf folgendes gestossen: ein mod behauptet, dass emule alle sich in der liste befindenden downloads prüft, erst wenn keiner der downloads einen teil benötigt wird sie irgendeiner datei als NNS zugewiesen, mit anderen worten bezieht sich das "not needed sources" nicht auf das bestimmte file sondern auf alle files die sich in der downloadliste befinden. wenn das stimmt wäre diese diskusion hier für die katz aber das kann ich nicht ganz glauben, es stimmt nicht mit meinen beobachtungen überein.
wenn das der fall wäre dann müssten ja bei einer A4AF zuweisung die meisten vorhandenen NNS nunmehr in dieser datei auffindbar sein und aus den anderen verschwinden (im falle dass er die NNS mitnimmt bei der A4AF zuweisung) bzw. alle NNS sich immer nich dort befinden wo sie vorher waren (im falle dass er sie nicht mitnimmt). die summe aller sich im emule befindenden NNS müsste demnach so oder so die selbe bleiben. dies ist nach meinen beobachtungen nicht der fall. die NNS werden weniger, was daraufhindeutet, dass er die NNS nicht nur "mitnimmt" sondern auch dort wo er sie "mithinnimmt" zu brauchbaren quellen umwandelt. das könnte nicht der falls sein, wenn er von vornhinein alle anderen dateien nach brauchbarkeit untersucht hätte.

Du darfst bei deinen Beobachtungen nicht vergessen, dass der Status einer Quelle in deiner Liste immer ein gewisses Alter hat! Quellen werden afaik im orginalen eMule alle 29 min neu abgefragt, NNS kann also schon lange hinfällig sein, weil die Quelle in der Zeit einen Chunk fertiggestellt hat. Die Erkennung von NNS zu A4AF ist damit recht träge und muss über einen längeren Zeitraum beobachtet werden.

Meiner Erfahrung nach trifft es zu, dass die Erkennung von NNS auf alle im Download befindlichen Dateien angewendet wird, am einfachsten lässt sich das testen, wenn man bei einer Serie zunächst nur Episode 1 lädt. Dabei werden einige NNS gefunden. Startet man nun Episode 2, so werden die NNS, die auch Quelle für E2 sind, zu A4AF und werden als Quelle zu E2 übernommen.

[dimicchh]

2 posts weiter oben:

Zitat von dimicchh

Noch ein nachtrag zu meinem post: die A4AF gelten definitiv nur für einen download, nämlich dem dem sie zugeordnet sind und nicht für alle aus der liste. Ich habe es heute nachgeprüft, in dem ich manuel eine bestimmte quellen hin und her geschoben habe, bei der einen datei war sie NNS, bei der anderen brauchbar. Gut man kann jetzt zwar behaupten, dass zum zeitpunkt wo sie der einen als NNS zugeordnet wurde, sie auch bei der anderen NNS war, als ich verschoben habe hatte der emule auf der anderen seite den part inzwischen runtergeladen, deshalb konnte die dann wieder gebraucht werden.... naja n bischen seeehr unwahrscheinlich, vorallem wenn man es bei mehren nachprüft.

Ich werd das mit der serie was du vorschlägst jedoch bei nächster gelegenheit testen.