Received suspicious block: file... oft bei MVCDs mit eF-Mod
 

Hallo Zusammen,

ich habe folgendes Problem, ich bekomme hauptsaechlich bei MVCD MPeg Dateien (bei denen ist mir das jedenfalls so extrem aufgefallen) folgende Fehlermeldung im log:

und das von verschiedenen usern immer wieder hintereinander! wobei part, block und blocksize immer die gleichen sind!

Was heisst diese Fehlermeldung, dass evnt die Datei ganz kaputt ist, oder dass ich vileleicht irgendwann mal glueck habe und diesen bestimmten block runterladen kann?

Danke fuer eure Hilfe,
das WebEye

Nach meiner bisherigen Erfahrung nach nach, würde ich sagen, die Datei is hinüber, aber da es ein mpg file ist, kannst du , sofern Anfang und Ende der datei hast, das Partfile mal testweise umbennenn in *.mpg.

Dann sollte es geöffnet werden und einzusehn sein.

Alternativ kannst du auch VirtualDub testen, damit öffnen und er zeigt dann die vorhandenen Daten, sofern Audio-/Videodaten da sind, an.

Ich hoffe, das ist soweit verständlich. :-)

Ach ja, ich benutze den Media Player Classic, den man sich bei sourceforge.net saugen kann, genau wie VirtualDub.

Yo, danke erstemal,
aber das bringt mich auch nicht weiter!

Ich kenn mich mit der Handhabung der part files und auch mit den benannten Tools aus! Das hilft mir aber alles nichts, wenn ein bestimmter block innerhalb des partfiles nicht runterkommt! Wie ich die Meldung verstehe, wird versucht ein bestimmter block runterzuladen, wird dann aber wieder fallengelassen, weil die Blockgroesse von der Erwarteten abweicht! Die Frage ist nun, warum ist das so, und gerade nur bei MVCD-codierten MPGs! Ich kann mir ehrlich gesagt nicht vorstellen, dass die files so kaputt sind, dass sie nicht heruntergeladen werden koennen, denn dazu ist mir das zu oft aufgefallen! Interessant waere vielleicht, wie die Blockgroesse entschluesselt wird, hat das file vielleicht fehlerhaftes Hashset! Naja, Fragen ueber Fragen, vielleicht kennt sich ja einer aus!

WebEye

Früher hat in solchen Fällen manchmal das Deaktivieren von I.C.H geholfen..

Nicht nur früher, das ist immer noch so. Vor allem Mvcd's haben eine höhere Komprimierung als Standart Mpeg's und von daher können da auch schon die "Fehlermeldungen" eher auftreten als halt bei Standart Files. Schalt mal I.C.H. (oder was es da sonst noch so bei den verschiedenen Mods gibt) ab und warte ....

Das 'früher' bezog sich darauf, dass ich das nur immer mal gelesen habe, es aber schon länger nicht mehr erwähnt wurde und ich selbst das Problem noch nie hatte und ausserdem inzwischen ausser I.C.H auch noch andere Methoden zum Einsatz kommen, die evtl. auch durch zu- oder abschalten helfen können. Je nach Mod gibt es da wohl Unterschiede..


WebEye hat leider nicht erwähnt, welchen Mod er verwendet - da er in eMule MODs - Allgemein gepostet hat, gehe ich aber mal davon aus, dass er sich was dabei gedacht hat und uns vielleicht auch noch den Mod nennt, den er verwendet und bei dem diese Probleme auftreten.

Hi!

Yo, sorry, hierfuer, hab ich im Nachhinein auch dran gedacht!
Ich benutze den eMule 41b.29 eF-Mod 0.9a1 und hab jetzt erstmal das I.C.H. System abgeschaltet, und probier das so mal ne weile, ansonsten haett ich noch 'defeat 0-parts' anzubieten, hat das evnt. auch was damit zu tun!

btw: ich hab das Ganze hier her gepostet, weil ich denke, dass es nicht mod abhaengig ist!

DAnke fuer die Hile,
WebEye

Also erstes Resume: I.C.H. scheint es nicht gewesen zu sein, ich habe exakt die gleiche Fehlermeldung gerde zum erstenmal wieder erhalten!

so long,
WebEye

wenn es sich um "Received suspicious block: file ..." meldung handelt,
dann hast du "Defeat 0-Part Filler Senders" nicht abgeschaltet. man


das habe ich im Sivka-Mod gelesen
also schalte es doch einfach mal ab

yo, habe es heute morgen abgewscxhaltet, und seitdem kam die Meldung auch nicht mehr, mal abwarten ;))

Danke,
WebEye

Doch, doch - es ist offensichtlich Mod-abhängig, weil es nämlich in der originalen eMule Version diese Option nicht gibt - somit auch nicht in jedem Mod - wie daenemark erwähnte, ist dieses "Defeat 0-Part Filler Senders" wohl ein sivka-feature und der eF Mod hat wohl sivka in sich.. ;)


Jedenfalls hast du damit dein Problem offensichtlich lösen können :)
Werde nun noch die thread Überschrift anpassen, damit andere den thread mit Hilfe der Board Suche leichter finden können. 8)

Hier wird oft über das Deaktivieren von "Defeat 0-Part Filler Senders" geredet, dabei hab ich dieses Feature bei meinen bisherigen Sivka-Versionen standradmäßig noch NICHT aktiviert gesehen... Demnach müßten es die entsprechenden User einfach eigeschaltet haben - warum, wenn vorher alles lief?
Was hat´s eig. für Folgen, wenn ich I.C.H. dauerhaft ausschalte? Meine Files werden mom. nicht beender. Besser gesagt, sie gehen auf 100%, Balken wird grün (wird beendet), stehen aber dann wieder in der DL-Liste mit zb 95-100% (beschädigte Teile)...
Da sich die Meldungen immer mehr häufen, und dieses Problem urplötzlich auftrat, kann es doch nicht am einzelnen User liegen. Ist evtl .das emule-Netz mit defekten bzw. hochkomprimierten Teilen verseucht??? I.C.H. filtert diese Teile aus, oder? Wenn ich es abschalte nicht mehr. Wie wirkt sich das auf mein File aus, wenn ich ein ungefiltertes Teil DL. Bei "Urlaubsfilmen" isses ja eig. fast egal - wie siehts bei Programmen aus???

Snoopy

Sowohl I.C.H. als auch "Defeat 0-filled Part Senders" sind Features die im Normalfall sehr gut funktionieren um korrupte Daten (von "verseuchtem eMule Netz" möchte ich nicht sprechen, es gibt immerhin auch noch Übertragungsfehler und eine Menge User ohne deine Probleme) abzuwehren bzw. wiederherzustellen. Die Empfehlung sie auszuschalten gilt nur bei den angesprochenen Fehlermeldungen, wenn z.B., wie bei dir, angeblich defekte Blöcke das Beenden von Downloads stören. Es könnte sein, dass ein Block fälschlicherweise als defekt erkannt wird und deshalb wiederholt als fehlerhaft aussortiert wird. Schaltest du I.C.H. aus, so wird der Block immer noch auf Fehler geprüft, an Hand seiner Prüfsumme, nur wird er nicht mehr von I.C.H gecheckt. Die Erfahrung zeigt, dass dann oft ein solches File fehlerfrei beendet werden kann, danach sollte man I.C.H. wieder einschalten.
Hast du's denn mal probiert?