Posts by Reichi

    Es gibt keinen scan aller Geräte ;).

    Die neue version ist ja bewusst "sparsam" gehalten (für den Anfang).

    Viele Geräte reagieren auch bestimmte Broadcasts direkt mit Rückfragen.

    Deswegen auch das Log ;).


    Du kannst auch gerne mit beiden Versionen ein Log erstellen, dann wird man das relativ schnell erkennen.

    OK ja, da hab ich eine Kleinigkeit im Vergleich zur alten Implementierung übersehen.


    ergänz doch in _onMessage einfach mal


    Python
    elif cmd == eCec.MSG_SET_SYSTEM_AUDIO_MODE:
        self.onSystemAudioModeStatus(sender, message)

    Ich schieb das derweil schon mal ins git.

    Muss ich nochmal testen, was bei self.giveSystemAudioModeStatus() zurückkommt.

    Das kommt asynchron zurück gell.

    Ich finde es allerdings eher merkwürdig, dass der AVR darauf gar nicht antwortet.

    Welches Modell ist das?

    Ggf. können wir im IRC auch gerne mal ein Log von deinem Fall durchsprechen.


    Das kann gut und gerne auch ein Bug in CEC 2.0 sein.

    Dafür gibts im ALTEN Cec die möglichkeit das Ziel zu forcieren (z.B. den TV).

    Im Neuen ist das so noch nicht implementiert.


    Code
    MSG_SYSTEM_AUDIO_MODE_STATUS

    schickt der AVR als antwort auf

    Code
    MSG_GIVE_SYSTEM_AUDIO_MODE_STATUS

    welches CEC 2.0 in

    Python
    def _onReady(self, logicalAddress, physicalAddress):

    abfragt (via self.giveSystemAudioModeStatus())

    Von nem TV habe ICH das in Logs noch nie gesehen.


    Die Standarddokumentation für CEC findet man im Supplement 1 der High-Definition Multimedia Interface Specification Version 1.4.

    Interessant und wichtig für die eigentliche Kommunikation sind m. M. n. die Kapitel CEC 3 und alle ab CEC 10 (alles Andere ist technischer Kram der euch nicht kümmern muss).


    Man kann sich natürlich auch die libcec zu Gemüte führen, für einen Einstieg ins Thema, ganz ohne theoretische Grundlagen, halte ich das aber für harten Tobak.


    Sven H Eine Möglichkeit für dich wäre es

    Python
    def sendSystemAudioKey(self, keyid, test=False):

    so abzuändern, dass es, wenn self._volumeDest != ADDR_AUDIO_SYSTEM ist, du den Request an den TV schickst.

    Und dann den config Eintrag auf True zu setzen (gerufen wird das dann aus CecRemote).

    Das entspräche dann funktional der alten "TV (forciert)" Einstellung.

    vorsicht: "AVR Volume Control"

    Dass ein TV das überhaupt kann ist halt eigentlich schon am Standard vorbei (ich hab mir das alles nicht ausgedacht!)


    Nachtrag: Im *-Text von Samsung liest es sich so als müsste es eigentlich gehen, das sollte aber mit der alten CEC Implementierung auch schon funktionieren.


    Nachtrag 2: OK in der Tabelle geht's wohl viel mehr darum ob der TV den AVR steuert. Vond aher wird die wenig helfen ;).

    Ich muss glaube nochmal darauf hinweisen, dass die wenigsten hersteller Laustärkesteuerung über CeC überhaupt ermöglichen.

    Was auch immer man vor hat, man sollte da vorher gut recherchieren ob das technisch überhaupt möglich ist.


    Meiner leicht getrübten Erinnerung nach war das eigentlich nur Sony.

    Hey, wir haben CEC in python, ihr dürfte gerne mal ausprobieren wie ekelhaft das ist.

    Tatsächlich ist es aber eher, so, dass sich dieses Problem mit den "sterben" älterer Geräte langsam aber sicher von alleine Löst.

    Die neueren Geräte-Generationen (von TVs und AVRs) verhalten sich, was CEC angeht, insgesamt schon sehr viel besser.


    Aber im Ernst.

    Dass das Ganze in python "rebootet" wurde, hat schlicht den Grund, dass es einfach nötig war das ganze nochmal von Null neu aufzubauen.

    Es ist auch nicht "fertig", funktioniert aber in sauberen, Standardkonformen Umgebungen eigentlich ziemlich gut.


    Im Übrigen wäre es relativ einfach einen "Vendor-Handler" zu bauen der z.B. Herstellerspezifische Tastendrücke für Lautstärke senden kann (oder wie auch immer das bei LG und konsorten gelöst sein mag).

    Sollte also doch mal jemand Interesse haben sich in das Thema reinzufuchsen, steh ich jederzeit!!! für Fragen und Anregungen und auch gerne entsprechend Starthilfe zur Verfügung.

    Moin,


    die Werkzeuge zum Updaten der RCU sind in Arbeit und werden NATÜRLICH auch für die DM9x0 veröffentlicht werden.

    Es tut uns leid, dass es mal wieder etwas länger dauert. Aber solche Firmware-Update Prozesse sind kritisch und müssen zuverlässig funktionieren, speziell wenn sie "Over-The-Air", wie im Falle der RCU, passieren.

    Es ist keinem geholfen wenn er wegen eines gescheiterten Updates einen "toten" schwarzen RCU-Block zu Hause hat.


    Man kriegt die BT-RCU zwar im Normalfall nie ganz Tot, aber wir müssen eben auch sicherstellen, dass sie von der Dreambox aus wieder zum Leben erweckt werden kann.

    Leider ist Fehlerbehandlung und Co und solchen Fällen immer Aufwändig.


    Bitte habt noch etwas Geduld, der Weg ist nicht mehr all zu Weit!

    Maybe some general comments about this.

    A load above 100% is not an issue per-say.


    A Dreambox One/Two has six cores which can lead to top showing up to 600% CPU load.


    But your "error description" was lacking pretty much ANY additional information so it was totally impossible to understand that your device was under permanent load.

    Please try to describe your issue a lot more in detail next time.

    Einfach willkürlich nen Tag später alle Beträge in nem Thread wieder löschen geht aber auch nicht.

    Gutemine hat ab sofort eingeschränktes editierrecht. Was das genau bedeutet werde ich hier nicht erläutern.

    Außer eines: Beiträge löschen ist damit vorbei.