Hash Wert der richtige Weg ?

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

    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.

    Auf Grund deines Hinweises habe ich mal eine Suche nach *.htm / *html Dateien gemacht. Nichts der gleichen wurde gefunden.

    es grüßt euer
    Willy

  • Guten Tag,

    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.

    Ich bin mal deiner Aufforderung gefolgt, und habe Ausgabeliste automatisiert via subprocess.run file <path>/<filename>.cgi und einer Vorfilterung auf cgi Dateien laufen lassen.
    Es gibt einige wenige Meldungen, die anders sind, aber so schnell kann ich auch nicht lesen ;) Dennoch der größte Teil bringt diese "raw G3 (Group 3) FAX" zur Anzeige.

    es grüßt euer
    Willy

  • Hallo Willy,

    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

    Normalerweise steht CGI für Common Gateway Interfaces. Diese dien(t)en in den 90ern dazu, Anwender-EIngaben serverseitig zu verarbeiten. Normalerweise handelt es sich dabei um menschenlesbare Script-Dateien. Diese können aber auch compilierte Programme enthalten - und enthalten dann eben nicht vollständig menschenlesbaren Inhalt

    CGI-Scripte werden als recht unsicher eingestuft, da Du nicht weißt, was dort wirklich gemacht wird.

    In Deinem Fall könnte CGI auch Computer Generated Imagery bedeuten, also Bild- und Video-Inhalte.


    Beste Grüße

    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 Tag,

    In Deinem Fall könnte CGI auch Computer Generated Imagery bedeuten, also Bild- und Video-Inhalte.

    Könnten das somit auch Bild- oder Animationselemente sein, die in den schon bearbeiteten Videosequenzen z.B. als Einblendungen und irgendwelche Laufschriften genutzt wurden / werden. Hier aber noch in einem Roh- oder Containerformat, irgendeines Video-Schnittprogramms vorliegen ?
    Wenn diese Bildeinblendung in der fertigen Video-Datei vorhanden ist, müsste man die doch gefahren los löschen können ? Oder sollte ich diese Dateien lieber unangetastet lassen ?

    es grüßt euer
    Willy

  • Hallo,

    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:

    Teste mal (deinen Pafad anpassen):

    Es müssten alle Unterverzeichnisse durchsucht werden.

    Grüße

    Dennis

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

  • Guten tag Dennis89

    Danke für den Code, zum Probieren ich noch nicht gekommen. Aber dafür habe ich in der nächsten Erweiterung ein neues Problem.

    var1, var2 = Textzeile.split(':') 

    Hier kommt jetzt leider ein Fehler, den ich so auch noch nicht auf dem Schirm hatte, dummer Weise enthalten einige Dateinamen auch einen Doppelpunkt.
    Der Fehler lautet ValueError: too many values to unpack (expected 2)
    Wie kann ich dem Split beibringen das er nach dem ersten Fund von ':' aufhören soll den String weiter zu zerstückeln ?

    es grüßt euer
    Willy

  • Hallo,

    dummer Weise enthalten einige Dateinamen auch einen Doppelpunkt

    hast du mal ein Beispiel wie der Dateiennamen aussieht und welchen Teil du daraus für den weiteren Programmablauf brauchst?

    Eigentlich behandelt man Pfade und/oder Teile daraus nicht als String sondern als Path-Objekt. Eventuell kann man dein Problem damit einfacher lösen.

    Ansonsten ....split(':', 1) siehe:

    https://docs.python.org/3/library/stdtypes.html#str.split

    Grüße

    Dennis

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

  • Guten Abend, Dennis89

    hast du mal ein Beispiel wie der Dateiennamen aussieht und welchen Teil du daraus für den weiteren Programmablauf brauchst?

    Ich habe jetzt erste deinen Löschcode als Teil auf einen unkritischen Teil der Verzeichnisstruktur angesetzt ;)   :danke_ATDE:
    Bezüglich der STRING Sache, ja, das ist so weil mir sonst das PI auch wieder aussteigt, habe ich die Suchroutine dahingehend schon im vorherigen Durchlauf abgeändert, dass er mit eine TXT Datei mit dem DatenFormat [<HASH-String>:<Pfad+Filename>],'\t','<Filegröße>','\t','<Dateiendung>','\n'schreibt. Damit kann ich nun auch nicht nur die cgi Dateien aussortieren, sondern bei der Erstellung der Double-Liste mich auf die Videodateiformate beschränken. Deswegen ist das leider ein STRING ;)
    Der Split('\n') und Split('\t') zuvor funktioniert ja einwandfrei. Nur ist jetzt nach einigen Stunden Rechenarbeit das Programm ausgestiegen.
    Damit will ich mich jetzt erst einmal im Kern auf die Video-Files und die offensichtlich Sinnlosen CGI Dateien beschränken. Zudem leere Ordner löschen, und dann werde ich mich mal mit dem Vorschlag von @DeaD_EyE beschäftigen, diesen Videovergleich durchzuführen.

    :danke_ATDE::danke_ATDE::danke_ATDE:

    es grüßt euer
    Willy

  • Guten Morgen,

    Und wieder möchte ich euch mit einem Zwischenbericht erfreuen.
    Die ganzen CGI-Datei sind radikal weggeputzt :bravo2:
    Das Löschen der leeren Ordner als Unterordner funktioniert wohl doch nicht so ganz - Ursache muss ich noch ermitteln.
    Ich habe nun ein gefilterte Liste, die mir aber erst im dreifach-Abgleich brauchbare Werte liefert.
    Nur wenn sowohl der Hash-Wert, die Größe und die Dateiendung stimmt, kann man sich wirklich auf diese Gleichheitsermittlung verlassen.
    In der Vorsortierungsliste ist mir aufgefallen wenn man nur nach den HASH-Werten schaut, dass es auch Dateien deren HASH Werte identisch sind, obwohl sie eine ganz andere Größe, wie auch einen ganz andere Dateiendung haben. :gk1:

    Was mir hier besonders aufgefallen ist, dass besonders der Dateityp MPG davon betroffen ist. Ich habe hier ein Liste nun aus dem dreifachen Vergleich, wo besonders viel solche Videofiles alle in diesem Format, den gleichen HASH wert haben, zum Teil nur wenige Byte, bis einige KByte groß sind, aber bei Vergleich in der Wiedergabe offensichtlich fast den selben Inhalt haben !? :conf:
    Kann es sein das dieser MD5 Hash nicht besonders gut geeignet ist, solche Dateien, mit solchen Größen miteinander zu vergleichen ?
    Meine Frage hat jetzt den Hintergrund, dass ich mich ab heute Nachmittag mit

    Bezüglich Videos-Hashen gibt es auch ein Python-Modul: https://pypi.org/project/videohash/

    beschäftigen möchte, und mir dann wahrscheinlich einige Dinge durch die Lappen gehen werden, obwohl das ganze mit sehr viel Rechenaufwand betrachtet wurde.
    Wenn ich jetzt alles auf Grund dieser Erkenntnis Hash- und Dateieindungs gleichen Dateien beackere, wird er diese ähnlich bis gleichen MPG Files nicht finden, weil sie nicht über den Vorsortierfilter als ähnlich erkannt wurden.
    Gibt es jetzt noch eine weitere Möglichkeit, ohne ein PLAY zu starten, mit einem einfachen "Irgendwas" schon während der HASH einer solchen Datei ermittelt wurde, noch sozusagen als Nebenfunktion herauszubekommen, welche Wiedergabelänge im Fall eines Videofiles, sowie die tatsächliche 1:1 Darstellungsauflösung dieses Video hat ?

    Irgendwie verfolge ich jetzt noch den Hintergrundgedanken durch einen bessere Vorfilterung die Anzahl der Dateien zu Reduzieren, ich ich mit dem VIDEO-HASH beackern lassen müsste.
    Kennt sich dazu jemand aus, wie man schnell und einfach mit einer Bibliothek ohne erst die Videodatei in einen Player laden zu müssen, einfach nur die Abspiellänge, und das Bildschirm- die Auflösung/- Format zu ermitteln. Die Unterschiede in den Tonspuren sind wohl nicht so relevant, weil einen wirklichen Stereo Ton wird es bei zT solch alten Aufnahmen nicht geben !?

    Ich danke wieder allen für die bisher eingebrachten Ideen und Vorschläge :danke_ATDE:

    es grüßt euer
    Willy

  • Was mir hier besonders aufgefallen ist, dass besonders der Dateityp MPG davon betroffen ist. Ich habe hier ein Liste nun aus dem dreifachen Vergleich, wo besonders viel solche Videofiles alle in diesem Format, den gleichen HASH wert haben, zum Teil nur wenige Byte, bis einige KByte groß sind, aber bei Vergleich in der Wiedergabe offensichtlich fast den selben Inhalt haben !? :conf:

    Kann es sein, dass es sich bei den Dateien, die nur aus wenigen Bytes bestehen, um Links auf größere Dateien handelt? Ein Video, selbst ein kurzes mit geringer Auflösung ist sofort im höheren kByte-Bereich.

    Wenn es symbolische Links sind, dann musst Du aufpassen, dass der Link gelöscht wird und nicht die tatsächliche Videodatei. Und ja, symbolische Links gibt's auch in Windows bis runter zum Dateisystem VFAT: Es sind die sogenannten Verknüpfungen.

    MD5-Prüfsumme oder andere Hashalgorithmen:

    Ihnen allen gemeinsam ist, dass nur ein exakt gleicher Inhalt zum gleichen Hashwert führt. Ändert sich auch nur ein Bit in nur einem Byte der zu hashenden Datei, liefert ein (guter) Hashalgorithmus einen vollkommen anderen Hashwert. Dass Dateien unterschiedlicher Größe den gleichen Hashwert liefern, ist bei ausreichender Bitbreite des Hashalgorithmus praktisch unmöglich. (Auch wenn Google es vor ein paar Jahren geschaft hat, sogar SHA1 zu knacken, indem es zwei PDFs mit unterschiedlichem Inhalt, rotes und blaues Rechteck, so manipuliert hat, dass der gleiche Hashwert herauskommt: Es wurden unter relativ hohem Rechenaufwand entsprechende Füllbytes in beide PDFs eingefügt, so dass am Ende der Hashwert beider Dateien gleich war)

    Grundsätzlich sind für mein Dafürhalten zur Videoprüfung auf Ähnlichkeit ganz andere Algorithmen heranzuziehen. Selbst die (verlustfreie) Umwandlung in ein anderes Videoformat bedingt aus obigen Gründen abweichende Hashwerte. Das Hashen taugt nur zum Vorsortieren und Eliminieren von Duplikaten.

    EDIT1:
    Gut, den Videohash kenne ich jetzt nicht, aber ich schätze, dass sich auch der die Zähne ausbeißt, spätestens wenn sich die Videoauflösung ändert. Im Wesentlichen bleibe ich bei meiner persönlichen Einschätzung aus Beitrag #27.

    EDIT2:
    Beinhalten die Videodateien Metadaten? Dann könnte man die extrahieren und vergleichen...

    Bei den alten Dateien aus ursprünglich analogem Material sind die Metadaten wahrscheinlich leer oder immer gleich.

    EDIT3:
    noch eine Idee:

    Die Länge der Videos ermitteln und alle Dateien ausspucken, deren Länge sich um weniger als 2(?) oder 5(?) Sekunden unterscheidet

  • Guten Tag,

    Kann es sein, dass es sich bei den Dateien, die nur aus wenigen Bytes bestehen, um Links auf größere Dateien handelt? Ein Video, selbst ein kurzes mit geringer Auflösung ist sofort im höheren kByte-Bereich.

    Nein, definitiv nein, dass sind alles echte MPEG, oder MPG Dateien, die auch einzeln auf einen USB Stick kopiert, auf einem anderen System wiedergegeben werden können. Alle so im oberen 2 stelligen MB Bereich bis knapp 250MB ! Damit scheidet wohl der Verdacht LINK aus !?

    Wie soll ich das beschreiben ? Wenn ich die Größe der Dateien über os.path.getsize() bestimme bekomme ich nur eine Abweichung von wenigen Bytes. Die MD5 Hashsumme ist mit dem Verfahren nach #23 die gleiche / identische. Wo es Abweichungen gibt, ist die Abspiellänge jetzt über VLC betrachtet und zudem Minimal in der Darstellungsauflösung. So wie es mir die Codec Ansicht verrät. Ich gehe mal davon aus, dass irgendwer zuvor versucht hat, diese Sequenzen in der Größe an eine andere Videoauflösung anzupassen, damit diese Zusammengeschnitten werden können. In den Metadaten sind nur Created by < Irgendwas > zu finden, wenn überhaupt vorhanden. Das sind alles nur so kurze 3 bis 8 Minuten Sequenzen, aber auch unterschiedlichen Alters. Deswegen habe ich schon angefangen mit dem anderen Verfahren erst Versuche gemacht, leider alle sehr Zeitraubend, und noch bin ich nicht dahinter gekommen, wie man die Ähnlichkeit anpasst . Wirkliche Duplikate findet das Verfahren auch nur, wenn die Dateiendung die gleiche ist. Ansonsten wenn es eine Kopie mit Formatwandlung ist, erkennt er das auch nicht als Duplikat an, zumindest bis jetzt noch nicht.

    Bis jetzt bin ich erst soweit, nur wenn das Dateformat das gleiche ist, die Dateigröße auch die Gleiche ist, und die Hash Summe identisch ist, sind es echte Duplikate. Formatübergreifend funktioniert mit dem reinen HASH ohnehin nicht, und mit der Videovergleichsmethode bis ich erst soweit, dass es erst einmal eine Bestätigung der 3-fach Sortierung ist. Dadurch, dass es ohnehin ein Merkmal, die Dateigröße gibt, fallen die auch nicht in das Muster und werden auch nicht automatisch gelöscht. Ich konnte jetzt auch noch keinen wirklichen allgemein gültigen Zusammenhang finden, dass alle Videos egal in welchem Format vorliegend und in einem Unterordner abgelegt, auch in der gleichen Auflösung vorliegen. Es ist einfach nur ein Datenchaos was viele Personen und jeder nur für sich angerichtet hat.

    es grüßt euer
    Willy

    1. kannte ich auch nicht, funktioniert aber. Weil es mich interessiert hat, habe ich mal mit OBS meinen Bildschirm
      aufgenommen.
      1. OBS: Video mit h264 1920x1080
      2. avidemux: dann umgewandelt nach h265, 2 Durchläufe mit Begrenzung auf 2 MiB
      3. dann umgewandelt nach h264 inklusive Halbierung der Auflösung.
    2. Metadaten können als Anhaltspunkt dienen. Oftmals fehlen die Metadaten aber auch.
    3. Das könnt für viele falsche positive Treffer sorgen

    Macht man hingegen der Vergleich mit dem Operator ==, bekommt man falsche Treffer.

    Zum Vergleich wird die Hamming-Distanz verwendet. Damit kann man z.B. nicht rotierte Videos erkennnen, aber sehr wohl Videos, die in der Auflösung reduziert sind. Es wird jede Sekunde ein Bild vom Video gemacht (144x144 pixel) und aus den Bildern wird dann der Hash gebildet.

  • Guten Tag,

    Macht man hingegen der Vergleich mit dem Operator ==, bekommt man falsche Treffer.

    Dann wird das wohl der Fehler sein, weswegen ich nicht weiter komme. :bravo2:

    from itertools import combinations_with_replacement

    Ist dann wohl die Lösung, die ich jetzt auch gleich mal ausprobieren werde.

    Könntest du mir jetzt noch einen Tipp geben, wie ich das jetzt mit nur 2 Dateien machen, oder gleich Listen machen könnte ? Dass ich gezielt die jeweilig vorsortierten Dateien nur mit den Dateien vergleichen lassen kann die sich in diesem Records Ordner befinden ?
    Ich habe somit, weil ich nicht weiß, wie ich die reale Videolänge über Python ermitteln kann, 2 Listen. Einmal die Dateiliste aus dem Records Ordner, und dann die Liste die mir die Hash und Größen Vorsortierung ausspuckt. Mir fehlt jetzt die Idee das auf die gesamte Ansammlung aller Videodateien anzuwenden :conf:
    :danke_ATDE: @DeaD_EyE Du bist mir wirklich eine sehr große Hilfe. Ich sehe langsam Licht am Ende des Tunnels :danke_ATDE:

    es grüßt euer
    Willy

  • Python
    from itertools import combinations_with_replacement

    Ist dann wohl die Lösung, die ich jetzt auch gleich mal ausprobieren werde.

    Ein paar Anhaltspunkte zum Hamming-Abstand:

    • Der Hamming-Abstand gibt an, wie viele Bits sich von Wert A und B unterscheiden.
    • Der Hamming-Abstand ist symmetrisch. D.h. VideoHash1 - VideoHash2 == VideoHash2 - VideoHash1
    • Man kann die VideoHash-Objekte subtrahieren, dass dann den Hamming-Abstand ergibt.
    • Bei einem Hamming-Abstand von 0 gibt es keine Unterschiede der erfassten Frames (1 Bild pro Sekunde).

    Die Methode is_similar berechnet zuerst den Hamming-Abstand und wenn weniger oder gleich 15 % der Bits unterschiedlich sind, ist es ein positiver Treffer. Dann sind die Videos sehr wahrscheinlich mit dem gleichen Inhalt. 15 % ist der Standard-Wert bei VideoHash und kann mit dem Attribut similar_percentage zugewiesen werden.

    Ich denke, dass es sinnvoll ist zuerst kurze Videos zu testen und ich würde da folgendermaßen vorgehen:

    1. Zuerst die langsame Arbeit: Videos hashen und die Hash-Werte zuerst einmal abspeichern. Ob in einer Datenbank, Textdatei oder sonst wo, spielt keine Rolle. An die Hash-Strings der VideoHash-Objekte kommt man über das Attribut hash_hex (ist ein str).
    2. Vergleich der zuvor aufgezeichneten hex_str.

    Würdest du einfach anfangen mittels Kombinatorik alle Dateien zu hashen, wäre ein Programmierfehler fatal (dauert lange & Ergebnis verloren). Auch würden dann wiederholt Dateien mehrfach gehasht.

    Langsame Arbeit (Code musst du ergänzen):

    Python
    from videohash import VideoHash
    
    
    def calculate_videohash(file):
        """
        VideoHash berechnen. Kann sehr lange dauern.
        """
        return VideoHash(file).hash_hex


    Wenn du dann später ein paar Hash-Werte hast, musst du aus den Resultaten mittels der Kombination (ohne Wiederholungen) immer 2 Werte vergleichen. Bei 180 Video-Dateien wären das dann 16110 Kombinationen (math.comb(180, 2) oder 180!). Permutation ist nicht zu gebrauchen, da man immer nur 2 Werte vergleichen kann und nicht alle auf einmal in unterschiedlicher Reihenfolge.

    Pro Vergleich wird ein Hamming-Abstand berechnet und man hat die zwei Dateien, die miteinander vergleichen worden sind. Negative Ergebnisse, können verworfen werden (minimaler Hamming-Abstand überschritten). Der VideoHash ist bei mir 64 Bit. Bei 15 % wären das dann 10.

    Python
    from itertools import combinations
    
    
    videos_to_compare = list(combinations(Path("Downloads/Telegram Desktop/").rglob("*.mp4"), r=2))

    Bei dir sind die Hash-Werte und Pfade ja in einer Datei/Datenbank. Verliere auch die Konzentration und muss mal Pause machen.

    Hier die Funktion, um den Hamming-Abstand zu berechnen:

    Ich hab bei VideoHash keine einfache Funktion gefunden.

  • Guten Morgen @DeaD_EyE,


    Ich hangele mich in meinen Programm rekursiv ( so heißt das doch wohl ) von dem angegebenen Startverzeichnis vor. In dem ich eine Inhaltsliste mache, die aufsplitte in Verzeichnisse und Dateien.
    Dann geht es immer wieder selbstaufrufend weiter, immer nach dem selben Schema, solange noch Unterverzeichnisse gefunden werden, der nächste Selbstaufruf. Wenn kein weiteres Unterverzeichnis gefunden wurde, also nur noch Dateien, dann werden diese mit der von dir gennannten MD-Hash-Bildung beackert, bis auch diese Dateiliste im rekursiven Funktionsaufruf durchgeackert ist. Dann erfolgt der Rücksprung, bis ich dann mal durch bin. Das passiert ohnehin. Somit habe ich in einer Datenbank sowohl den vollständigen Dateinamen inkl. der absoluten Pfadangabe, den MD5 Hach, die Dateiendung und die Dateigröße.
    Ich weiß aber auch jetzt schon das die eigentlichen gesampleten Originale alle in dem Ordner "Recorrds" liegen.
    Dank dieser Liste konnte ich schon die CGI Dateien ausfindig machen und löschen., und konnte ermitteln, dass es sich nur um "MPEG" ( Ja mit 4 Buchstaben ), "MPG", "AVI", und "MP4" Dateien handelt. Wenn ich jetzt auf eine solche Datei stoße, egal wo, kann ich doch schon theoretisch diesen 64 BIT VIDEOHASH bilden lassen ? So wie du es in der ersten langsamen Methode beschrieben hast. Gemacht muss es doch eh werden ? oder ?
    Also bräuchte ich dann nun noch so meine Annahme, in diese Datenbank schauen, und jedes Vorkommen einer Videodatei aus den übrigen Ordnern mit den VideoHASH-Werten des Records-Ordner nach der !? Ja wie nun vergleichen. Für alles was in diesem Records Ordner ist, wird ohnehin eine zweite kleinere Datenbank angelegt.
    Oder bin ich da auf dem Holzweg ?
    Ich kann auch noch eine LIST entstehen lassen wo nur die VideoHASH Werte drin sind, die aus dem Records Ordner stammen. Hier ist die absolute Pfadangabe und der Dateiname völlig unrelavant, weil hier darf ja nichts gelöscht werden ?

    Oder hättest du jetzt noch einen besseren / anderen Vorschlag ? Zeit in dem Sinne spielt erst einmal keine Rolle.
    Mir würde jetzt erst einmal die Aussage langen, bevor ich eine automatische Löschroutine ergänze die Video-Ähnlichkeit liegt bei 10-20 % und die Abspiellänge ist bis auf +/- 5 oder 10 am Anfang und Ende die gleich.
    Manchmal sind es nur wenige Sekunden die am Anfang und Ende fehlen. Zumindest wenn man sich vergleichend die Videos über den VLC anschaut.

    Wieder ein dickes LOB und :danke_ATDE:

    es grüßt euer
    Willy

  • Guten Morgen,

    So wie soll ich sagen, das Werk ist vollbracht.
    Mein PI hat es geschafft :bravo2:
    Die Methode von @DeaD_EyE und dem VideoHash ist durch.
    Ich habe jedoch weil es doch nicht anders ging, alle Videofiles in den anderen Ordnern und Unterordnern, mit den Videofiles in dem Records Ordner vergleichen lassen.
    Basierend auf dem Vergleich dieser Werte konnte ich nun offensichtlich alle Videodateien ausfindig machen, die Inhaltsgleich /-ähnlich sind, auch wenn dieser inzwischen Format- oder Auflösungs-konvertiert wurden.
    Es hat zwar gedauert, aber in Anbetracht der schlichten Menge dieser Dateien ging das immer noch schneller als wenn ich mir jedes Filmchen einzeln angesehen hätte.
    Ich setzte das Thema damit auf erledigt und bedanke mich noch einmal für diese tolle Unterstützung aller :danke_ATDE:

    es grüßt euer
    Willy

Jetzt mitmachen!

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