Beiträge von Welm

  • Repo verschwunden

    Es ist ja das ganze Verzeichnis weg und nicht nur die RPMs darin. Sieht irgendwie mehr nach Absicht als nach Bug aus. Ich dachte, vielleicht hat jemand was von Problemen auf dem Gebiet gehört ... z.B. sowas wie "log4j-Probleme mit 15.3 und das Verzeichnis wird sicherheitshalber bis zur Lösung entfernt".

  • Repo verschwunden

    Ich verstehe nicht, wieso ein Wohnungseinrichtungsprogramm wie SweetHome3D oder ein Bankingprogramm wie Hibiscus davon betroffen sind. Und wieso das in Tumbleweed anders ist als in 15.3.

  • Gwenview frisst Speicher

    Zitat von matbhm

    Leider verstehe ich Deine Problembeschreibung und die Lösung aus Post #2 nicht :).

    Dann versuch ich mal, es anders zu beschreiben :)


    Gwenview hat beim Anzeigen von Bildern aus einem großen Verzeichnis massenweise RAM gebraucht ... mehr als da war.


    Es lag aber nicht an den vielen Bildern. Es waren einzelne dieser Bilder, die enorm RAM geschluckt haben. Die große Masse der Bilder war gar kein Problem. Es lag nicht an der Kamera oder am Motif, denn ich hatte zwei direkt nacheinander mit derselben Kamera aufgenommene Bilder von denen das eine problemlos war und das andere so ein RAM-Schlucker. Geprüft hab ich es dadurch, dass ich das "böse" Bild ein paar Mal in ein neues Verzeichnis kopiert habe und beim Betrachten mit gwenview waren sofort die 16GB weg und der Rechner fing an zu swappen. Ich hab dann erstmal andere Programme statt gwenview benutzt.


    Irgendwann hab ich dann doch noch die gemeinsame Eigenschaft dieser "bösen" Bilder gefunden. In einem JPEG kann ja zusätzlich ein kleines Vorschaubild gespeichert werden. Bei JPGs aus Canonkameras wird zusätzlich noch eingetragen, welchen Ausschnitt davon bei Vorschauen das Anzeigeprogramm nehmen soll. Da stand jetzt bei einem Vorschaubild von z.B. 200x300 Pixel dran: Nimm für die Vorschau Pixelspalte 10437 bis 45358 und die Pixelzeilen 3246 bis 61799. Diese Spalten- und Zeilennummern gibt es aber in dem 200x300 Vorschaubild nicht. Da dürften ja nur viel kleinere Zahlen vorkommen. Irgendwie ist gwenview dadurch total durcheinandergeraten.


    Ich hab dann mit exiftool die vier unsinnigen Zahlen alle durch 0 ersetzt. Das bedeutet, dass das ganze Vorschaubild genommen werden soll. Die Probleme waren dann weg.


    Mit der "Prüfung" soll nur sichergestellt werden, dass man nicht an Dateien herumbastelt, die gar kein Problem machen.


    Ich hab aber keine Ahnung woher diese fatalen Canon-Angaben kamen. Dass keiner geantwortet hat könnte ein Hinweise darauf sein, dass ich als einziger so doof war diese Tags kaputt zu machen ...

    Aber für den Fall, dass doch noch jemand das Problem bekommt, wollte ich doch gern eine Umgehungsstraße ausschildern :-))

  • Gwenview frisst Speicher

    Zitat von Welm

    ...es sind bestimmte Bilder...

    Die problematischen Bilder sind die mit unsinnigen Einträgen der Canon Maker Notes in "Thumbnail Image Valid Area". Damit gibt man augenscheinlich eigentlich einen Ausschnitt des Thumbnails für die Thumbnail-Anzeige an.


    Anzeige:

    exiftool -ThumbnailImageValidArea x.jpg


    falls da keine plausiblen Pixelkoordinaten stehen sondern lustige Werte zwischen 0 und 65535:


    Prüfung:

    -verdächtige Datei in ein neues Verzeichnis kopieren

    -dort vervielfältigen. z.B. "for I in {01..22}; do cp -a x.jpg pic$I; done"

    -KSysGuard oder ähnliches zur Überwachung des RAM-Verbrauchs anwerfen

    -dort "gwenview ." starten und mit der Hand über Control-C ggf. rechtzeitig abbrechen bevor die Kiste anfängt zu swappen.


    und ggf. Reparatur:

    exiftool -ThumbnailImageValidArea="0 0 0 0" x.jpg

    Letzteres bedeutet "nimm das ganze Thumbnail als Thumbnail".

  • Ich verstehe "akonadictl status | grep -i running" nicht...

    Zitat von der_rosi

    Tut es... und ich hab wieder was gelernt (weil ich diese Umleitung via status 2 nicht kannte

    Nur damit Du Dir nicht was Falsches merkst: "status 2" gibt es nicht. Die "2" gehört zum ">". ">" lenkt stdout in eine Datei. "2>" lenkt stderr in eine Datei. man kann z.B. auch Sachen schreiben wie

    Code
    befehl > ausgabe.txt 2> fehler.txt

    und hat dann stdout in der einen und stderr in der anderen Datei

  • Ich verstehe "akonadictl status | grep -i running" nicht...

    Zitat von der_rosi

    Da Umleitung ( akonadictl status > status.txt ) zum gleichen Ergebnis führt (leere Datei, Ausgabe in Bash), ist meine Vermutung, dass akonadictl irgendwie stout umgeht...

    Vielleicht schreibt er auf stderr statt stdout. Ich hab kein akonadictl und kann nur spekulieren.


    Falls es so ist würde

    Code
    akonadictl status 2> status.txt

    in die Datei schreiben.


    Falls es so ist könnte man in der grep-Zeile stderr auf stdout umlenken:

    Code
    (akonadictl status 2>&1)| grep -i running