das die datei sofort den gesamten platz einnimmt is nicht korrekt. es kommt drauf an, mit welchem teil der datei anfängt er zu laden. lädt er die datei von vorne nach hinten, so is die datei immer so groß, wie übertragen/fertiggestelt worden ist. fängt er jetzt bei der hälfte an, is die datei erstmal nur halb so groß. fängt er allerdings ganz hinten mit dem letzten chunk an, hat die part datei sofort die volle größe.

Hallo NaP,

da könnte man doch trotzdem ansetzen.

Die Parts werden doch mit Position usw übermittelt. Man könnte die Parts einfach in einer Datei in Reihe speichern und am Start ist Partname, Länge, und Position im gesamten File abgelegt. Oder für jede Part eine kleine Datei anlegen, was aber wohl viel wäre. Das ganze wäre denke ich auch fürs hashen kein Problem weil es gibt in C sicherlich auch Funktionen mit denen man einen String aus Nullen zurückerhält und man könnte leicht die parts einbauen um sie zu hashen.

Oder ?

Grüße,
Sebastian

tja ja könnte man, wie im Donkey Hibrid!
aber ich find es so besser, denn wie will man dann noch sinvoll eine Dateivorschau machen (OK mit viel mühe gehts, aber halt nicht für normal sterbliche)

Ich persönlich habe nur im download was auf die "PLATTEN" passt.
Die Fertigen Dateien kann mann ja auch auf eine andere ge-share-te platte legen.

NaP, also bei mir haben die .part-files von beginn an immer die größe, die sie haben sollen wenn sie fertig sind, egal womit der esel anfängt zu laden.
ist ja auch am sinnvollsten so, sonst kanns nämlich passieren, das man lauter angefangene dl´s hat und die platte plötzlich voll ist und damit kein dl beendet werden kann.

darum haben ja einige mods das feature, dass sie dl´s stoppen, wenn die platte zu voll wird.

Die .part files haben dann die endgültige Größe, wenn die first and last chunks des files vorhanden sind - hat man diese Option nicht aktiviert, dann wird das .part file je nachdem, welcher chunk in der Mitte z.B. geladen wird auch erst nur so groß, wie es von chunk 1 bis zum aktuell geladenen chunk ist.
Ein Problem mit den DLs, die auf Pause stehen, aber noch weiterlaufen scheint daher zu rühren, daß der "gegnerische" client nicht versteht, daß unser mule sagt: stop, nicht mehr weiter übertragen.. mir fällt v.a. auf, daß das meist eDonkeys sind, die trotzdem weiter übertragen - wenn es dann ganz dumm und die Platte voll läuft, dann u.U. Absturz.. :(

hi,
habt ihr, dass auch fest gestellt, so nach 3-4 tagen, ist der speicher verbrauch ganz schön angstiegen! (von 10mb auf 70mb)
ansonsten, top!!!
cyrex2001

@cosmic girl,

entgegen deiner these haben files die weder den ersten noch den letzten chunk geladen haben schon ihre volle größe.files,die noch nicht geladen haben stehen auf null,aber wenn der erste chunk geladen ist werden sie in voller größe angezeigt.also muß,folgendermassen,muli schon vorher oder beim laden des ersten chunks die volle größe des files wissen.was ja auch sinn macht.
kannste gerne ausprobieren.

Also, ich konnte es im Moment anhand von vier files überprüfen:
Die drei .avi files sind als .part files noch um einiges kleiner als die fertiggestellte Größe sein wird.
Das eine .mpeg hingegen hat als .part file schon die volle Größe, obwohl nur ein paar chunks aus der Mitte geladen sind.

Was lernen wir daraus? Der eMule macht was er will? :mrgreen:

Wenn man z.B. für ein file die preview mal genutzt hat, dann ist das klar, daß er die gesamte Länge braucht..
Im Falle meines .mpegs habe ich weder den ersten noch den letzten chunk bisher geladen, aber hatte gestern den preview mode angewählt (also nur für dieses eine file). Ob daher nun die volle .part-file Größe resultiert?

Wer kann noch seine Beobachtungen kundtun?

@cosmic girl,

das file muß eigentlich von vorneherein als bestimmte größe feststehen,wie sollte das grautier sonst wissen welchen chunk es wohin setzen sollte??

Die Tatsachen beweisen ja wohl, daß es auch so weiss, wohin.
Ich habe immer wieder files, die erst im Laufe des DLs ihre vollständige Größe annehmen - das Muli weiss schon was es tut.
Interessant finde ich, was sich da nun mit dem neuen Hybriden tut... hatte doch gestern einer geklagt, daß der irgendwas mit seinen .part files angestellt hätte (mehrfach unterteilt oder so).. wenn ich es wieder finde, poste ich den link - oder vielleicht hat diesen post auch jemand anderes zufällig parat?

@cosmic girl,
das wäre sehr interessant zu wissen.
edith/ oder kommt es doch auf das sys an,habe xp/marga

Also das der neue Hybrid die Datei in die Einzelnen chunks aufteilt, hab ich selbst erlebt.
Bin mal ins Temp verzeichniss gegangen und siehe da, ein megalanges listing an stücken.
Beim beenden des downloads, hat er sie dann zusammengesetzt.

So, ist eine Preview funktion nur möglich wenn diese sich die parts zusammensetzt zu einer datei, die man dann sehen kann. Also nicht so simpel wie bisher.

CYA
MasterKGB

Hallo allerseits!

Ich habe den Emule 27c Morph V3b jetzt schon über 24 Stunden laufen und bisher alles bestens, läuft also in jeder Beziehung (Stabilität, Quellen, Download) schön rund. :) Zuvor hatte ich den Emule 0.27c Sivka 7b2;Lamerz Choice (L) Mk.4 Beta 14 laufen - der hat mir auch schon gut gefallen, aber der Morph gefällt mir besser, da er imho etwas stabiler läuft, eine ausführlichere Statistik mitbringt, das Release-Fenster nicht hat, das ich nicht brauche, und mir jetzt auch optisch besser gefällt (homogenes Design der Icons) etc. Also ein wirklich klasse Mod, danke! :)

Der Morph läuft bei mir auf einem P3-850 (~5% CPU-Auslastung) mit 768 MB RAM unter Windows XP SP1. Max Verbindungen 400, pro 5 Sek max. 50 neue Verbindungen.

In der Warteschlange fällt mir nun öfters das Community Tag "- [MoRpH.Mod.Fun]" auf. Hat das irgendwas mit dem Morph im allgemeinen zu tun? Hat jemand eine Idee, woher dieser Tag kommt?


tazoo

Jo kann ich auch nur bestätigen! Ein sehr guter Mod. Nicht nur von der Stabilität her sondern vor allem von der Geschwindigkeit. Ich war lange nicht mehr bis vor 2 Tagen bei 80kb/sek down gewesen... :roll: :roll: