Das rätselhafte Verschwinden von Kris Kremers & Lisanne Froon

staminag schrieb:Ich gebe die Frage direkt an @Doctective weiter. Ist der Fehler im Dateisystem, den 509 verursacht haben soll, ein Zitat aus dem NFI-Bericht?

Welches Zitat genau (Wortlaut). Ich stehe gerade auf dem Schlauch.

Offshore7 schrieb:Hast du Unterlagen von Digicel vorliegen, die zwar keine Funkpeilung bzw. den Ort Pianista Mirador zeigen, wohl aber eine (letzte) IMSI/IMEI-Anmeldung im Netz am 1.4. gegen 12:33 Uhr?

Nein, die letzten 3 eingehenden SMS sind vom 30.3. Danach gibt es keine eingehende oder ausgehende Verbindung mehr.

Doctective schrieb:Welches Zitat genau (Wortlaut). Ich stehe gerade auf dem Schlauch.

Es geht um das hier:

None of the photos previously deleted on the camera, which could be recovered using forensic software, caused such an error in the file system. Only #509 could not be retrieved, not even snippets of it.

Quelle: Koudekaas (Scarlet schreibt, dass sie das von euch hat, nicht direkt dass es aus ViP ist)

Im Prinzip dasselbe findet sich in ViP akt. Auflage S.97/98.
In beiden Fällen ist die o.g. Stelle nicht Teil des wörtlichen Zitats. Die Frage ist, ob das NFI tatsächlich von "Fehler"/"Error" schreibt.

Bei Scarlet ist darunter ein zweiter Teil als wörtliches Zitat markiert (wobei es etwas schwierig ist zu erkennen, was genau dazu gehört). Den finde ich in ViP so nicht (sondern nur kurz zusammengefasst). Der Teil endet mit:

Assuming that "IMG_0509.JPG" was created as a file on the data carrier, it therefore seems plausible to me that the space that the disappeared "IMG_0509.JPG" originally occupied, was overwritten by the subsequent file "IMG_0510.JPG". It also seems plausible to me that "IMG_0509.JPG" was deleted before "IMG_0510.JPG" was created and not later, because the space was reoccupied by the latter.

Da kommt das NFI ja zum richtigen Schluss, soweit ich das inzwischen beurteilen kann. Man hat trotzdem den Eindruck, dass diese Lösung dem NFI nicht so richtig gefällt(?) Die Frage ist, ob das nur an der extrem auffälligen Position liegt, oder man meint es müsse eben irgendeine Art von Fehler dazugekommen sein?

Okay, dann halten wir das wörtliche Zitat aus dem NFI-Bericht einfach mal fest, genauso wie es da steht. Ist in unserem Buch auf Deutsch und Englisch aber auch als solches gekennzeichnet, wie alle Zitate ,-)

Mir ist aufgefallen, dass in der oben genannten Fotoserie eine Datei fehlte: "IMG_0509.JPG". Ich sah, dass dies eine auffällige Tatsache war, denn das vorherige Foto "IMG_0508.JPG" (…) war auf den 1. April 2014 um 13:54 Uhr datiert und das nachfolgende Foto "IMG_0510.JPG" wies das Datum 8. April 2014 und Uhrzeit 01:29 Uhr auf. Außerdem fiel mir auf, dass auf "IMG_0510.JPG" eine Serie von 100 Fotodateien mit dunklen, nächtlichen Aufnahmen folgte, die schwer zu lokalisieren waren. Ich wurde vom Untersuchungsteam gebeten, weiter zu untersuchen, ob sich Spuren dieser fehlenden Datei auf dem Datenträger befinden.
Mit dem Programm Encase durchsuchte ich die Evidence-Files des Datenträgers sehr umfangreich nach Spuren der fehlenden Datei. Dabei ging ich davon aus, dass die Datei wahrscheinlich zu einem unbekannten Zeitpunkt nach dem 1. April 2014 13:54 manuell gelöscht worden war. Im FAT32-Dateisystem des Datenträgers konnte ich jedoch keine Spur dieser fehlenden Datei finden. Daraufhin habe ich mit dem Datenrettungsprogramm Photorec, Version 6.14, der Firma CGSecurity den freien Speicherplatz (nicht zugewiesene Cluster) des Datenträgers nach Resten von Fotodateien durchsucht, die aus diesem Speicherplatz noch gerettet werden könnten. Dieses Programm erzielt in der Regel sehr gute Ergebnisse. […] Die Ergebnisse des Programms Photorec lieferten keine Spur des fehlenden Bildes "IMG_0509.JPG"

Quelle: Hardinghaus/Nenner: Verschollen in Panama (2024), S. 112 f.

Doctective schrieb:Okay, dann halten wir das wörtliche Zitat aus dem NFI-Bericht einfach mal fest, genauso wie es da steht. Ist in unserem Buch auf Deutsch und Englisch aber auch als solches gekennzeichnet, wie alle Zitate ,-)

Aber woher kommt dann die Einschätzung, dass es diesen "Fehler" nur genau ein einziges Mal, nämlich bei #509, gegeben habe? Und worin genau besteht der Fehler?

Es gibt ja offenbar mind. 63 fehlende Bild-/Video-Nummern zu denen es auch null Infos gibt (wenn man die Zahlen bei IP mal entspr. umrechnet).

Und wo hat Scarlet den zweiten Teil des wörtlichen Zitats auf ihrer Seite (s.o.) her?

cyclic schrieb:Aber woher kommt dann die Einschätzung, dass es diesen "Fehler" nur genau ein einziges Mal, nämlich bei #509, gegeben habe? Und worin genau besteht der Fehler?

Ich habe keine Ahnung, woher diese Einschätzung kommt. In unserem Buch steht das IMHO nicht.

@Doctective, @cyclic

Es dreht sich alles um das Wort "Fehler". ViP nennt das Wort im Satz: None of the photos previously deleted on the camera, which could be recovered using forensic software, caused such an error in the file system. Seite. 133, Kindle.
Hier wird der NFI Person nicht zitiert, aber ist das eine Umschreibung von den Autoren.

Scarlet hat bereits denselben Text aus ViP verwendet, deshalb auch das Wort „Fehler“, "Error".

Die Frage ist, ob der NFI-Bericht auch von „Error“ / "Fehler" spricht? Welcher Begriff wird in den NFI-Bericht für „Error“ verwendet?
Haben sie z.B. das niederländische Wort "Fout" verwendet?

Agno schrieb:Offenbar löst der Baseband-Chip kein Aufwachen der Haupt-CPU aus.

Doch, es gibt den Wake-Grund "Baseband". Das Event wird aber nicht bei jeder Änderung der Baseband-Werte ausgelöst, was ja logisch ist, sonst schläft der Hauptprozessor nie.

Agno schrieb:Das wirft die Frage auf, was den Transfer der flüchtigen Baseband-RAM-Daten in den persistenten Flash auslöst.

Umgekehrt. Das iPhone wacht auf, bezieht aktuelle Daten vom Baseband und loggt diese oder loggt Käse (Freeze, Dummy).

Agno schrieb:Das muss nicht unbedingt stimmen; der Impuls, die Baseband-RAM-Logs in den persistenten Speicher zu schreiben, könnte ebenso durch das Aufwachen ausgelöst worden sein, das für den 112-Anrufversuch um 16:39 nötig war. Somit können RAM-Daten rückwirkend gespeichert werden.

Nein. Wie gesagt: Erst aufwachen, dann messen / ermitteln, dann loggen. Was das Baseband in der Sleep-Phase im RAM veranstaltet ist wurscht, die Werte (RSSI usw.) können sich sekündlich ändern.

##

Ansonsten hat sich die Sache mit dem 3 Stunden-Zeitraum vor den Notrufen erledigt bzw. ins Gegenteil gedreht, nun sind es (nach meiner Interpretation) auffällig viele, sehr sehr viele, Powerlogs in diesem Zeitraum .. :-)

Auch zum Baseband-Report gibt es ein paar Neuigkeiten, u.a. gab es kein Hard-Reset des Modems (die "Uptime" lief also weiter). Und die beiden Notrufe liegen relativ "gemütlich" auseinander, in der Zeit schaffe ich locker 4 bis 5, denn es braucht keine Wahlwiederholung oder so, einfach den nach einem Disconnect aufploppenden grünen Button tippen:



Werde demnächst den Blog entsprechend aktualisieren.

Offshore7 schrieb:Doch, es gibt den Wake-Grund "Baseband". Das Event wird aber nicht bei jeder Änderung der Baseband-Werte ausgelöst, was ja logisch ist, sonst schläft der Hauptprozessor nie.

Ein solches „Baseband“-Ereignis könnte etwa ein Absturz sein; in diesem Fall würde ich einen „gepushten“ Mini-Dump in der Datei BasebandCrash_.plist* erwarten.

Dennoch überrascht mich, dass dieses 13:38 Freeze-Ereignis fast genau in dem Moment protokolliert wurde, als sie in eine Funklochzone gerieten – das wirkt auf mich wie ein nach­drücklich übermittelter Log-Eintrag. Ich halte es für eher unwahrscheinlich, dass die Mädchen ihre Telefone just in diesem Augenblick einschalteten (man spürt elektromagnetische Wellen ja nicht und merkt ihr Fehlen auch nicht plötzlich...).

Offshore7 schrieb:Nein. Wie gesagt: Erst aufwachen, dann messen / ermitteln, dann loggen. Was das Baseband in der Sleep-Phase im RAM veranstaltet ist wurscht, die Werte (RSSI usw.) können sich sekündlich ändern.

Okay, das klärt es: Im RAM des Infineon X-GOLD 618 (PMB9800) wird tatsächlich nur der jeweils aktuelle Datensatz gehalten. Ich hatte gedacht, es gäbe dort vielleicht noch ein paar Zeilen Verlauf, aber offenbar ist das nicht der Fall.

Offshore7 schrieb:Ansonsten hat sich die Sache mit dem 3 Stunden-Zeitraum vor den Notrufen erledigt bzw. ins Gegenteil gedreht, nun sind es (nach meiner Interpretation) auffällig viele, sehr sehr viele, Powerlogs in diesem Zeitraum .. :-)

Das wäre ein sensationeller Fund. Deine Nachricht ist etwas kryptisch, deshalb versuche ich nachzuvollziehen, wie du zu diesem Schluss gelangt bist, vielleicht so etwas: Jeder Powerlog-Eintrag besitzt eine Sequenznummer; du hast die fehlenden Nummern zwischen dem Beginn und dem Ende dieses berüchtigten dreistündigen Zeitfensters geprüft und dabei festgestellt, dass dort sehr viele Powerlogs fehlen? Gibt es so etwas wie einen Overflow, wenn zu viele Powerlogs erzeugt werden? Ich bin wirklich neugierig, was genau deine Gedankengänge dabei waren.

Was könnte im Sleep-Modus eine derart große Anzahl von Powerlogs erzeugen?

Offshore7 schrieb:Auch zum Baseband-Report gibt es ein paar Neuigkeiten, u.a. gab es kein Hard-Reset des Modems (die "Uptime" lief also weiter). Und die beiden Notrufe liegen relativ "gemütlich" auseinander, in der Zeit schaffe ich locker 4 bis 5, denn es braucht keine Wahlwiederholung oder so, einfach den nach einem Disconnect aufploppenden grünen Button tippen:

Toller Funds. Nur um sicherzugehen: Beziehst du dich auf die beiden aufeinanderfolgenden 911-Anrufe am 3. April?

Anthurium schrieb:Scarlet hat bereits denselben Text aus ViP verwendet, deshalb auch das Wort „Fehler“, "Error".

Die Frage ist, ob der NFI-Bericht auch von „Error“ / "Fehler" spricht? Welcher Begriff wird in den NFI-Bericht für „Error“ verwendet?
Haben sie z.B. das niederländische Wort "Fout" verwendet?

Das ist halt das Problem, wenn dauernd davon die Rede ist, aus den Akten zu "zitieren", aber de facto überhaupt nicht klar wird, was wirklich direktes Zitat, was Paraphrase und was Interpretation der Autoren ist. Ohne diese Differenzierung taugt das Buch mmn nicht als verlässliche Quelle. Eher als spannende Prosa für Krimifans.

augustine schrieb:Das ist halt das Problem, wenn dauernd davon die Rede ist, aus den Akten zu "zitieren", aber de facto überhaupt nicht klar wird, was wirklich direktes Zitat, was Paraphrase und was Interpretation der Autoren ist

Das ist sehr klar. Zitate sind als solche gekennzeichnet, kursiviert, abgesetzt, mit Quellenangabe versehen. Das ist das Gute am wissenschaftlichen Arbeiten, dass man so immer ganz genau nachvollziehen kann, was Zitat und was Autorenmeinung ist. Buch mittlerweile gelesen, oder bewertest du "de facto" immer noch ohne jede Grundlage?

Doctective schrieb:Das ist sehr klar.

Doctective schrieb:Welches Zitat genau (Wortlaut). Ich stehe gerade auf dem Schlauch.

Also hat der Forensiker nicht von einem Fehler im Dateisystem geschrieben, sondern das ist eure Interpretation? Das war ja die Frage und dir scheint die Textsstelle selbst nicht mehr so ganz klar zu sein ;)

Wenn der so bezeichnete einzigartige Fehler im Dateisystem aber nur eine Interpretation der Autoren ist, dann hatte der Forensiker vermutlich das Löschen mit nachfolgendem Überschreiben als naheliegenden Grund betrachtet und es spricht auch aus dessen Sicht nichts dagegen. Der Speicherfehler, den @Agno erzielen konnte, wäre eine weitere Möglichkeit, aber eine, die Bedingungen/Besonderheiten erfüllen müsste (der Kontaktfehler muss erstmals beim Auslösen auftreten). Das wäre jetzt mein aktuelles Fazit in der Diskussion zum nicht existierenden Bild 509, @cyclic hatte dieses Fazit bereits vor längerer Zeit gezogen.
Ein Löschen am Computer müsste ebenfalls Bedingungen/Besonderheiten und vor allem eine Motivation und technisches Wissen erfordern, diese Variante wäre also meiner Meinung nach als sehr unwahrscheinlich zu betrachten. Hinweise darauf gibt es keine.

staminag schrieb:Der Speicherfehler, den @Agno erzielen konnte, wäre eine weitere Möglichkeit, aber eine, die Bedingungen/Besonderheiten erfüllen müsste (der Kontaktfehler muss erstmals beim Auslösen auftreten).

Das was @Tatum getestet hat - d.h. Entfernen der Speicherkarte zwischen Auslösen und Beginn der Speicherung auf der SD-Karte, also während die Rohdaten intern prozessiert werden, hat den großen Nachteil, dass das praktisch genau im Moment des Auslösens passieren muss, bzw. minimalem Delay (wobei ja ein Rausfallen der SD-Karte dank Deckel ohnehin unmöglich ist, aber als Bsp. für einen schweren Fehler ist das schon brauchbar).

Der Clou an dem Prozedere von @Agno ist aus meiner Sicht aber, dass der Fehler schon nach dem Einschalten bis zum Auslösen auftreten kann, also indem z.B. ein Kondenswassertröpfchen beim Drehen der Kamera zw. Hoch- und Querformat an die falsche Stelle fließt. Das gibt ein paar Sekunden mehr Zeit bis zur Aufnahme. Dass ein Fehler dagegen erst genau im Moment des Auslösens auftritt erscheint mir wahnsinnig unwarschrscheinlich. Zumal bei hinterher unbeschädigter Kamera.

staminag schrieb:Ein Löschen am Computer müsste ebenfalls Bedingungen/Besonderheiten und vor allem eine Motivation und technisches Wissen erfordern, diese Variante wäre also meiner Meinung nach als sehr unwahrscheinlich zu betrachten. Hinweise darauf gibt es keine.

Wenn das NFI das Löschen als irgendwie nur in Zusammenhang mit einem zusätzlichen Fehler als wahrscheinlich erachtet hätte, obwohl nach allem was wir hier inzwischen erarbeitet haben, ein ganz normales Löschen völlig ausreichend ist, wäre das ein Hinweis gewesen.

Aber irgendwie scheint es ein Ding der Unmöglichkeit zu sein das Drama hier aufzuklären. Ich verstehe es jedenfalls immer noch nicht.

Was ich auch nicht verstehe ist: Man hat beim NFI, so wie es aussieht, keinerlei Vergleichstests gemacht. Man hat sich scheinbar auch nicht angesehen, wie sich das bei anderen gelöschten und nicht wiederherstellbaren Dateien verhalten hat? Ein Vergleich mit den 40 Bildern die wiederherstellbar waren erübrigt sich ja weitgehend, erstens weil sie eben wiederherstellbar waren und zweitens weil das sämtlich keine normalen Canon-Jpegs waren, sondern irgendwelche verkleinerten Ansichten zu denen die Canon-Originale auch noch existierten und drittens weil die vermutlich am Ende des belegten Speichers abgelegt waren und nicht irgendwo zwischen normalen Bildern. Man hätte das mMn doch mal mit den 63 oder 103 ebenfalls spurenlos verschwundenen (gelöschten) Bildern/Videos vergleichen müssen (oder halt eigene Tests durchführen müssen). Gerade weil das NFI selbst beschreibt wie außergewöhnlich #509 allein schon aufgrund der Lage zw. Tag- und Nachtbildern war.

Was leider auch völlig unaufklärbar bleiben wird ist der von @sceptical eingebrachte interessante Aspekt des Schlupfspeichers. Da #510 so außergewöhnlich winzig für eine Canon-Jpeg-Datei ist, hätten Reste von #509, wenn es die Datei je gab, fast sicher im Schlupfspeicher auffindbar sein müssen. Wären da hingegen nur 1en (alle Bits) dann gab es nie eine #509. Ob einem EnCase diese Info irgendwie aufdrängt, oder ob man EnCase aktiv dazu veranlassen muss danach zu suchen (wie in WinHex) und ob man das getan hat, ist aus den bekannten Infos leider überhaupt nicht ersichtlich.

staminag schrieb:Also hat der Forensiker nicht von einem Fehler im Dateisystem geschrieben, sondern das ist eure Interpretation?

Es bleibt jedoch ein Fehler. Ein Fehler in den ´Foto Logs´. Das Fehlen von Foto 509 ist eine Anomalie. Das ist damit gemeint.
Fout / Afwijking / what ever.

Agno schrieb:Dennoch überrascht mich, dass dieses 13:38 Freeze-Ereignis fast genau in dem Moment protokolliert wurde, als sie in eine Funklochzone gerieten

Um 13:38 Uhr war das iPhone bereits im Funkloch. Die Funklochzone dürfte schon zB um 13:28 Uhr erreicht worden sein, wo das Baseband letztmalig reale -94 dBm registrierte, die dann beim Einschalten um 13:38 Uhr als Freeze-Log auftauchen.

Agno schrieb:Okay, das klärt es: Im RAM des Infineon X-GOLD 618 (PMB9800) wird tatsächlich nur der jeweils aktuelle Datensatz gehalten.

Das wüsste ich nicht mal, aber die Bezeichnung kommt mir bekannt vor. :-)

Agno schrieb:Jeder Powerlog-Eintrag besitzt eine Sequenznummer; du hast die fehlenden Nummern zwischen dem Beginn und dem Ende dieses berüchtigten dreistündigen Zeitfensters geprüft und dabei festgestellt, dass dort sehr viele Powerlogs fehlen?

Genau, zum. einige Powerlog-Einträge. Da ich auf IP in den 3 Stunden weder Akku- noch Signalstärke-Logs sehe, gehe ich davon aus, dass diese knapp 800 Powerlogs nur auf den DVDs wohnen.

Agno schrieb:Gibt es so etwas wie einen Overflow, wenn zu viele Powerlogs erzeugt werden?

Nö, denke nicht. Gerade im lfd. Betrieb (Display an, App-Nutzung) fallen sehr viele Powerlogs an.

Agno schrieb:Was könnte im Sleep-Modus eine derart große Anzahl von Powerlogs erzeugen?

ME gar nix, siehe Blog Punkt XIII. Kann ja kein gesunder Schlaf sein, wenn das Ding dauernd loggt. :-) Und beim Samsung sieht es ja auch eher nicht nach 3 Std. Standby aus.

Agno schrieb:Beziehst du dich auf die beiden aufeinanderfolgenden 911-Anrufe am 3. April?

Yep.

cyclic schrieb:Man hat beim NFI, so wie es aussieht, keinerlei Vergleichstests gemacht. Man hat sich scheinbar auch nicht angesehen, wie sich das bei anderen gelöschten und nicht wiederherstellbaren Dateien verhalten hat?

Vermutlich nicht. Es sieht so aus, als wenn man sich bei der Untersuchung die Fragen, die wir hier haben, gar nicht gestellt hat.

Anthurium schrieb:Es bleibt jedoch ein Fehler. Ein Fehler in den ´Foto Logs´. Das Fehlen von Foto 509 ist eine Anomalie

Nur in Bezug auf den Untersuchungszeitraum 31. März/ 1. April, wobei am 31. März keine Fotos gemacht wurden. Im gesamten Fotobestand gibt es aber meines Wissens mehrere Bildnummern ohne zugehöriges Bild.

Offshore7 schrieb:Da ich auf IP in den 3 Stunden weder Akku- noch Signalstärke-Logs sehe, gehe ich davon aus, dass diese knapp 800 Powerlogs nur auf den DVDs wohnen.

Verstehe ich das richtig: Es gibt vermutlich knapp 800 Powerlogs in den drei Stunden, während bei deinem Test im Standby ohne Nutzung aber nur ca. 100 zu erwarten sind? Das spricht doch dafür, dass das IPhone (oder beide Geräte) für irgendwas genutzt wurden, was nur im NFI-Bericht nicht auftaucht, oder was vermutest du als Grund?

Anthurium schrieb:Es bleibt jedoch ein Fehler. Ein Fehler in den ´Foto Logs´. Das Fehlen von Foto 509 ist eine Anomalie. Das ist damit gemeint.
Fout / Afwijking / what ever.

Also auf Deutsch kann man eigentlich nicht von einem Fehler sprechen, wenn es ohne irgendeine Fehlfunktion erreichbar ist. Man könnte von einem möglichen Fehler sprechen, wenn es u.a. auch durch eine Fehlfunktion erreichbar ist, oder einer Abweichung, Anomalie, oder ähnlichem. Interessant wäre halt, ob im NFI-Bericht überhaupt irgendeines dieser Wörter benutzt wurde.

staminag schrieb:Nur in Bezug auf den Untersuchungszeitraum 31. März/ 1. April, wobei am 31. März keine Fotos gemacht wurden. Im gesamten Fotobestand gibt es aber meines Wissens mehrere Bildnummern ohne zugehöriges Bild.

Um das nochmal zu verdeutlichen, was sich aus den Angaben bei IP ergibt + der Annahme, dass die 64+4 od. 24+4 durch noch vorhandene Verzeichniseinträge gelöschter und bereits überschriebener (Datenbereich) Dateien nachweisbar waren (sorry es ist etwas ASCII-Art'ig):

166 Bilder/Vidos vor der Reise aufgenommen (#167 ist erstes Reisebild) 470 + 7 = 477 Images/Videos auf SD 33 + 0 Pianista/Mirador/Q1 (01.04) 100 + 0 Nacht (08.04) 337 + 7 = 344 < 01.04. existierende Aufnahmen gefunden 475 < 01.04. mit der Camera aufgenommen (Januar - 31.03.) 131 gelöscht ENTWEDER: 64 + 4 = 68 gelöscht mit Spuren (FAT-Verzeichniseinträge) 63 gelöscht ohne Spuren (nur fehlende Bild/Video-Nummern) ODER (40 in 64 enthalten): 24 + 4 = 28 gelöscht mit Spuren (FAT-Verzeichniseinträge) 103 gelöscht ohne Spuren (nur fehlende Bild/Video-Nummern)

Also gibt es offenbar entweder zu 63 oder 104 Dateien (Bild-/Video-Nummern) auch keinerlei Infos. Nun können die sämtlich ganz am Anfang auf einer anderen SD-Karte oder auf derselben aber noch im Januar gelöschten / neu formatieren Karte gespeichert gewesen sein. In dem Fall kann man da nichts auswerten. Dann wäre #509 tatsächlich vollkommen einzigartig (umso wichtiger wäre dann ein Vergleichstest gewesen um die Annahme einer Löschung abzusichern).

Sollten aber jemals ab Januar Bilder oder Videos gelöscht worden sein, hätte man ja Vergleichsmaterial gehabt (erkennbar daran, dass fehlende Bildnummern höher als die kleinste existierende Bildnummer war). Und wenn man schon keine Tests macht, hätte man doch zumindest mal darauf abstellen sollen: waren die irgendwie anders als #509 oder passt alles zusammen?

PS: Es ist gerade bei der Kamera verdammt leicht mal versehentlich auf den Video-Rec-Knopf zu kommen (viel höhere Gefahr als bei meiner S120). Ist mir häufiger passiert. Zumindest solche Videos wird man wohl löschen wollen und zwar vorzugsweise sofort (was auch der möglichen Situation bzgl. #509 entspräche).

---

@Offshore7
Ganz sicher, dass die vermeintlichen Zeilennummern nicht vielleicht auch verkappte, seltsam kodierte Zeitstempel sein können (nur im sicher zu gehen)?

staminag schrieb:Der Speicherfehler, den @Agno erzielen konnte, wäre eine weitere Möglichkeit, aber eine, die Bedingungen/Besonderheiten erfüllen müsste (der Kontaktfehler muss erstmals beim Auslösen auftreten).

Das stimmt nicht; meine Erkenntnisse stützen die folgende Abfolge von Ereignissen:
1) Man versucht, ein Foto zu machen, die Kamera fällt herunter und schlägt auf einen Stein – oder landet vielleicht im Wasser, oder beides (das ist es, was den Kontaktfehler verursacht)
2) Man hebt sie auf, prüft sie und erhält beim nächsten Auslöserversuch die Meldung „Memory Card Error“; die Bildnummer wird übersprungen und nichts wird auf der SD-Karte gespeichert (anders als bei einer Löschung).
3) Schaltet man die Kamera aus und wieder ein, erscheint derselbe Meldung erneut, und die Kamera wirkt nun wie ein nutzloser „Backstein“.
4) Der Fehler lässt sich in der Regel leicht beheben: SD-Karte herausnehmen und erneut einsetzen oder die Kamera ein paar Tage trocknen lassen. Wahrscheinlich gibt es deshalb in Canon-Foren nicht massenhaft Beschwerden über dieses Problem – die meisten Nutzer lösen es selbst oder kaufen einfach eine neue SD-Karte.

Du könntest also zwischen 1) und 2) eine Stunde warten (die Kamera bleibt dabei eingeschaltet) und würdest trotzdem denselben Effekt einer übersprungenen Bildnummer beobachten. Diese Ereignisse benötigen keinerlei Synchronisation. Falls die Kamera im ausgeschalteten Zustand herunterfällt (also gerade nicht benutzt wird), erscheint nach einschalten sofort die Meldung „Memory Card Error“ – und es kann keine Bildnummer übersprungen werden, weil sich schlicht kein Foto aufnehmen lässt. Also deutet alles darauf hin, dass beim Auslösen des Fotos etwas schiefgelaufen ist. Der Versuch, das nächste Foto etwa in der Nähe von Q2 oder Q3 aufzunehmen, entspricht dem Muster der Mädchen.

Dies liefert eine einfache Erklärung für die Abfolge der Ereignisse:
• Foto 509 fehlt – keinerlei Spuren auf der SD-Karte
• plötzlich werden keine weiteren Fotos gemacht, auch nicht mit dem Handy (die Stimmung ändert sich, wenn die Kamera kaputt ist. Oder der offene Rucksack kippt um, und die Handys erleiden ebenfalls einen Wasserschaden).
• ein Kameraproblem, das behoben werden konnte oder sich von selbst behoben hat (man musste also nicht im Morgengrauen des 8. April an der SD-Karte herumfummeln; sie hätten die Kamera einfach nehmen, ausprobieren und feststellen können, dass sie wieder funktioniert – z. B. weil sie getrocknet war).

Dieses Szenario passt wie angegossen zu den bekannten Ereignissen, aber ich bin offen für jede andere ebenso einfache Erklärung. Es handelt sich also weder um ein einfaches Löschen der 509 (das Spuren hinterlassen würde), noch um eine böswillige Manipulation per PC oder das Vorhandensein einer zusätzlichen SD-Karte (was nicht erklären würde, warum am 1. April keine weiteren Fotos aufgenommen wurden).

Offshore7 schrieb:ME gar nix, siehe Blog Punkt XIII. Kann ja kein gesunder Schlaf sein, wenn das Ding dauernd loggt. :-) Und beim Samsung sieht es ja auch eher nicht nach 3 Std. Standby aus.

Lass mich zusammenfassen, was ich bislang verstanden habe:
• Deine Beispiel-Logdateien unter Punkt XIII zeigen deutlich, dass das iPhone 4 im wachen Zustand eine Menge Logeinträge erzeugt, während es im Ruhezustand kaum etwas protokolliert (abgesehen von der (halb-) stündlichen Abfrage von Akkustand und Signalstärke).
• Deiner Vermutung zufolge existieren jedoch auf der DVD vermutlich mehr als 800 Powerlog-Einträge; das NFI habe sie ignoriert, weil sie weder Akku- noch Signalstärkedaten enthalten.

Das ist schwer zu erklären. Vorstellbar wäre nur, dass das Telefon während dieser drei Stunden tatsächlich wach war – das widerspricht allerdings dem relativ geringen Batterieverbrauch. Und hätten die Mädchen ihre Telefone um 13:38 Uhr aufgeweckt, um damit einen Freeze-Log dauerhaft abzuspeichern, müsste es auch einen „Wake“-Eintrag geben, der den Weckgrund nennt (RTC, Benutzer, Baseband usw.); das NFI hätte ihn bemerkt. Theoretisch könnte ich mir ein Szenario vorstellen, in dem der Sleep/Wake-Button des Telefons im Rucksack häufig gedrückt wurde. Doch auch dann wären das Polling und das Aufzeichnen von Akku- und Signalstärkewerten ausgelöst worden – und gerade diese Daten hat das NFI nicht gefunden.

Bleibt also nur die Annahme, das System sei im Sleep-Modus gewesen, habe aber intern ständig „gegrübelt“. Doch bezweifle ich, dass es so etwas wie einen „Albtraum-Modus“ gibt … Vielleicht könnte ein mechanischer Defekt oder ein Wasserschaden einen solchen Effekt verursachen.

Das Ganze erscheint mir eher unwahrscheinlich, und letztlich wird nur die DVD Aufschluss über die Wahrheit geben.

@staminag

Tatum schrieb am 25.06.2025:Wenn du die SD Karte rausziehst während oder unmittelbar nachdem (<1s oder so) du den Auslöser drückst geht die Kamera zwar aus, aber wenn du die SD Karte wieder einsteckst und danach weiter Fotos machst wirst du feststellen dass ein Foto übersprungen wurde. Das ist gut reproduzierbar.

Ich habe das jetzt übrigens auch mal getestet und es hat auch gleich beim ersten Versuch geklappt (gut reproduzierbar kann ich also bestätigen). Das hat mir gereicht, denn eigentlich kam mir vorhin eine andere Idee:

Öffnen des Deckels der Akku-/SD-Karten-Slots im richtigen/falschen Moment, weil ich das für noch eher vorstellbar halte. Ich habe nicht endlos viele Versuche gestartet, aber es ist mir bisher nicht gelungen auf die Art den Fehler auszulösen. Entweder das Bild wurde gespeichert (ich war zu langsam), oder es wurde nicht gespeichert, aber auch keine Nummer übersprungen.

Allerdings hatte ich lustige Effekte, bis hin zum kompletten Hängenbleiben, bei eingeschaltetem Display, wo nur noch Auswerfen und Wiedereinstecken des Akkus geholfen hat.