Hash Wert der richtige Weg ?

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Hallo,

    Zitat

    Mein System ist ein RasPi 4 mit 2GB RAM /

    Gut - aber dann kann das doch auch nicht gut funktionieren, wenn ein Programm für's Hashing die Datei komplett im Speicher braucht. Sagen wir mal, du hast ~1,25 GB RAM frei, dann fängt das System kurz bevor das RAM voll läuft heftig an zu swappen, weil halt das RAM voll läuft. swappen ist halt langsam, weil RAM auf die SD Karten (swap Datei oder Partition) geschrieben wird.

    Wie gesagt weiß ich nicht, ob die hashlib von Python mit Datenströmen arbeiten kann, ich vermutet aber mal, dass mit kompletten Dateien gearbeitet wird. Was auch erklären würde, weswegen das Programm scheinbar nichts mehr macht, weil es auf's swappen wartet.

    Gruß, noisefloor

  • Wie gesagt weiß ich nicht, ob die hashlib von Python mit Datenströmen arbeiten kann, ich vermutet aber mal, dass mit kompletten Dateien gearbeitet wird. Was auch erklären würde, weswegen das Programm scheinbar nichts mehr macht, weil es auf's swappen wartet.

    Das wäre sehr eigenartig und einschränkent, wenn Python das nicht unterstützen würde.

    Mein Beispiel verdeutlicht das mit mmap. Da befindet sich nur ein Teil des Abbilds im Speicher. Was da ganz genau passiert, müsste man der Implementierung entnehmen.

    Explizit iterativ geht mit der update-Methode.

  • Guten Abend

    Der richtige Aufruf für rdfind wäre in deinem Fall :
    rdfind -dryrun true -deleteduplicates false -outputname /media/pi/File_Liste.txt /media/pi/Toschiba35

    Um jetzt mal eine klare Stellungnahme abzugeben, dass ist die größte Drecksoftware die ich je gesehen habe. Wie Der_Imperator hier vorgegeben hatte, schein es diese Software nicht zu interessieren, dass der Parameter -deleteduplicates false gesetzt war. Wieder kommt trotz, wie nennt man das "Vortext" , das zwar der DRYRUN Modus aktiv sei, wieder diese dämliche Frage ob er nun mit irgendwas Löschen beginnen will. Auf N wie No regiert das dämliche Programm nicht , und wenn man dann mit STRG+C das Ganze abbricht wird die eingeforderte Log-Datei trotzdem nicht erzeugt.
    Das Programm habe ich umgehend wieder vom System entfernt.

    A) es findet nichts, oder nur kleine Dateien ,
    B) einzelne Parameter werden offensichtlich ignoriert,

    C) die Bedienung ist schlicht und einfach nur zum <X

    Dafür bin ich zum meinem alten Python Proggi zurückgekehrt, und habe die Vorschläge von @DeaD_EyE aus dem Beitrag #23 umgesetzt. :danke_ATDE:
    Das so modifizierte Programm ackert nun schon über eine Stunde die USB-HDD durch, ist sogar bei über 32 GB große Dateien problemlos durchgelaufen. Und hat auch einen Hashwert am Ende des Funktionsaufrufes bei bis jetzt jeder zugewiesenen Datei ausgespuckt. Nun warte ich noch bis er damit fertig ist, und werde mal vergleichen, ob das wirklich so alles stimmig ist.

    Was ich aber schon als positives Zwischenergebnis vermelden kann, die beiden Dateien, die von rdfind als "nicht identisch" identifiziert wurden (oder wie auch immer ) , hier hat das Python-Proggi dank des Vorschlags von DeaD_EyE zwei identische Hashwerte ermitteln können.

    Ich bin guter, sehr guter Hoffnung dass das PI damit irgendwann mal fertig wird, und mir eine Liste ausspuckt, auf die ich mich wirklich verlassen kann. Leider sind es mit einigen Musikfiles, und einigen anderen "Ablagerungen" - über 2,1 Millionen Dateien die auch erst einmal durchgesehen werden müssen.

    Gut Ding will Weile haben ;)

    es grüßt euer
    Willy

  • Guten Morgen,

    Ha, :bravo2:
    Nachdem ich heute früh aus dem Bett gekrochen bin, und geschaut habe was, das "Arbeits-PI" so treibt - totales Erstaunen. :sleepy:
    Es hat nicht die rote Flagge gehoben, ist nicht abgebrannt, der Prompt blinkte gelangweilt im Konsolenfenster, und zu meinem größten erstaunen, ich muss noch eine Programmergänzung anfügen.
    Die 1000 Zeilen, die man zurückscrollen kann reichen nicht, um mir alle Funde anzuzeigen. Das liegt wohl auch an der Ausgabeformatierung, das pro Ausgabe bei gefundenen Duplikaten mindestens 2 Textzeilen draufgehen.

    Also werde ich jetzt noch eine LOG-Fileausgabe anfügen.

    Jetzt hätte ich besonders an @DeaD_EyE und Dennis89 die mir hier die absoluten Python Programmierprofis zu scheinen sind, aber auch jeden der sich angesprochen fühlt, eine Zusatzfrage ;)
    "Ich nehme mal den Telefon-Joker" :saint:

    Mir ist aufgefallen das die Videofiles in den drei Hauptformaten MP4, MPEG und AVI vorliegen. Ebenso das stark unterschiedliche Videoauflösungen verwendet werden.
    Damit kommt man mit der HASH Methode natürlich nicht weiter.

    Da ich das Programm jetzt ohnehin noch ergänzen muss, und die Rechenzeit mir schlicht egal ist, weil das PI von meinem kleinen Balkon-Mini-Solarkraftwerk mit knapp 600 Ah Pufferbatterie gespeit wird, und somit Netz-autark ist, ob man nicht, so meine Grundidee:
    Wenn eine Datei zur Ermittlung des Hash-Werte ohnehin geöffnet wird, könnte man da nicht gleich noch anhand eines Filter der sich die Dateiendungen anschaut in Erfahrung bringen welche Auflösung und Abspiellänge diese Videofile hat ?
    Dann so mein rein theoretischer Ansatz, sich merkt welches das kleinste genutzte Videoformat z.B. 640x480 oder sowas in der Art ist. Das mit dem Hintergrund, zu sagen okay, ich habe nun verschiedene Files die annähernd auf z.B. 5 oder 10 Sekunden die gleiche Abspiellänge haben.
    Nun nimmt man das Videofile mit der kleinsten Auflösung aus dieser Ähnlichkeitsliste , und konvertiert ( Platz ist reichlich vorhanden ) die möglichen ähnlichen Files auf das gleiche Format herunter. Und nun wenn man beide Files, das Ausgangsfile und das Konvertierte hat, sagt man einfach ( Gedanklich einfach ) die ersten 2 Sekunden am Anfang und Ende lässt du mal unter den Tisch fallen, und vergleichst nur die Videoausgabe so, ob es für die gesamte Videoausgabe ein Muster gibt, in dem man feststellt, ja der Hauptteil ist theoretisch von der Bildinformation identisch. Das mit dem Hintergrund: "Aha, ja diese Datei ist ein Clone" nur in einem anderen Wiedergabe- und / oder Dateiformat.

    Ich weiß das dürfte nicht so einfach sein, wie man es mit Worten recht simpel beschreiben kann.
    Es wäre mir auch egal, ob das PI damit dann eine oder zwei Wochen beschäftigt wäre. Hauptsache ich muss mir nicht jede Datei einzeln ansehen, um weitere Duplikate in der recht großen Sammlung von zum Teil, ich nenne es mal erzeugten Datenmüll, zu finden. Die dabei erzeugten Auflösungsidentischen Duplikate können dann ja wieder gelöscht werden, wenn der Vergleich abgeschlossen ist. :helpnew:

    Jetzt werde ich mal die Dateiausgabe noch anfügen, und bin gespannt, ob ich zu meiner Idee noch ein paar wirklich brauch- und nutzbare Anregungen Vorschläge bekommen. :danke_ATDE:

    es grüßt euer
    Willy

  • Hi Willy,

    bezüglich Videovergleich wird wohl ffmpeg Dein Freund sein. Der kann anscheinend auch Videos vergleichen...

    Ich hab's noch nie probiert und es scheint nicht straight-forward zu sein. Aber es ist in den meisten Linux-Distros enthalten.

    Mein Vorgehen wäre hier:

    1. Die mit der bisherigen Hashmethode gefundenen 1:1-Duplikate entfernen

    2. Die Lust sammeln, das Projekt auf den Videovergleich zu erweitern :lol:

    3. Einlesen in die man-pages von ffmpeg (richtig laaaang, deshalb sollte aber das Meiste auch wirklich drinstehen -- ist die Lust noch da?)

    4. Ebenfalls mit ffmpeg alle Videodateien auf ein einheitliches Format und die gleiche Auflösung konvertieren, ggf. auf einer zweiten Platte mit gleicher Verzeichnisstruktur.

    5. Die Dateien mit den Programmen ffplay oder ffmpeg auf Gleichheit prüfen, wie z.B. hier auf stackoverflow beschrieben. Das wird ziemlich langsam sein. Außerdem ist dort nicht beschrieben, wie man zwei Videos auf 95%(?) Gleichheit prüft. Aber das Internet ist groß.

    Das Wenige was ich vom ffmpeg-Paket weiß, dass es ein Filter ist, der aus einem oder mehreren Inputdateien (Quellen) eine Ausgabe erstellt. Wirklich gearbeitet habe ich damit noch nicht, nur ein paar einfache Versuche gemacht.

    Viel Spaß!

  • gerade noch etwas gefunden: Delta file (difference file)

  • Hallo,

    die mir hier die absoluten Python Programmierprofis zu scheinen sind,

    von der Liste würde ich mich gleich mal wieder streichen. Ich würde mich weder als Programmier und schon gar nicht als Profi bezeichnen.

    Das aufwendigste wird wohl der Vergleich von den Videos sein. Hier würde ich mal in Richtung OpenCV Ausschau halten.

    Ich habe das aber noch nie gemacht und muss vermutlich so viel im Internet suchen wie du.

    Weiterhin viel Erfolg und falls ich mal noch was sinnvolles einbringen kann melde ich mich.

    Grüße

    Dennis

    🎧 With the music execution and the talk of revolution, it bleeds in me and it goes 🎧

  • Hallo Willy,

    Dann so mein rein theoretischer Ansatz, sich merkt welches das kleinste genutzte Videoformat z.B. 640x480 oder sowas in der Art ist. Das mit dem Hintergrund, zu sagen okay, ich habe nun verschiedene Files die annähernd auf z.B. 5 oder 10 Sekunden die gleiche Abspiellänge haben.
    Nun nimmt man das Videofile mit der kleinsten Auflösung aus dieser Ähnlichkeitsliste , und konvertiert ( Platz ist reichlich vorhanden ) die möglichen ähnlichen Files auf das gleiche Format herunter. Und nun wenn man beide Files, das Ausgangsfile und das Konvertierte hat, sagt man einfach ( Gedanklich einfach ) die ersten 2 Sekunden am Anfang und Ende lässt du mal unter den Tisch fallen, und vergleichst nur die Videoausgabe so, ob es für die gesamte Videoausgabe ein Muster gibt, in dem man feststellt, ja der Hauptteil ist theoretisch von der Bildinformation identisch. Das mit dem Hintergrund: "Aha, ja diese Datei ist ein Clone" nur in einem anderen Wiedergabe- und / oder Dateiformat.

    ich glaube nicht, dass dieser Ansatz funktionieren kann. Ich lasse mich da aber gern eines Besseren belehren.

    Jede Konvertierung ist mit Datenverlusten verbunden. Bei Umwandlung von dem einem Format in ein anderes Format mehr, bei einem anderen Format weniger. Du solltest nicht davon ausgehen, wenn Du alle Videos in das gleiche Video-Format z.B. in AVI und einer bestimmten Auflösung konvertieren lässt, dass der Hash-Wert dann identisch sein muss oder sein wird.

    Beste Grüsse

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Guten Abend Andreas

    Hallo Willy,

    ich glaube nicht, dass dieser Ansatz funktionieren kann. Ich lasse mich da aber gern eines Besseren belehren.

    Jede Konvertierung ist mit Datenverlusten verbunden. Bei Umwandlung von dem einem Format in ein anderes Format mehr, bei einem anderen Format weniger. Du solltest nicht davon ausgehen, wenn Du alle Videos in das gleiche Video-Format z.B. in AVI und einer bestimmten Auflösung konvertieren lässt, dass der Hash-Wert dann identisch sein muss oder sein wird.

    Ich möchte dir jetzt in keinerlei Form zu nahe treten, aber ich denke ich habe mit keinem Wort erwähnt, dass der Videovergleich nach der Konvertierung ausschließlich über eine Hash-Wertbildung vollziehen möchte.
    Vielleicht lassen sich ja ähnliche Muster wie bei der Bewegungserkennung nutzen!?
    Ich bin hierbei noch vollkommen offen, und habe mich auch noch nicht auf ein bestimmte Strategie festgelegt. Das ist jetzt erst einmal die Erkenntnisgewinnphase ;)

    es grüßt euer
    Willy

  • Guten Morgen,

    Hiermit melde ich mich mal wieder mit einem Zwischenbericht zurück.

    Bei dem nun zweite Durchlauf, welcher auch wieder über Nacht gelaufen ist, hat mir mein Python- Programm eine ganz tolle Ausgabedatei angelegt. :bravo2:

    Zu meinem großen Erstaunen, hat diese Hash- und Größenvergleichs Analyse hervorgebracht, das auf dieser Platte über 15.000 doppelte oder mehrfach vorhandene Dateien gefunden wurden. :gk1:

    Jetzt werde ich erst einmal schauen, was davon alles Videofiles sind, und ob diese bei der Video Ausgabe wirklich identisch sind.

    Das sich auf einer Platte dieser Größenordnung mit über 8.000 Ordnern und Unterordnern ein solches Datenchaos anrichten lassen kann, hätte ich auch nicht gedacht. ||

    Dennoch bin ich für weitere Input aus #26 dankbar. :danke_ATDE:
    Dieses "erschreckende"Ergebnis ist wohl auch die Ursache, dass dieses komische "rdfind", wenn es mal eine Meldung ausgegeben hat, falls mal die Übergabeparameter zufälliger Weise in der richtigen Reihenfolge angegeben waren immer wieder die Meldung ausgespuckt hat, dass das zu analysierende Datenvolumen über 2 TB betragen würde, und es nicht alle Duplikate gefunden hat. :!::?:

    es grüßt euer
    Willy

  • Zu meinem großen Erstaunen, hat diese Hash- und Größenvergleichs Analyse hervorgebracht, das auf dieser Platte über 15.000 doppelte oder mehrfach vorhandene Dateien gefunden wurden. :gk1:

    An dieser Stelle würde ich mit dem Ausmisten beginnen und die 1:1-Duplikate (halbwegs automatisiert) löschen, indem Du die Logdatei aus Deinem Programm in ein Shellskript umeditierst, à la

    Bash
    rm /pfad/zu/datei1.mp4
    rm /pfad/zu/datei2.avi
    .
    .
    .
    # anschließend Löschen von leeren Verzeichnissen

    Mit etwas Glück wird der Verzeichnisbaum damit erheblich zurückgeschnitten und die Anzahl der übrigen Dateien wird überschaubar?

    -- WICHTIG --

    Eine Sicherungskopie unterstelle ich an dieser Stelle mal.

  • Guten Morgen,

    An dieser Stelle würde ich mit dem Ausmisten beginnen und die 1:1-Duplikate (halbwegs automatisiert) löschen, indem Du die Logdatei aus Deinem Programm in ein Shellskript umeditierst, à la

    Wenn ich mit dem manuellen Vergleich durch bin, 100% Vertrauen habe ich noch nicht ;):angel:
    werde ich noch eine Funktion anfügen, die Anhand der Dateiendungen gleich mit os.remove() alle Dateien wegputzt, die nicht im "Records" Verzeichnis liegen. Da muss ich nicht erst noch ein Shell-Script schreiben 8o Die anderen Dateien interessieren mich erst einmal nicht, denn irgendwann vor Weihnachten soll auch noch das Filmchen zum 23 Jährigen Bestehen unseres Verkehrsgartens fertig werden.

    Nur wie passe ich jetzt die Suchroutine an, oder erstelle eine neue, und das alles in Python, um leere Ordner und Unterordner zu finden, und diese auch gleich zu löschen ? :helpnew:

    EDIT: Hat jemand Ahnung was *.cgi Dateien sind ? Ich habe gemäß der Liste knappe 3.000 solcher Dateien, alle nur zwischen ca. 300k und 1.2MB groß. Anhand des Verzeichnis Namens komme ich nicht drauf wofür die gut sind. Der Texteditor zeigt mir nur irgendwelchen Zeichenmüll an, und wenn ich über MC in der HEX Ansicht F3 reinschaue bin ich genauso schlau wie vorneweg

    es grüßt euer
    Willy

    Einmal editiert, zuletzt von WillyR_aus_C (28. August 2022 um 08:06)

  • Guten Tag,

    Siehe hier: https://www.dateiendung.com/format/cgi und hier: https://datei.wiki/extension/cgi

    Gehören anscheinend zu Webservern bzw Webseiten.

    Interpretiere ich jetzt die erläuternden Ausführungen deiner Links falsch, wenn dort geschrieben steht, dass es sich um Scipt-Dateien handelt -> dann müsste man sie och als Script auch im Klartext lesen können - ähnlich wie Shell-Scripte, oder jeder andere nicht compilierte Programmcode ?
    Das ist nur Zeichenkaderwelsch, wenn ich mit oder über den MC drauf- oder reinschaue ?

    es grüßt euer
    Willy

  • Es sind (vor) compilierte Scripte , steht doch aus so in beiden Artikelen, ziemlich am Ende jeweils.

    Werden anscheinend auch bei Besuch von Webseiten automatisch geladen und gespeichert um Aktionen im Client Browser ausführen zu können.

    Ansonsten: Keine Ahnung.

  • Guten Tag,

    Was sagt denn file <filename>.cgi dazu?

    raw G3 (Group 3) FAX ist die Ausgabe jetzt mal bei einer willkürlich herausgegriffenen cgi-Datei.

    :gk1::conf:
    Braucht man das möglicher Weise bei einem Windows-Programm, welches zur Erstellung, oder Konvertierung der Videos genutzt wurde ?
    Ich sollte wohl noch sagen, das die Videos in dem Aufnahme Ordner Records aus sehr unterschiedlichen Zeiten stammen. Einige machen den Eindruck, dass das Original mal ein alter Zellulloid-Film war. Ich bin auch nicht von Anfang an dabei gewesen, und erst später dazu gestoßen. So das ich auch keine wirklichen Aussagen machen könnte, woher, oder wie die Filme der ersten Jahre im Original gemacht wurden.

    es grüßt euer
    Willy

  • raw G3 (Group 3) FAX ist die Ausgabe j

    Das klingt ebenso daneben wie das Common Gateway Interface (CGI).

    Evtl. mal an anderen Files nachsehen, scheint mir aber eher eine willkürlich benutzte Extension irgendeiner alten Software zu sein.

    Wenn du nichts zu sagen hast, sag einfach nichts.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!