[Thaddäus Tentakel]

Hallo miteinander,

ich bin seit ca. 4 Wochen stolzer Besitzer eines neuen PCs, den ich mir aus Einzelteilen zusammengestellt habe. Bislang lief auch alles sehr gut, allerdings habe ich jetzt ein Problem festgestellt, das von Beginn an existierte, mir aber erst jetzt aufgefallen ist. Nur fehlen mir inzwischen die Ideen, wie ich das Ganze lösen könnte:

Es geht um Kopiervorgänge auf USB-Datenträger. Aus irgendeinem Grund zerschießen sich die Dateien in den meisten Fällen von selbst, obwohl während des Kopiervorgangs keinerlei Auffälligkeiten da sind. Konkret habe ich versucht, TV-Aufnahmen im TS-Format auf eine Western Digital 3 TB My Book-Platte zu schieben. Auf dem PC waren die Dateien noch völlig in Ordnung, auf der Festplatte pixelt das Bild alle paar Sekunden auf. Auch die MD5-Checksumme ist eine andere als bei der Originaldatei.

Mein erster Verdacht: Die externe Festplatte ist kaputt. Das konnte ich allerdings schnell wieder ausschließen, denn am Notebook funktioniert die Platte einwandfrei während an dem neuen PC nach einigen Tests auch andere Datenträger (eine weitere WD-Platte und verschiedene USB-Sticks) die gleichen Probleme aufwiesen. Es ist auch völlig egal, welchen USB-Anschluss ich nehme: Ob die USB 3.0-Anschlüsse an der Gehäuse-Front, die USB 3.0-Anschlüsse hinten oder der 3.1, bzw. einer der 2.0-Anschlüsse auf der Rückseite des Boards, es ist überall das gleiche Ergebnis.

Hin und wieder wird dann durch Zufall mal eine Datei korrekt kopiert, das ist aber ein reines Glücksspiel. Ich kannn jetzt einen Kopiervorgang mit 10 Dateien starten, mit ganz viel Glück sind dann am Ende 1-2 große Dateien korrekt kopiert worden, wenns blöd läuft sind alle fehlerhaft. Es ist bislang kein System für mich erkennbar, es spielt keine Rolle, ob ich den PC während dem Kopiervorgang nun noch zusätzlich stark beanspruche oder ob ich ihn komplett in Ruhe lasse.

Und um dem Ganzen jetzt noch die Krone aufzusetzen: Lesen funktioniert einwandfrei, auch bleiben die USB-Geräte stabil verbunden, nur das Schreiben funktioniert nicht wie ich es will.

Natürlich habe ich auch schon versucht, Treiber neu zu installieren. Als das nichts gebracht hat habe ich gestern sogar Windows neu aufgesetzt, aber auch das half nicht. Genommen habe ich die Treiber von der Asus-Homepage - erst die beiden oberen Chipset-Treiber, danach den LAN-Treiber, dann die USB-Treiber (den Beta-Treiber habe ich auch schon getestet) und den SATA-Treiber und zum Schluss noch von NVIDIA den Treiber für die Grafikkarte. Ich habe auch zwischen der Installation der einzelnen Treiber getestet, aber auch hier war das Problem immer da. Auch hatte ich die LAN-Verbindung nach der Neuinstallation von Windows gekappt, damit Windows sich nicht selbst noch Treiber aus dem Netz laden konnte.

Hier meine verbaute Hardware:

Mainboard: Asus Z170 Pro Gaming
CPU: Intel Core i7 6700K
RAM: Corsair Vengeance LPX DDR4-2133, 16 GB (2x 8 GB)
Grafikkarte: MSI GeForce GTX970
System-SSD: Crucial MX200 (250 GB)
Daten-HDD: Western Digital Blue WD30EZRZ (3 TB)
Netzteil: be quiet! Pure Power L8 (530 Watt)
Gehäuse: Corsair Carbide Series 200R
Betriebssystem: Windows 10 Pro (64 Bit)

Ich hoffe, irgendwer von euch hat eine Lösung - ich bin mit meinen Ideen nämlich so langsam aber sicher am Ende.

Vielen Dank schon vorab!

Nachtrag: Mein letzter Versuch war jetzt, das Ganze mal unter einem von DVD gestarteten Ubuntu zu testen. Dort tritt der Fehler auch auf, aber deutlich seltener als unter Windows. Ich habe es mit 15 verschiedenen Serienfolgen zwischen 1,3 und 4 GB probiert. Von diesen 15 Dateien weisen jetzt noch 2 eine unterschiedliche MD5 auf. Alle anderen wurden jetzt sauber rüberkopiert.

Nachtrag 2: Die zwei besagten Dateien werden zwar mit unterschiedlichen MD5-Summen angezeigt, wie es aussieht wurden sie aber trotzdem fehlerfrei kopiert. TS Doctor findet auch in diesen beiden Dateien keine Fehler und beim stichprobenartigen Reinschauen sind mir auch keine Pixel-Aussetzer aufgefallen.

Dieser Beitrag wurde von Thaddäus Tentakel bearbeitet: 13. April 2016 - 20:31

[Samstag]

Lass mal bitte memtest durchlaufen. Könnte sein dass dein Ram die Fehler wirft.
Willkommen bei uns im Forum :)

Dieser Beitrag wurde von Samstag bearbeitet: 13. April 2016 - 20:53

[Candlebox]

Passiert das auch, wenn du das .ts intern kopierst?

Wenn bei mir das Md5 nach dem kopieren nicht passen würde, ist irgendwo ein Fehler. Sei es ein knacksen, im ersten Augenblick ein minimaler, nicht sichtbarer Ruckler oder sonstwas.

Ein .ts ist dabei Fehlerunanfälliger als z.B ein h264/h265.


Paßt das MD5 nicht, hast eigentlich in einem h.264 sofort irgendwo grüne Blöcke etc. drin.

Der Doctor zeigt dir im .log auch mögliche errors an, auch wenn die nette Dame sagt, daß der "Stream succesfully completed gecleant" sei

Da es auch unter Linux Auftritt, scheint mir hier eher ein Hardwarefehler/Biosfehler vorherrschend zu sein.

Bei Vista und Win7 hat mir der Defender anfangs versucht, meine gerenderten Video-Dateien beim auslagern kaputtzumachen, unter Win 8.1 und 10 konnte ich dieses aber nicht mehr beobachten.

Wenn das md5 Problem Intern nicht auftritt, mach mal eine .7z Datei (nur Speichern) intern aus dem .ts, verschieb diese dann auf das USB LW und versuch mal dieses wieder zu entpacken.

Da es ein Asusboard ist, tippe ich auf Bios/RAM und würde mal Speichertechnisch mit Minimalkonfiguration anfangen, den Fehler zu suchen.

Edit: Ja. Memtest, natürlich. Danke Samstag. Ich Depp, Erstmal viel einfacher.

Dieser Beitrag wurde von Candlebox bearbeitet: 13. April 2016 - 21:07

[Thaddäus Tentakel]

Danke für eure Antworten!

Intern kopieren von der Daten-HDD auf die SSD und wieder zurück klappt einwandfrei, problematisch wird es erst wenn das Ganze über einen USB-Anschluss auf eine externe Platte soll.

Die Log-Datei vom TS-Doctor hab ich mir bei den beiden Dateien mit unterschiedlicher MD5 auch angeschaut, da wird aber auch nichts außergewöhnliches angezeigt, lediglich die DD2.0-5.1-Wechsel am Anfang und Ende der Episoden, aber die sind ja auch schon im Original drin.

Das mit dem Memtest werd ich dann wahrscheinlich morgen abend mal austesten. Mal schauen was da rauskommt.

Beim BIOS hab ich übrigens gestern ein Online-Update laufen lassen, das hatte auf den Fehler aber auch keinerlei Auswirkungen.

[Thaddäus Tentakel]

So - ich habe gerade mal einen Memtest durchlaufen lassen und bin mir jetzt selbst nicht sicher, ob ich das Ergebnis gut oder schlecht finden soll. Es wurden jedenfalls keine Fehler gefunden, was ja einerseits gut ist, nur die Lösung des Problems wohl nicht gerade einfacher macht...

[Candlebox]

Hmm, ich würde trotzdem mal jeweils einen Ramriegel rausnehmen, und diese einzeln in unterschiedlichen Bänken testen, und das mit Linux oder alternativ mit einem nackten Windows ohne Treiber und Zusatzsoftware von irgendwelchen Herstellerseiten, sondern nur das verwenden, was sich Win10 erstmal selber holt.

Gehts nicht, würde ich das unter einem nackten Win7/8.1 nochmals wiederholen.

Meinen Win10 Test-Kisten traue ich auch keinen Meter und prüfe alle erstellten/aufgenommenen Videos derer gegen. Ist aber mittlerweile alles sauber, mit Treibern, die Windows sich selbst holt, oder geholt hat.

Dann würde ich dem Defender unter Windows sagen, daß er die entsprechenden Pfade und Dateitypen ignorieren soll, der hat mir früher eben schon so manches h.264 zerbröselt. Bei mir sind gewisse Pfade zur Prüfung von vornherein ausgeschlossen.

Dann würde ich die Kopierorgien nochmals unter den Unterschiedlichsten Szenarien durchführen und bei der Kontrolle ausschliesslich beim MD5 bleiben, und mich nicht auf den TSDoctor verlassen. Ich arbeite selbst damit, das ist auch nur ein Stück Weichware mit Bugs.

Abschliessend, wenn alles nix fruchtet, ich hatte das nämlich genauso auch mal mit Video-Dateien, was mich schier zum Wahnsinn getrieben hat, würde ich das ganze Innenleben rausreissen und ersetzen, was ich damals tat. Da ich nicht zocke, und Asusboards konsequent meide, fiel die Wahl relativ leicht und hab seitdem Ruhe.

Vielleicht, so könnte ich mir Vorstellen, ist auch das NT der Schuldige, wenn es der Arbeitsspeicher nicht ist. Aber es ist und bleibt ein Asusboard, mit denen ich persönlich in Summe, die allerschlechtesten Erfahrungen gemacht habe.

Das ist meine persönliche Meinung und muß nicht die Meinung der Masse widerspiegeln.

Dieser Beitrag wurde von Candlebox bearbeitet: 14. April 2016 - 21:11

[Thaddäus Tentakel]

Ich scheine der Sache so langsam aber sicher auf den Grund zu kommen - der Tipp mit dem Ramriegel rausnehmen hat jedenfalls gefruchtet. Testweise habe ich einen der beiden rausgenommen und eben wieder 8 Dateien mit insgesamt über 25 GB auf eine USB-Platte gezogen und siehe da: Allesamt haben sowohl auf der internen HDD als auch auf der Platte die gleiche MD5!

Das werde ich jetzt noch etwas ausgiebiger testen (Riegel untereinander tauschen, weitere Dateien kopieren...), aber möglicherweise hatte der momentan entfernte Riegel ja doch irgendeinen Schaden, den Memtest nicht gefunden hat. Mal schauen, was die weiteren Tests ergeben...

EDIT: Sieht nach Volltreffer aus - ich habe noch 11 weitere Dateien mit einem Gesamtvolumen von ca. 14 GB kopiert, ebenfalls alle fehlerfrei. Danach mal den RAM-Riegel gewechselt (in die gleiche Bank wo vorher auch der drin war, mit dem es funktioniert hat) und die gleichen 19 Dateien nochmals kopiert. Ergebnis: Ausnahmslos alle Dateien kaputt mit anderer MD5. Zu allem Überfluss gab es mit diesem Riegel auch 2x Bluescreens, einmal "Page fault in nonpaged area" und einmal "IRQL_not_less_or_equal". Es schreit also förmlich danach, als sei dieser Riegel die Ursache allen Übels. Ich tausche das Ganze jetzt nochmal aus, wenn es dann wieder funktioniert dürfte das ja endgültig Gewissheit bringen.

Dieser Beitrag wurde von Thaddäus Tentakel bearbeitet: 15. April 2016 - 17:25

[Sturmovik]

Interessant, dass Memtest hier nicht angeschlagen hat, wenn doch offensichtlich ein Speicherriegel fritte ist.

Um meine Neugier zu befriedigen:
Wie hast du Memtest gestartet?

[Candlebox]

Zitat (Sturmovik: 15. April 2016 - 17:29)

Interessant, dass Memtest hier nicht angeschlagen hat, wenn doch offensichtlich ein Speicherriegel fritte ist.

Memtest hat bei mir noch nie versagt. Ich denke auch, daß die Speicher beide ok sind. Nur glaube ich, macht Windows oder irgendein Treiber diese Fehler, Software halt.

Denn das machte mich stutzig. Der Unterschied unter Linux könnte nämich Zufall oder irgendwas anderes gewesen sein. Denn die Tendenz unter Linux war für mich entscheidend.:

Zitat (Thaddäus Tentakel: 13. April 2016 - 18:46)

Nachtrag: Mein letzter Versuch war jetzt, das Ganze mal unter einem von DVD gestarteten Ubuntu zu testen. Dort tritt der Fehler auch auf, aber deutlich seltener als unter Windows. Ich habe es mit 15 verschiedenen Serienfolgen zwischen 1,3 und 4 GB probiert. Von diesen 15 Dateien weisen jetzt noch 2 eine unterschiedliche MD5 auf. Alle anderen wurden jetzt sauber rüberkopiert.

Nachtrag 2: Die zwei besagten Dateien werden zwar mit unterschiedlichen MD5-Summen angezeigt, wie es aussieht wurden sie aber trotzdem fehlerfrei kopiert. TS Doctor findet auch in diesen beiden Dateien keine Fehler und beim stichprobenartigen Reinschauen sind mir auch keine Pixel-Aussetzer aufgefallen.

Ich würde es eben mal ohne den ganzen installierten Win10-Treiberkram gegenprüfen. Am besten noch mit einem 8.1 oder 7 (schrieb ich ja bereits) Mag ja sein, daß das wie die Aussage eines Idioten klingt, es sind eben meine Erfahrungen mit schnell gestrickten Softwareupdates. Seit ich das anders handhabe, kann ich mich auf meine Sklaven verlassen, denn ich muß mich auf die verlassen können, daß die zuverlässig .ts produzieren.

Dieser Beitrag wurde von Candlebox bearbeitet: 15. April 2016 - 17:44

[Thaddäus Tentakel]

Memtest habe ich über die Windows-Speicherdiagnose gestartet.

Das mit dem Treiberkram hab ich schon mehr oder weniger ausprobiert, als ich Windows aus Verzweiflung diese Woche neu installiert habe. Immer schrittweise weitere Treiber installiert und zwischendurch Dateien kopiert, um zu sehen was passiert. Auch vor der Installation von irgendwelchen Treibern habe ich das Ganze ausprobiert und auch da ging es schief.

Es sieht aber ganz nach Jackpot bei dem RAM-Riegel aus. Nachdem ich jetzt wieder den anderen eingesetzt und wieder die besagten 19 Dateien kopiert habe wurden wieder alle fehlerfrei mit identischer MD5 zum Original rübergezogen.

Die Tendenz unter Linux ist in der Tat interessant, aber ohne dass ich jetzt der große Experte in dem Thema bin schreit für mich alles nach Defekt an dem einen RAM-Riegel.

[Sturmovik]

Ok, dann is alles klar. Die Windows-Speicherdiagnose is fürn Eimer

Das ist das wahre Memtest
http://www.memtest.org/

[Thaddäus Tentakel]

Zitat (Sturmovik: 15. April 2016 - 18:07)

Ok, dann is alles klar. Die Windows-Speicherdiagnose is fürn Eimer

Das ist das wahre Memtest
http://www.memtest.org/

Das erklärt dann einiges - ich habe nur nach Memtest gegooglet und kam direkt zur Windows-Speicherdiagnose.
Werde dann jetzt mal wieder beide Riegel einsetzen und den von dir verlinkten Test laufen lassen. Sobald ich das Ergebnis habe melde ich mich wieder.

EDIT: Noch eine kurze Frage: Nehme ich besser den verlinkten Memtest86+ oder den hier: http://www.memtest86.com/
Der 86+ ist ja schon ein paar Jahre alt während der andere in der aktuellen Version erst im Januar 2016 veröffentlicht wurde.

Dieser Beitrag wurde von Thaddäus Tentakel bearbeitet: 15. April 2016 - 18:17

[Sturmovik]

Sollte egal sein, die beiden stammen ursprünglich vom selben Autor, bis der das Team verlassen hat. Dann hat Passmark das Ding als kommerzielle Variante weiterentwickelt, die Free Edition ist naturgemäß kastriert, wie das bei proprietärer kommerzieller Software meist ist.

memtest86+ ist die freie Weiterentwicklung, wird halt nicht so oft aktualisiert.

EDIT: wenn ich mir das genauer ansehe, scheint das Projekt stillzustehen, einige Bugreports sind seit Jahren unbeantwortet => greif zu Passmarks memtest86 free
/EDIT

Während meiner Windows-Zeit hab ich immer die freie Variante genutzt, heute vertraue ich meist auf die im Linuxkernel eingebackene Variante oder die mentest86+-Weiterentwicklung, die auf der sysresccd drauf ist, die ich immer am Schlüsselbund hängen hab)

---

Es kann natürlich immer noch sein, dass irgendein Treiberproblem unter Windows vorliegt, gerade hinsichtlich der fehlerfreien Kopierei unter Linux.

Da Linuxe bei großen Kopiervorgängen normalerweise den gesamten verfügbaren Speicher zum cachen nutzen, müsste hier auch einer der vermeintlich kaputten Speicherbereiche genutzt worden sein. Andererseits ist die Fehlerkorrektur von ntfs-3g recht ausgereift, sodass Kopierfehler hier bemerkt und still und heimlich gefixt werden.

Dieser Beitrag wurde von Sturmovik bearbeitet: 15. April 2016 - 18:47

[Thaddäus Tentakel]

Memtest findet kurioserweise keine Probleme, ich hab es jetzt über 3 Stunden laufen lassen. Ein Durchgang lief komplett durch, der zweite war jetzt beim Hammer-Test, also auch kurz vor Ende.
Nach der Tauschaktion bin ich mir aber ziemlich sicher, dass der eine Riegel einen Knacks hat. Das Problem war ja beim Test weg, wenn der Riegel weg war und da ich es ja auch an ein und der selben Bank getestet habe spricht das ja auch dafür, dass der Riegel kaputt ist. Wäre es das Board oder der Treiber dürfte es doch mit dem einen Riegel auch nicht zu 100% sauber laufen während nur der andere 100% Fehlerquote produziert.

[Candlebox]

Zitat (Thaddäus Tentakel: 15. April 2016 - 21:53)

Nach der Tauschaktion bin ich mir aber ziemlich sicher, dass der eine Riegel einen Knacks hat.

Wenn dem so sei, läßt sich das mit einem neuen Riegel einfach verifizieren.