Beiträge von clocker

    Ohne jetzt alles einzeln gelesen zu haben, habe ich noch Vorschläge, die ruckzuck eingebaut sind. Hab das bei meiner verpanschten 0.7er auch immer so gemacht. Um die Ausfallsicherheit weiter zu erhöhen habe ich


    1. dem Kernel den Bootparameter "panic=1" mit auf den Weg gegeben. Das führt zu einem Neustart, sobald eine Kernelpanic auftritt. Ich will ja im Wohnzimmer im unwahrscheinlichen Fall eines Notfalls nicht auf den eh nicht vorhandenen Resetknopf drücken.


    2. wäre es nett, wenn das runvdr-Script, falls der vdr abgeschmiert ist (watchdog spricht an) und der Treiber entladen wurde, nochmal überprüfen würde, ob der Treiber wirklich entladen ist. Manchmal bei (sehr buggy) Systemen kann sich der Treiber so verabschieden, dass nur noch ein Neustart hilft (weil er nicht mehr zu entladen geht). Das könnte man per runvdr abfangen und automatisch rebooten.

    Ich hatte das auch mal. Mein Problem war Folgendes:


    Ich hatte in der commands.conf ein Script eingetragen, was in etwa so gestartet wurde:


    Test: /usr/bin/test &


    Das abschließende "&" dient ja dazu, den Prozess im Hintergrund zu starten, weil sonst VDR hängen bleiben würde.


    Das reicht aber NICHT!


    Ich musste es so machen:


    Test: echo /usr/bin/test | at now


    Erst dann ging's. Wieso, keine Ahnung. Hat sicher etwas mit der Shell zu tun. Vielleicht hilft es ja jemandem.

    Ich bin mir nicht ganz sicher, aber ich meine, dass der Patch drin war. Ich habe auf einem System c't-VDR installiert und mit dem aktuellen vdrdevel-Paket experimentiert. Würde mich eigentlich wundern, wenn der Patch da nicht drin gewesen wäre.
    Du kannst ja mal das probieren (mit dem VDRAdmin-TV in ein Menü gehen), was ich im ersten Posting geschrieben habe. Dann erfährst du, ob der Patch wirklich auch mein Problem beheben würde.

    Ich weiß nicht genau, was die Ursache ist. Es sind ja mehrere Probleme. Einmal die fehlende Initialisierung (wobei ich nicht kapiert habe, ob das eventuell auch mit dem Scrolling zu tun hat). Dann die Tatsache, dass die Sleep-Methode, wenn man im Menü ist und den VDRAdmin-Fernseher anhat, ständig unterbrochen wird. Ich habe auch nicht verstanden, was diese "delayed updates" machen.
    Mein Patch ist somit einfach ein Workaround.

    Ich bin jetzt hergegangen und habe die ganze Methode durch das ersetzt:



    Keine Ahnung, ob sich das auf das Scrolling von Text auswirkt, das geht bei mir eh nicht, oder ich habe es nicht an, keine Ahnung. Die Änderung bewirkt jedenfalls u.a., dass eine Mindestwartezeit von 100 ms zwischen den Aktualisierungen eingeführt wird. Öfter will ich das Bild eh nicht sehen.


    Das ganze Plugin ist mir sowieso etwas suspekt, weil ich letztens versucht habe, ein Theme anzupassen, aber aufgrund der ganzen Schreibfehler den Durchblick verlor. Da stehen solche Sachen wie "widht" drin. Nach einem Blick in den Quellcode habe ich dann mitbekommen, dass die im Theme tatsächlich prämeditiert waren... aber dann hatte ich keine Böcke mehr.

    Des Monologes dritter Teil


    Was ist eigentlich das hier? (erste Erwähnung von _updateIn in Action())


    Ist es Absicht, dass _updateIn manchmal undefiniert bleibt?

    Also, ich habe jetzt herausgefunden, dass die Methode


    _doUpdate.TimedWait(_mutex, _updateIn);


    in der display.c im o.g. Fall ständig durch irgendetwas unterbrochen wird. Das resultiert darin, dass das Bild alle Furz lang (Furz ~ 0 ms) aufgerufen wird. Kein Wunder, dass die Auslastung hoch geht. Hat einer eine spontane Ahnung, warum das so ist? Warum gerade, wenn man in so einem Menü ist?
    Ein Workaround wäre es jetzt, zu überprüfen, ob überhaupt etwas Zeit vergangen ist und nur dann neu zeichnen zu lassen.

    Es ist übrigens essentiell wichtig, dass ein fsck auch beim Start aufgerufen wird. Wenn es nämlich Dateisystemfehler gibt, MÜSSEN die behoben werden, bevor wild auf der Platte herumgeschrieben wird, da sonst im schlimmsten Fall Daten weg sind. Alles andere widerspräche dem Sinn von journalling file systems. Bei LinVDR wird fsck daher ein Mal beim Start aufgerufen und beim Beenden wird es dann nur erzwungen, falls in Kürze ein Routinecheck anstünde.

    Hi *,


    hat hier irgendjemand noch das Problem, dass mit dem GraphTFT die CPU-Auslastung auf 100% steigt, wenn ihr in Untermenüs Optionen ändert?


    Macht mal bitte Folgendes: Per VDRAdmin auf Menü / Einstellungen / OSD gehen und dann die CPU-Auslastung beobachten. Hat jemand eine Idee, wie man das Problem beheben kann?