media-autobuild_suite

  • Ich hab heute seit langem wieder mal einen 64bit-Komplettdurchlauf gemacht, hat mit einem i7, SSD und Win 8.1 4:15 gebraucht. Ist aber ohne Meckerei durchgelaufen und hat alles brav gebaut.


    Toll! Ich feire das! :daumen::daumen::daumen:




    Btw. weiß jemand, wie ich die Tools in "\msys64\usr\bin" statisch bekomme? Das wäre für mich eine große Hilfe.

  • :hm: Manchmal hasse ich ffmpeg...


    Win32 hat noch compiliert. Bevor die Win64-Runde losging, wurden die Quellen noch mal aktualisiert ... dadurch blieb die Win64-Compilierung stecken, weil libschroedinger nicht mehr unterstützt wird. Ab sofort. :rolleyes:


    Na ja, zum Glück ist wiiaboo wirklich fix, schon aktualisiert.


    Dennoch, ich glaube, zwischen Win32 und Win64 die Quellen noch mal zu updaten find ich suboptimal.

  • :wall:


    Mal wieder ein Update. 68 Dateien heruntergeladen, Abhängigkeiten werden überprüft ... tut mir Leid, geht nicht, python2-olefile kann nicht aktualisiert werden, weil ein Verzeichnis egg-info existiert.


    Tipp: pip uninstall olefile sowohl in mingw32 als auch mingw64 (beide blanke Shells) ausführen.


    Also gut, Shell geöffnet, Befehl ausgeführt. Es erscheint eine Liste, was deinstalliert werden soll.


    Und dann passiert nichts.


    0% CPU, 0 Bytes I/O. Prozess-Status: Wait:UserRequest :grübeln: was, soll ich 'Y' eingeben?


    Ja! :ja:


    Und dann fragt er: Proceed (y/n)? :rolleyes:


    Anscheinend wartet Python unter MinGW auf einen Flush.

  • Hat jemand ne Idee was man machen kann, bei mir bleibt ffmpeg bei 'Running configure' immer stecken.
    Gibt keinen Fortschritt auch nach 8+ Stunden. sh.exe erzeugt zwar dauernd cpu auslastung, aber das Teil wird nicht fertig.
    Hab schon mal den ffmpeg-git Ordner gelöscht, aber das hat auch nichts geändert.


    Cu Selur


    Ps.: würde sonst als nächstes mal alles im build-Ordner löschen, nicht nur den ffmpeg-git Ordner.
    PPs.: dieses mal ist er nach 1 1/2 Stunden von configure nach make gewechselt,... vielleicht passiert nach was,..
    -> okay, jetzt geht es wieder,... keine Ahnung warum es die letzten 3 Tage nicht ging.

  • Nach 24h ist er bei mir immer noch beim Kompilieren der 32bit tools, hab das Skript extra auf eine SSD gepackt und sowohl in Malwarebyte als auch im WindowsDefender den Ordner rausgenommen.
    -> keine Ahnung was sich geändert hat aber irgendwas hat sich entweder am Skript oder na meinem System geändert was dafür sorgt, dass das Kompilieren ewig dauert.
    Encoding und normales Kompilieren mit anderen Tools geht gewohnt flott nur media-autobuild_suite ist super lahm,....
    die .ini sieht eigentlich aus wie immer,...


    Cu Selur

  • Geh mal das Troubleshooting der README.md durch; manchmal muss man die INI (und evtl. Compiler-Options, falls du Textdateien verwendest) neu erzeugen lassen, manchmal muss es auch mal ein frisches MSYS2-64 sein (MSYS2-32, also Crosscompile auf einem 32b-Hostsystem, kannst du vergessen).

  • Irgendwas ist strange, habe das Ganze jetzt mal angehalten, als ich gesehen habe, das die CPU 6000 threads offen hat und 600 000 handle <- das sieht einfach falsch aus,...
    Rechner neugestartet, fdk-aac git Ordner gelöscht.
    fdk-aac wird momentan seit 30min kompiliert und der Handles count ist von initalen ca.60k auf momentan 105k gestiegen,... noch mal 10 min handles ist bei 110k,.. nach einer Stunde an ffk-aac sind es 126k handle,...
    Nach ca. 1 1/2 Stunden ist er jetzt fertig damit, aber die CPU handles gehen nicht runter sondern steigen munter weiter (145k+)
    -> Hat einer ne Idee was da so viele cpu handles braucht?
    Ich hatte die Cores schon von meinen früheren 16 auf 4 herunter gesetzt:


    Verwende hier Windows 10 64bit, 32GB RAM, Ryzen 7 1800X, nicht overclocked. (hab ihn normalerweise auf 4GHz Basis getacktet, im Turbo geht er dann auf 4.4 GHz hoch,..)

  • Ich habe überhaupt keine Ahnung. Aber mir erscheint nichts logischer als Bugs in MinGW oder GCC. Aber hier ist die Anzahl an Experten auf diesem Gebiet vermutlich eher überschaubar...


    Womit stellst du die Anzahl der Handles fest? Falls ProcessExplorer: Welchen Prozess müsste man dafür beobachten?

  • Am Ende liegt's noch an Windows 10? — Obwohl: "Handle Leaks" sind nicht völlig neu.


    Unter Windows 7 ist es auf zwei verschiedenen Rechnern anstandslos durchgelaufen. Allerdings verwende ich den ProcessExplorer, wer weiß, wie ich den zur Überwachung einstelle. "Performance - Handle Count" hat der auch als Tabellenspalte. Ich versuch's später damit noch mal.


    P.S.: Ah, warte, die verlinkte Anleitung hat extra ein Kapitel für den PE.


    Ansonsten, wie gesagt, hier findest du für diese Frage sicher nicht ausreichend Spezialisten.
    _


    So, anfangs läuft hier alles gesittet ab, mehr als ein paar Hundert Handles braucht bisher kein Shell- oder Compiler-Prozess.

  • He,he bei dem Microsoft Artikel bin ich auch gelandet.
    In Windows 10 kann man sich auch die handle der einzelnen Prozesse angucken (wenn man unter Details im TaskMgr die entsepechende Spalte aktiviert).
    -> lass das Skript mal wieder laufen und guck mir das Morgen früh oder Abend noch mal an.


    Cu Selur


    Ps.: Das Skript solle nur Dateien unterhalb des Hauptordners erstellen oder? (habe aktuell für den Hauptordner entsprechende Ausnahmen für Virenscanner&Co)