|
Mein File completed nicht. Wieso?
Es ist eine alte "Krankheit" im Esel, dass es manchmal anscheinend nicht möglich ist, einen Download zu beenden. Dabei ist es gleich, ob man eDonkey, OverNet oder eMule verwendet. Hier spielen mehrere Faktoren mit.
a) Das File ist einfach noch nicht fertig. Und dafür ist die Angabe der gesaugten Bytes nur ein Anhaltswert. Wenn nämlich während des Downloads korrupte Teile gesaugt wurden, werden die später noch "nachgesaugt". Dabei werden auch die nachgesaugten Daten mit aufaddiert. Das kann sich um einige wenige hundert KB handeln, aber auch um viele Megabyte. Selbst eine "Übermenge" von mehreren hundert Megabyte ist zwar selten, aber nicht ausgeschlossen! (Der Autor hat es auch schon erlebt, 1,5 GB für ein 700 MB File zu benötigen)
b) Da man ja immer nur zu einem User Connect haben kann, ist die Wahrscheinlichkeit gerade beim letzten Chunk niedriger, dass man gerade hierfür Connect bekommt und nicht nur auf Platz 2222 in der Queue steht. Das ist auch der Grund dafür, dass gegen Ende eines Files immer die Downloadgeschwindigkeit auf nahe 0 absinkt. Hier ist dann einfach ein wenig Geduld angesagt.
c) Allerdings haben auch sowohl eDonkey, als auch eMule vereinzelt wirklich Probleme beim completen eines Files. Oftmals, besonders wenn längere Zeit kein einziges Byte übertragen wurde, kann es helfen, den Client abzuschalten und erneut zu starten. Meist findet dann das Completing innerhalb weniger Minuten statt.
d) "corrupt" bedeutet nicht, dass das Datenpaket real beschädigt ist, sondern nur, dass es vom Client als beschädigt eingestuft wird. Gerade bei Filmen reicht es oft schon, dass entsprechende Part File (dessen Identifikation bei eMule zugegebenermaßen schwierig ist) in einen anderen Ordner zu kopieren und es auf den korrekten Dateinamen umzubenennen.
e) Last but not Least hat eMule in seinem frühen Entwicklungsstadium aber auch noch Probleme in Punkto Stabilität, die des Öfteren während des Completing beobachtet wurden (Programm bleibt dann einfach stehen). Auch hier hilft in der Regel, eMule zu beenden und neu zu starten.
Meine Downloadmenge ist höher als die Dateigröße. Wieso?
Während des Downloads eines Files wird jedes Datenpaket geprüft und bei einem möglichen Fehler als "corrupt" gemeldet. (siehe auch: Fehler- und Warnmeldungen) In diesem Fall, wird dieses corrupte Datenpaket zwar zur Downloadmenge addiert, aber es wird trotzdem erneut angefordert. Dadurch steigt die Downloadmenge über die eigentliche Dateigröße hinaus an.
Das kann im Extremfall auch sehr massiv sein. Es ist durchaus schon beobachtet worden, dass für ein 700 MB File 1,4 GB als Downloadmenge erforderlich waren.
Trotzdem besteht kein Anlass zur Sorge: Wenn eMule das File als "fertig" darstellt, wird alles i.O. sein.
Mein Download ist zu früh "complete", als Downloadmenge ist niedriger als die Dateigröße?
Bei Transfers von eMule Client zu eMule Client wird versucht, die Datenpakete zu packen. Das kann bis zu 10% der benötigten Downloadmenge ausmachen. Das ist also kein Problem, sondern eher ein angenehmer Effekt: Das File ist einfach früher fertig.
Mein File wird mit "complete" angezeigt, aber ich finde es nicht im Incoming Ordner. Wo ist nun mein File?
Das ist ein Problem, welches sowohl beim Esel, als auch bei eMule immer mal wieder auftritt. In der Regel ist dann irgendwas beim completen schiefgegangen. Also an dem Punkt, wo das part File aus dem Temp Ordner in das endgültige File im Incoming Ordner transferiert wird.
Man sollte zunächst in den Temp Ordner schauen und dort versuchen - z.B. anhand der Dateigröße - das zuständige part File zu identifizieren. Dann dieses File in einen anderen Ordner kopieren (und nicht verschieben, damit im Misserfolgsfall noch was vorhanden ist!). Anschließend das File umbenennen in das, wie es eigentlich heißen soll und anschauen. Mit hoher Wahrscheinlichkeit ist das so erzeugte File völlig in Ordnung.
Welchen Speicherplatz benötige ich? Wieso ist angeblich kein Platz auf meiner Festplatte?
Um das zu verstehen, müssen einige technische Hintergründe verdeutlicht werden: In dem Moment, wo ein File zum Download ausgewählt wird, berechnet eMule (übrigens genauso wie eDonkey) den notwendigen Speicherplatz. Dabei wird der benötigte Platz als DOPPELT so hoch kalkuliert, wie eigentlich vom File benötigt. Denn zunächst wird ein Part File in der fertigen Größe im Temp Ordner angelegt. Wenn aber später das File completed wird, also im Incoming Ordner erstellt wird, wird aus Sicherheitsgründen ERST das fertige File erzeugt, bevor ANSCHLIESSEND das Partfile gelöscht wird. Während dieser kurzen Zeit des Completing existiert das File also doppelt. Falls die Ordner "Temp" und "Incoming" in verschiedenen Partitionen liegen, muss also in BEIDEN Partitionen noch genügend Platz für das zu ladende File sein.
Ich erhalte einen Warnton (Beep) während des Completing?
eMule prüft zwar zu Beginn eines Downloads den benötigten Platz und auch bei jedem Neustart. Nicht aber während des laufenden Betriebs. Wenn also nach Start des Downloads durch Umkopieren oder Installation von Programmen der ursprünglich als ausreichend errechnete Speicherplatz nicht mehr genügt, so kann das File nicht completen. Dies wird durch einen Warnton signalisiert.
Nach Schaffung von ausreichend Platz muss dann in den meisten Fällen das File "von Hand" erzeugt werden. Also Identifikation der Part Datei, Umkopieren und Umbenennen in den korrekten Dateinamen.
Der Warnton bei Fehler kann übrigens unter "Einstellungen" auch abgeschaltet werden. Das ist aber nicht so empfehlenswert.
Blacklisted? Was ist das?
Hierzu ein Text, entnommen aus http://www.der-stille-bob.de/content.php?kat=blacklist :
quote:
Ein paar Infos zu den Blacklistproblemen seit dem Wechsel auf Serverversion p75:
Hintergrundinfos:
Mit der Serverversion p58 hat Lugdunum Master das slimit-Modul eingeführt, das dafür sorgt, dass Clients anhand ihres Verhaltens gemessen werden und bei übermäßiger Belastung dazu führt, dass der Server den Client auf eine schwarze Liste setzt und dieser nicht mehr bedient wird.
Dies ist eine nötige Schutzfunktion um für alle User einen stabilen Service anbieten zu können
Dazu bekommt jeder Client ein Guthaben von 1200 Credits, und für jede Aktion wird ein bestimmter Betrag (abhängig von den "Kosten" der Aktion) von diesem Konto abgezogen. Sinkt das Konto auf 0 Credits, wird der Client nicht mehr bedient.
Da bis zur Version p74 der Client einfach keine Antworten mehr auf seine Quell-Anfragen bekommen hat, sobald er auf der schwarzen Liste stand, haben viele dies gar nicht bemerkt. Zusätzlich wurden die Auswirkungen durch das Source-Exchange Feature der Emule Clients abgeschwächt.
Seit der Serverversion p75 hat sich das Verhalten des Servers dahingehend verändert, daß Clients, sobald sie in der schwarzen Liste gelandet sind, vom Server geworfen werden.
Um sich ein bessere Bild machen zu können, hier eine Liste der Aktionen und ihre Credit-Kosten:
* pro Datenpaket (Frame): 1 Credit
* pro Quell-Anfrage: 16 Credits
* pro Login-Versuch: 100 Credits
* pro abgebrochendem Loginversuch: 900 Credits (Emule Clients mit deaktiviertem "Langsames/Sicheres Verbinden")
Ein Loginversuch der abgewiesen wird, weil der Server voll ist, kostet keine Credits.
Pro Sekunde wird 1 Credit gutgeschrieben (bis zu einem Maximum von 1200 Credits)
Das Ganze gilt sowohl für den Server mit dem man verbunden ist, als auch für jeden Server in der Serverliste, da der Client jeden Server, den er kennt, regelmäßig per UDP nach Quellen fragt.
Das eigentliche Problem:
Die aktuellen Clients verhalten sich leider nicht besonders netzschonend, denn sie fragen jedesmal, wenn sie einen Server fragen, nach Quellen für alle Dateien. D.h. ein Client mit 50 aktiven Dateien bombadiert jeden Server regelmäßig mit 50 Anfragen auf einmal.
Die Entwickler der Clients sollten sich ihrer Verantwortung dem Netz gegenüber bewußt sein und ihre Clients so bauen, dass ein normaler User, ohne dass er die Konfiguration extrem verändert oder Cracks benutzt, das Netz nicht belastet. Man kann von den Meisten Usern nicht erwarten, daß sie sich so tief in die Funktionsweise des Netzes einarbeiten, daß sie eigenständig erkennen, wie sie sich verhalten müssen. Diese Aufgabe müssen die Clients übernehmen.
Solange die Clients also dort kein anderes Verhalten an den Tag legen, bleibt für den User nur die Möglichkeit die Anzahl der aktiven Dateien zu reduzieren, um eine Belastung des Netzes zu vermeiden und von den Servern bedient zu werden. Da der Creditverbrauch von vielen Faktoren abhängt, kann ich als Faustregel nur sagen: Nicht mehr als 30 Files gleichzeitig!
Meinen Informationen zufolge arbeiten die Emule-Entwickler an einer Lösung. Diese ist aber noch nicht in der aktuellen v0.29c implementiert. Bleibt also nur auf eine bessere Emuleversion, vielleicht die v0.30 zu warten.
Auf Server auszuweichen, die ältere Serverversionen nutzen, ist nicht wirklich eine Lösung, denn
1. bekommt ihr auch von diesen Servern keine Quellen mehr, sobald ihr in der schwarzen Liste steht und
2. bekommt ihr von keinem lugdunum Server mit einer Serversersion über p57 Quellen mitgeteilt sobald ihr mittels der UDP-Quellensuche auf die schwarze Liste geraten seid
Im Klartext:
Wenn euer Client mit seinem Verhalten von einem Server mit Serverversion p75 geworfen wird, ist es fast garantiert, dass ihr nach kurzer Zeit bei fast allen Servern auf der schwarzen Liste steht und damit von diesen Servern keine Quellen mehr übermittelt bekommt. D.h. ihr habt dann nur noch die Chance über den Source-Exchange des Emule an Quellen zu kommen.
Das Problem besteht schon seit Monaten, ihr seht es nur jetzt erst!
Weiter zu Sonstige Probleme und Fehler Teil 2
|
