Debian lcd4linux und mpd (Pearl-dpf)

  • Demo geht jetzt, aber bei python PyDPF.py kommt:



    PyDPF.py: cannot connect to X server


    das wird doch nicht wirklich nen x-server brauchen?

    Asus AT3N7A-I | Atom 330 mit Nvidia Ion 2gb Ram

    Creatix CTX 929

    X10 als Fernbedienung

    yavdr

  • Schau mal in die README und die config.py - ich behaupte mal, du willst in letzerer sowas in der Art einstellen:

    Code
    1. DISPLAY=PEARL_DPF

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • An meiner Dockstar hängt ein Pearl LCD. LCD4linux wird beim booten mitgestartet, so dass CPU etc angezeigt wird.
    Jetzt habe ich festgestellt, dass der LCD4linux-Prozess mindestens 12% CPU verbrät. Wenn ich zB ein File auf die dockstar kopiere, geht der Verbrauch sogar auf 30-40%% hoch (dann bleibt für smbd nur noch der Rest...)


    wenn ich einmal killall lcd4linux sage und es neu starte mit /etc/init.d/lcd4linux start, ist alles wie gewohnt, unter 2 %.
    Ich habe wheezy mit kernel 3.2.0-4 installiert.


    Hat jemand eine Idee, woran das liegen könnte?

    ION ITX-A mainboard mit NVIDIA und Atom330 auf yavdr 0.4
    Satelco Easywatch DVB-S2 baugleich TT3650. (und noch ne Terratec S7 - geht net, kriegt keinen sync bei HD Sendern)
    Logitech Harmony "Volksfernbedienung" (brilliantes Preis/Leistungsverhältnis)
    Denon 1912 AVR mit Medion TV

  • An meiner Dockstar hängt ein Pearl LCD. LCD4linux wird beim booten mitgestartet, so dass CPU etc angezeigt wird.
    Jetzt habe ich festgestellt, dass der LCD4linux-Prozess mindestens 12% CPU verbrät. Wenn ich zB ein File auf die dockstar kopiere, geht der Verbrauch sogar auf 30-40%% hoch (dann bleibt für smbd nur noch der Rest...)


    wenn ich einmal killall lcd4linux sage und es neu starte mit /etc/init.d/lcd4linux start, ist alles wie gewohnt, unter 2 %.
    Ich habe wheezy mit kernel 3.2.0-4 installiert.


    Hat jemand eine Idee, woran das liegen könnte?


    Ich weiß nicht, ob es das gleiche Problem ist, aber bei mir hatte der Timercode von LCD4Linux ebenfalls Probleme.
    Hintergrund bei mir, die Dockstar hat kein RTC. Damit startet die Uhr immer mit dem 1.1.1970 und wird erst Sekunden später
    per NTP aktualisiert, wenn das Netzwerk online ist. Der Orignalkode von LCD4Linux kommt aber mit einem so langen Zeitsprung
    nicht klar. Ich habe dies für mich, wie folgt behoben, den Patch aber nie Upstream für eine Review gesendet.