1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

Lumina-fm: Bitte einmel helfen und testen

Dieses Thema im Forum "FreeBSD - Anwendungen und Ports" wurde erstellt von SolarCatcher, 20 Januar 2017.

  1. SolarCatcher

    SolarCatcher Active Member

    Registriert seit:
    24 August 2006
    Beiträge:
    702
    Hallo,

    KURZVERSION:
    Wenn Du Lumina benutzt, probiere doch bitte einmal folgendes. Lege einige hundert (leere) Dateien in einem Verzeichnis an und schau, wie dann die Performance des Lumina File Managers ist - bei mir ist sie unterirdisch. Hier ein Skript mit dem Du 1500 leere Text-Dateien unter /tmp/testdir anlegen kannst:

    Code:
    #!/bin/sh
    mkdir /tmp/testdir
    i=1000
    while [ $i -lt 2500 ]
    do
        touch /tmp/testdir/$i.txt
        i=`expr $i + 1`
    done;
    
    HINTERGRUND:
    ich nutze seit einem 3/4 Jahr den Lumina Desktop und bin recht zufrieden damit. Allerdings habe ich schon seit langem ein Performance Problem mit lumina-fm. In Verzeichnissen mit vielen Dateien braucht er schon für das Anzeigen mehrere Sekunden, eine Datei-Änderung (Umbennenen, Löschen) dauert dann sogar bis zu 50 Sekunden und fast nochmal so lange, bis der File Manager bei mir wieder benutzbar ist.

    Ich habe seit einigen Tagen mit den Entwicklern versucht, den Fehler einzugrenzen - aber sie können es auf ihren Systemen nicht reproduzieren. Ich nutze Standard FreeBSD 11.0-RELEASE auf einem ca. 4 Jahre alten T530 mit i7 und 8GB RAM. Da darf eine Umbenennung einfach nicht mehrere Sekunden dauern. Auf der Command Line und im zum Vergleich einmal getesteten PCManFM (aus dem LXDE) geht es - wie man es erwarten würde - ruckzuck. Ich habe auch ein unverschlüsseltes UFS-Dateisystem ausprobiert (um auszuschließen, dass es mit dem geli-verschlüsselten ZFS zu tun hat) - aber dort das gleiche Problem.

    Falls jemand einmal testen kann, wäre ich dankbar, wenn Ihr hier Eure Erfahrung zurückmelden könntet. Ich wüsste gerne, ob ich irgend ein seltsamer Einzelfall bin, oder ob andere auch das Problem haben. Das würde auch den Entwicklern helfen.
     
  2. sterum

    sterum Member

    Registriert seit:
    17 Februar 2009
    Beiträge:
    501
    Kann ich bestätigen. Bei mir zeigen sich die gleichen Probleme.
    11.0-RELEASE, i7 2700K, 16GB RAM, ZFS auf einer HDD.

    [edit] im Terminal bekomme ich während z.B. dem Umbenennen von Dateien folgende Meldung: QCoreApplication::postEvent: Unexpected null receiver [/edit]
     
  3. peterle

    peterle Forenkasper

    Registriert seit:
    19 August 2006
    Beiträge:
    1.752
    Ort:
    Aachen
    Zumindest scheint die Fehlermeldung sich nicht ernst zu nehmen. ;)

    https://github.com/thoughtbot/capybara-webkit/issues/39
    Klingt aber irgendwie nach "hätte man besser machen können ..."
     
  4. SolarCatcher

    SolarCatcher Active Member

    Registriert seit:
    24 August 2006
    Beiträge:
    702
    Danke, @sterum ! Das ist schon einmal sehr interessant - das dürft dann auch für (noch) mehr Aufmerksamkeit bei den Entwicklern sorgen.

    Die Fehlermeldung, die Du siehst, sei lediglich "kostmetisch", hatten auch die Lumina-Entwickler an anderer Stelle gemeint.
     
  5. sterum

    sterum Member

    Registriert seit:
    17 Februar 2009
    Beiträge:
    501
    Ich kann nicht beurteilen ob das nur kosmetischer Natur ist. Jedenfalls tritt während dem Umbenennen diese Meldung auf meinem System etwa 9000 Mal auf.

    So sehr ich die Idee hinter dem Lumina Projekt mag, aber dieses "hätte man besser machen können" zieht sich meiner Meinung nach durch das ganze Projekt.
     
  6. Rakor

    Rakor Moderator Mitarbeiter

    Registriert seit:
    17 September 2009
    Beiträge:
    2.004
    Ort:
    Mannheim
    Das sehe ich leider bei PC-BSD (oder wie es heute heißen mag) an vielen Stellen.
     
    CrimsonKing gefällt das.
  7. peterle

    peterle Forenkasper

    Registriert seit:
    19 August 2006
    Beiträge:
    1.752
    Ort:
    Aachen
    Ich habe mir vor ein paar Tagen mal "lumina-1.2.0.p1,2 Lumina Desktop Environment" installiert und empfinde dasselbe Problem, was hier beschrieben wird.
    Beim Öffnen eines Verzeichnisses mit "vielen" Dateien, kann ich mir in Ruhe eine Pfeife stopfen und beim Wechseln in ein ähnliches Verzeichnis anzünden ...
     
  8. peterle

    peterle Forenkasper

    Registriert seit:
    19 August 2006
    Beiträge:
    1.752
    Ort:
    Aachen
    Nun gibt es

    Code:
    ==> pkg info |grep lumina
    lumina-1.3.0,3  Lumina Desktop Environment (meta-port)
    lumina-archiver-1.3.0.p1  Archive manager from the Lumina Desktop
    lumina-calculator-1.3.0.p1  Scientific calculator from the Lumina Desktop
    lumina-core-1.3.0.p1  Lumina Desktop Environment
    lumina-coreutils-1.3.0.p1  Lumina Desktop Environment
    lumina-fileinfo-1.3.0.p1  File properties utility from the Lumina Desktop
    lumina-fm-1.3.0.p1  Insight file manager from the Lumina Desktop
    lumina-mediaplayer-1.3.0.p1  Streaming media player from the Lumina Desktop
    lumina-screenshot-1.3.0.p1  Screenshot utility from the Lumina Desktop
    lumina-textedit-1.3.0.p1  Plaintext editor from the Lumina Desktop
    lumina-xdg-entry-1.3.0.p1  XDG desktop entry creator from the Lumina Desktop
    
    und die Probleme sind nicht mehr vorhanden. Wo er vorher ewig brauchte, ist es jetzt flott beeinander.
     
  9. SolarCatcher

    SolarCatcher Active Member

    Registriert seit:
    24 August 2006
    Beiträge:
    702
    Hier leider nicht. Habe gestern die lumina-1.3.0,3-pkg eingespielt und getestet, die im offiziellen Vierteljahres-Repo aufgetaucht sind... Ich habe den Eindruck, dass sich die Performance leicht verbessert hat. Aber in meinem Test-Ordner mit 1500 (leeren) Dateien dauert ein Umbenennen einer Datei immer noch ca. 20 Sekunden. Und dann nochmal 20 Sekunden, bevor Lumina-fm wieder etwas anderes machen kann.
     
  10. peterle

    peterle Forenkasper

    Registriert seit:
    19 August 2006
    Beiträge:
    1.752
    Ort:
    Aachen
    Jetzt wollte ich das gerade noch einmal für Dich testen, habe aber wegen Synchronisationsproblemen mit meinen Clouds aktuell nur elementary OS im Laptop ... Sorry!
     
  11. pit234a

    pit234a Well-Known Member

    Registriert seit:
    8 Juli 2006
    Beiträge:
    3.116
    Sorry. Ich dachte, ich kann eine verfügbare zeit nutzen und es mal für dich testen, aber wie ich gerade sehe, ist es bei mir jetzt lumina-fm: 1.3.0. Ich habe nur den lumina-fm installiert (es gab noch zwei unerfüllte Abhängigkeiten zu irgendwas mit Qt5). Als Test habe ich genau nach dem Spript im Eingangsthread leere Dateien angelegt, lumina gestartet und ins Verzeichnis navigiert. Gleichzeitig habe ich das Verzeichnis mit pcmanfm geöffnet. Aus dem pcmanfm heraus dann eine Datei in leafpad geöffnet, geändert und abgespeichert. Dann in pcmanfm umbenannt.
    In lumina-fm passierte nichts, die Datei stand noch immer mit ihrer alten Größenangabe und dem unveränderten Namen dort. Nach einer gefühlten halben Ewigkeit passierte dann ein update. Die Datei dann in lumina-fm umbenannt, erscheint sofort mit neuem Namen in pcmanfm, aber wieder erst nach einer halben Ewigkeit in lumina-fm.
    lumina-fm das Fenster etwas größer gezogen: der Inhalt wird erst nach einer vollen Ewigkeit wieder passend dargestellt.

    Ich würde für mich sagen: unbrauchbar.
     
  12. SolarCatcher

    SolarCatcher Active Member

    Registriert seit:
    24 August 2006
    Beiträge:
    702
    Danke @pit234a !

    "unbrauchbar" ist relativ - die Entwickler haben das auf div. Systemen und Konfigurationen getestet und können dieses Verhalten nicht reproduzieren. Es scheint nur einen kleinen Teil der User zu betreffen.

    Sie haben schon angekündigt, dass sie das darunterliegende System zur Kommunikation mit dem Filesystem nochmal komplett umschreiben werden.
     
  13. marcel

    marcel Member

    Registriert seit:
    9 Juli 2017
    Beiträge:
    67
    System: Toshiba Satellite A300
    Code:
    FreeBSD 11.1-RELEASE #0: Sun Oct  1 15:18:17 CEST 2017
      ich@laptop.localhost:/usr/obj/usr/src/sys/LAPTOP amd64
    FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
    VT(vga): text 80x25
    CPU: Intel(R) Core(TM)2 Duo CPU  T6400  @ 2.00GHz (2000.11-MHz K8-class CPU)
      Origin="GenuineIntel"  Id=0x1067a  Family=0x6  Model=0x17  Stepping=10
      Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
      Features2=0xc08e39d<SSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,OSXSAVE>
      AMD Features=0x20100800<SYSCALL,NX,LM>
      AMD Features2=0x1<LAHF>
      TSC: P-state invariant, performance statistics
    real memory  = 4294967296 (4096 MB)
    avail memory = 4107427840 (3917 MB)
    
    Das Umbenennen einer der 1500 Dateien mit lumina-fm-1.3.0 dauert eine Minute. Während dieser Zeit ist WCPU durchgehend bei 68–69%.
     
  14. marcel

    marcel Member

    Registriert seit:
    9 Juli 2017
    Beiträge:
    67
    System: Asus Eee PC 1001PX
    Code:
     
    FreeBSD 11.1-RELEASE #1: Sun Sep  3 04:41:57 CEST 2017 
      ich@netbook.localhost:/usr/obj/usr/src/sys/NETBOOK i386 
    FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) 
    VT(vga): text 80x25
    CPU: Intel(R) Atom(TM) CPU N455  @ 1.66GHz (1666.52-MHz 686-class CPU) 
      Origin="GenuineIntel"  Id=0x106ca  Family=0x6  Model=0x1c  Stepping=10 
      Features=0xbfe9fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> 
      Features2=0x40e39d<SSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE>
      AMD Features=0x20100000<NX,LM> 
      AMD Features2=0x1<LAHF> 
      TSC: P-state invariant, performance statistics 
    real memory  = 2147483648 (2048 MB) 
    avail memory = 2085056512 (1988 MB) 
    
    Das Löschen und Umbenennen einer der 1500 Dateien mit lumina-fm-1.3.0 dauert jeweils zwei Minuten. Während dieser Zeit ist WCPU bei beiden Operationen jeweils durchgehend bei 76–77%.
     
    Zuletzt bearbeitet: 7 Oktober 2017
  15. marcel

    marcel Member

    Registriert seit:
    9 Juli 2017
    Beiträge:
    67
    System: Lenovo ThinkCentre M58p
    Code:
    FreeBSD 11.1-STABLE #8 r322509M: Mon Aug 14 23:22:28 CEST 2017
      ich@riara.uni.cx:/usr/obj/usr/src/sys/RIARA amd64
    FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
    VT(vga): text 80x25
    CPU: Intel(R) Core(TM)2 Duo CPU  E8400  @ 3.00GHz (2992.56-MHz K8-class CPU)
      Origin="GenuineIntel"  Id=0x1067a  Family=0x6  Model=0x17  Stepping=10
      Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
      Features2=0xc08e3fd<SSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,OSXSAVE>
      AMD Features=0x20100800<SYSCALL,NX,LM>
      AMD Features2=0x1<LAHF>
      VT-x: HLT,PAUSE
      TSC: P-state invariant, performance statistics
    real memory  = 8589934592 (8192 MB)
    avail memory = 7748583424 (7389 MB)
    
    Das Löschen und Umbenennen einer der 1500 Dateien mit lumina-fm-1.3.0 dauert jeweils 33 Sekunden. Während dieser Zeit ist WCPU bei beiden Operationen jeweils durchgehend bei etwa 70%.
     
  16. SolarCatcher

    SolarCatcher Active Member

    Registriert seit:
    24 August 2006
    Beiträge:
    702
    Super, vielen Dank. Ich habe Eure Erfahrung gerade an die Entwickler zurückgemeldet. Vielleicht bekommt dieses Issue doch nochmal die Liebe, die ihm dringend zukommen müsste.
     
  17. lme

    lme FreeBSD Committer

    Registriert seit:
    6 Mai 2003
    Beiträge:
    2.613
    Ort:
    Düsseldorf
  18. SolarCatcher

    SolarCatcher Active Member

    Registriert seit:
    24 August 2006
    Beiträge:
    702
    Sagt der Entwickler!

    Änderungen an einer Datei sind jetzt wirklich so schnell, wie man es erwarten würde - keine merkliche Verzögerung!

    Aber - zumindest auf meinem FreeBSD 11.1-RELEASE Laptop ist das Problem nur verschoben: Während das erste Öffnen des Test-Ordners recht flott ging, dauert es jetzt geschlagene 15 Sekunden. Damit bleibt Lumina für mich weiterhin ein Test-Spielzeug und nichts, was ich täglich einsetzen werde.

    Wobei ich die Hoffnung habe, dass die Entwickler es hinbekommen werden, dass sowohl das Öffnen eines Ordners als auch das anschließende Arbeiten darin, einigermaßen flott funktionieren. Zumindest scheinen sie endlich die Stellschrauben gefunden zu haben, die dieses Verhalten für einige von uns unerträglich macht.