Beschädigte Datei retten ?

[OldGrumpy]

Der große Knackpunkt bei der Sache hier ist der unscheinbare Hinweis auf die externe Festplatte. Viele USB-IDE/SATA-Bridges kommen mit defekten Sektoren überhaupt nicht zurecht und spielen dann toter Mann - der Datentransfer bleibt hängen und manchmal hilft sogar nur noch, den USB-Stecker zu ziehen.

Daher immer die Festplatte aus dem externen Gehäuse raus und direkt ans Mainboard anhängen - schon geht das Auslesen selbst an den defekten Stellen weiter, wenn auch erst nach einigem Gerödel und ggf. etwas Wartezeit. Übrigens funktioniert dann auch der Code aus (WIMRE) #5.

[p80286]

[OT] Wenigstens einer hier der lesen kann [/OT]

[himitsu]

Zitat von OldGrumpy:

Der große Knackpunkt bei der Sache hier ist der unscheinbare Hinweis auf die externe Festplatte. Viele USB-IDE/SATA-Bridges kommen mit defekten Sektoren überhaupt nicht zurecht und spielen dann toter Mann - der Datentransfer bleibt hängen und manchmal hilft sogar nur noch, den USB-Stecker zu ziehen.

Darum ja auch die Frage nach den Programmverhalten.
Selbst wenn ein Lesevorgang verreckt müssen nicht alle stehenbleiben und wenn letzeres zutrifft, dann gibt es auch Möglichkeiten da etwas zu machen, ohne an der Hardware rumzuspielen.

Aber dafür müßte man erstmal erfahren was passiert.
- Lassen sich hängengebliebene Programme beenden und wenn ja wie?
- Welches Betriebssystem läuft? (mein letzer Code benötigt z.B. mindestens Windows Vista)
- Können andere Programme noch auf den Datenträger oder gar die Datei zugreifen, wärend ein anderes Programm hängt?
- ...

[OldGrumpy]

Das übliche Verhalten (sprich bei allen ca. 10 Bridge-Chips die mir unterkamen bis auf einen kombinierten USB/IEEE1394-Chip von WIMRE Cypress der sich robuster verhielt) ist simpel: Egal ob unter Linux oder Windows (bis 7 gleiches Verhalten) spielen die Chips einfach toter Mann. Zugriffe aufs Device werden nicht mehr beantwortet, Trace durch den I/O-Stack zeigt, dass die Datenpakete sogar bis zum Chip durchgereicht werden, es erfolgt aber nie mehr eine Antwort mit z.B. dem angeforderten Sektor oder einem Fehlercode. Auslöser ist in allen Fällen ein defekter Sektor mit dem die Platte sehr lange beschäftigt ist. Offenbar gibts da ein chipinternes Timeout was dann alles ins Chaos stürzt.

[FredlFesl]

Zitat von Medium:

Zitat von FredlFesl:

Sind die Fragen geklärt oder ich zu paranoid?

Letzteres. Noch nie ein Urlaubsvideo vom Digi-Camcorder am PC geschnitten, was? Allein aus "ich habe ein 4GiB Video" gleich einen Verdacht zu konstruieren finde ich reichlich anmaßend.

"Anmaßend" ist hier anmaßend. Fragen wird man ja wohl noch dürfen und mein Keywort-Verdachts-Generator hat bei "AVI", "Kopieren", "Probleme" nun mal geblinkt. Probleme damit?

Übrigens habe ich keine Urlaubsvideos und ich finde in den Beiträgen hier auch sonst keinen Verweis. Aber möglich ist alles.

[himitsu]

Nja, mal sehn. ob der TE sich nochmal maldet und was er/sie dazu sagt.


Ansonsten: DVD = standardmäßig MPEG2

[ToFaceTeKilla]

Zitat von FredlFesl:

Nur mal so: Wieso bimmeln hier keine Alarmglocken?
Ich meine "große AVI-Datei"? Kopierproblem?

Kann man nicht mal klären, was in der AVI-Datei so drin ist?
Darf der Threadersteller das überhaupt *kopieren*? Gibts da nicht sowas wie Copyright und so?

Sind die Fragen geklärt oder ich zu paranoid?

Siehe Ausgangspost:

Zitat von Cicaro:

/edit/ Es ist eine 4 GB Datei (mit Fraps erstelt) und liegt auf einer externen Festplatte.

(Link von mir eingefügt)
Schonmal damit gearbeitet? Da haste ruckzuck eine Videodatei von beachtlicher Größe erstellt.

[OldGrumpy]

Zitat von FredlFesl:

Nur mal so: Wieso bimmeln hier keine Alarmglocken?

Ich hör da nur das Philisterglöckchen bimmeln

[Cicaro]

Zitat von himitsu:

Tja, dann hast du ein kleines Problemchen ... scheinbar stürtzt de Treiber dort ab, bzw. bleibt hängen, und wenn die Leseoperationen nicht zurückkommen, dann war's das.

Welches Windowsversion nutzt du denn,
wie reagieren die Programme, wenn man sie beenden will? (lassen sie sich "leicht" über [X] oder den Taskmanager beenden)

Wie gesagt, das ist ein sehr ein einfacher Code und ein/zwei Ecken gibt es noch, wo man was drehen kann, aber ob man so am Treiber vorbei kommt...
Darum die Frage nach dem Beendeverhalten des Programms ... also ob es sich lohnt das jetzt noch "schnell" umzuschreiben und es dann nochmal zu versuchen.

Ich sag mal so viel, dass der Kopiervorgang NICHT schnell beendet werden kann. Windows hat ja selber Probleme die Datei zu kopieren und meldet den Fehler erst nach langer Wartezeit. Wenn du den Code ändern willst, schau dass du Fehler schneller ignorierend übergehen kannst. Am besten gleich GetLastError ohne Exceptions usw. Aber da verlässt du dich immer noch auf WinAPI. Also könnte auch das nichts bringen. Leider musst du dir irgendwo anders fehlerhafte Sektoren suchen. Meine Datei ist schon weg und ich weiß, wie ich meinem Problem in Zukunft aus dem Weg gehen kann (zumindest funktioniert es noch).

[hathor]

Mal was Grundsätzliches:

- wenn man Probleme mit Media-Files hat, muss man mit regsvr32 /u shmedia.dll
die Vorschaufunktion ausschalten, denn die blockiert bei einem fehlerhaften AVI-File
den ganzen Computer mit 100%-CPU-Last!
- die AVI-Frames (Index) müssen neu geschrieben/ neu nummeriert werden mit z.B. avifixed
- erst dann sollte man einen Kopierversuch machen