|
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!
|
Menu