DM9x0 - LED Anzeigen optimieren um bestimmte Zustände anzuzeigen (on|off|red|blue|purple|blinking)

  • Mit den default Einstellungen (ohne LED Manager) ist die blaue LED ON wenn die Box aktiv ist, OFF im IDLE Mode. Wenn eine Aufnahme läuft oder über das Web-IF gestreamt wird blinkt die blaue LED - aber man weiß nicht, ob wg. einer laufenden Aufnahme oder weil ein Stream aktiv ist ...


    Die DM9x0 haben ja zwei LED's die man gut nutzen könnte: Vielleicht kann man einbauen, dass wenn z.b. ein Aufnahme läuft per default die blaue LED blinkt und wenn über das Web-iF (streamproxy), HLS oder RTSP gestreamt wird die Rote? Best Case: violett oder abwechselnt rot/blau blinkend wenn eine Aufnahme läuft UND ein Stream aktiv ist.


    Ich habe das auf meiner dm900uhd mit einem shell script das im loop mit einem sleep 1 läuft umgesetzt (ohne ledmanager) - was aber nicht schön ist ...


    Mein Script bewirkt folgendes:
    - beide LEDs sind immer off (ON + IDLE) - das Display zeigt mir ja den Stauts an (im IDLE wird hier nur die Uhrzeit angezeigt)
    - läuft eine Aufnahme: led0 (blue) ON
    - läuft ein stream: led1 (red) ON
    - läuft eine Aufnahme UND ein stream: led0+led1 ON = violet



    HLS und RTSP kann man über netstat abfragen, wobei aktives HLS streaming Unmengen von PID's auswirft, die eingestellten Ports kann man aus den e2 settings auslesen, aber vielleicht gibt es über Enigma2 andere Möglichkeiten


    Kann man so etwas fix in Enigma2 einbauen - wäre schade wenn man zumindest 8 (von noch mehr möglichen) LED Stati nicht nutzt um bestimmte Zustände anzuzeigen: LED off, red, blue, violet, blinking red, blinking blue, blinking violett, blinking blue/red


    Derzeit werden per default eigentlich nur 3 Stati ausgeschöfpft: IDLE = LED off, ON = BLUE on, recording (blinking BLUE)

    Gruß Fred

    Die Dreambox ist tot, es lebe die Dreambox

    Einmal editiert, zuletzt von Fred Bogus Trumper ()

  • +1
    Eine klare Unterscheidung zwischen Recording/Streaming (nicht nur bei der LED, auch in den Skins) wäre vermutlich nicht das Dümmste. Ich lese immer wieder von Usern die Unsicher sind warum "Rec" blinkt.

  • Entweder liefert e2 das zurück oder deine Scripts werden in einen Converter oder vielleicht Source eingebaut. Ich nehme mal an, das geht sehr performant mit deinem Script.

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • +1
    Kannst du uns dein Skript mal zur Verfügung stellen.
    Ich finde die Idee auch sehr gut.


    Kann man vielleicht das Ledmanager Plugin erweitern?
    Leider bin ich mit Python ein kompletter Anfänger. Lesen geht so langsam, aber proggen leider nicht.

  • +1
    Eine klare Unterscheidung zwischen Recording/Streaming (nicht nur bei der LED, auch in den Skins) wäre vermutlich nicht das Dümmste. Ich lese immer wieder von Usern die Unsicher sind warum "Rec" blinkt.

    Genau das war der Grund warum ich mir überlegte, ob und wie man das umsetzen könnte. Es gibt ja garade wieder einen Threat zu diesem Thema



    Aber ganz ohne ledmanager komme ich dereit noch nicht aus, da gibt viele Bedingungen die man Abfragen muss - und die werden nicht weniger, wenn man mehrere Zustände darstellen will ...
    Aktive HLS oder RTSP Streams funktionieren auch noch nicht ganz so wie ich möchte



    @dre
    Das nur per script umzusetzen hat wieder den Nachteil, dass es schwerer wird individuelle Anpassungen zu machen - z.b. über den ledmanager. Aber die Idee mit dem converter gefällt mir. Ich hab' da noch ein paar selbstgestrickte aus OE2.0 Zeiten liegen, die ich umbauen könnte Damit wäre eine REC, Stream, HLS oder RTSP Anzeige im Skin auch möglich.


    Aber hier geht es mal um die LEDs, damit könnte man auch im IDLE unterschiedliche Zustande darstellen

    Gruß Fred

    Die Dreambox ist tot, es lebe die Dreambox

  • vermute in der StreamServerConfig.py unter


    def _setInfoText(self):


    Wenn ich den Code richtig verstehe, werden hier auch die nur ports geprüft, da könnte man siche auch den streamproxy port so abfagen

    Gruß Fred

    Die Dreambox ist tot, es lebe die Dreambox

  • Dann ginge bei den Aufnahmen doch ggf. die unterschiedliche Signalisierung nach der Art (Timer, Pseudoaufnahme...). Und wenn Autotimer die Unterscheidung liefern würde... bei der Timeraufnahme die Unterscheidung nach Direkt-Timer, Ausweich-Timer.

    NEU: DM920 (1x DVB-S2 FBC Twin Tuner, 1x DVB-C/T2 Dual-Tuner)
    ALT: DM8000 (2x DVB S2 Tuner, 2x DVB-C Tuner)

  • Das wird dann schon viel Info und unübersichtlich


    Es ging mir ursprünglich darum, dass man am LED gleich erkennt ob eine Aufnahme läuft oder ein Stream abgegriffen wird. Da werden immer die "hellhörig" deren http(s) ports etc. extern offen sind ...


    Ich komme schon so auf 11 mögliche Zustände, wenn man OFF mitzählt - und das ist schon oversized.
    Ich bin gespannt ob ich das mit einem script sauber auf die Reihe bekomme, um eine E2 Implemtierung müssten sich andere kümmern ...


    Gruß Fred

    Die Dreambox ist tot, es lebe die Dreambox

  • Ich denke, es sollte mal klein angefangen werden. Zuerst mal saubere Erkennung der verschiedenen Typen von Streams und das performant. Danach mit den LEDs weitermachen. Aber leider geht es in solchen Threads oft rasch in die gleiche Richtung: ein paar wenige bringen Lösungsvorschläge und viele wünschen sich schon wieder die eierlegende Wollmilchsau.

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • vermute in der StreamServerConfig.py unter


    def _setInfoText(self):


    Wenn ich den Code richtig verstehe, werden hier auch die nur ports geprüft, da könnte man siche auch den streamproxy port so abfagen


    Ne da muss noch irgendwo im Code der Wert self._clientCount gesetzt werden. Das ist aber eine private Variable (zu erkennen an dem _ vor dem Namen) und da bräuchte man noch eine Funktion um das auslesen zu können.


    Für Shell-Scripte hilft dir das natürlich eh nichts. Guck mal ob das mit netstat und Co ohne zusätzliche CPU last funktioniert.

    so long
    m0rphU

  • Wenn ich das Script im loop mit 0.3 Sekunden laufen lasse (damit bekam ich saubere LED Anzeigen hin) pendelt die CPU Last für das Script zwischen 0.0 und 1.0% bei 0,1%MEM - 0.5% CPU im Schnitt dürfte hinkommen.


    Allerdings prüfe ich derzeit nur ob recording, streamproxy, hls und rtsp true oder false ist, setze also noch keine Aktionen. Das Script verrichtet quasi die Arbeit eines converters.


    Ich mache auch nur eine netstat Abfrage und versuche aus dem Buffer auszulesen, ob stremproxy, rtsp und hls Zugriffe stattfinden.
    Mit wget prüfe ich ob eine Aufnahme läuft was mit einer python Lösung wegfallen würde.



    Interesant wäre, was ein vergleichbarer converter an zusätzlicher Last verursacht

    Gruß Fred

    Die Dreambox ist tot, es lebe die Dreambox

  • Die Last des Converters ist das eine. Auch die poll-Häufigkeit sollte smart gewählt werden.


    Spannend wäre, wenn für jeden client was geschrieben wird in ein File. Mal schauen am Weekend

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • Please add also "Dark Hours" feature for Dreamboxes used in bedroom


    as incomplete solution i use command
    echo "00"> / proc / stb / fp / led0_pattern
    called from the /usr/script>enigma_standby_off.sh

  • Das Schreiben in ein file wollte ich vermeiden. Man kann ja auch die netstat Ausgaben so filtern, dass nur aktive tcp/udp Verbindungen angezeigt werden und nicht die LISTEN Ports
    Die Ausgabe kann man in ein Variable schreiben und daraus die Stati abfragen - dann muss man netstat nur einmal Bemühen und nicht für jeden gewünschten port


    z.B:


    Bash
    root@dm900uhd:~# HLSPORT=8080
    root@dm900uhd:~# STREAMPROXYPORT=8001
    root@dm900uhd:~# CACHE=$(netstat -tuen|grep -v 127.0.0.1|awk '{print $4}'|grep [0..9])
    root@dm900uhd:~# if echo $CACHE|grep :$HLSPORT  >/dev/null;then echo HLS access;fi
    root@dm900uhd:~# if echo $CACHE|grep :$STREAMPROXYPORT  >/dev/null;then echo streamproxy access;fi
    streamproxy access
    root@dm900uhd:~#


    die Variable CACHE enthält dann nur noch die Liste aller aktiven Verbindungen im Format: IP:PORT IP:PORT IP:PORT


    mit echo $CACHE|sed 's/ /\n/g' bekommt man sie wieder gelistet



    Code
    root@dm900uhd:~# CACHE=$(netstat -tuen|grep -v 127.0.0.1|awk '{print $4}'|grep [0..9])
    root@dm900uhd:~# echo $CACHE
    192.168.178.90:80 192.168.178.90:22 192.168.178.90:8001 192.168.178.90:22 192.168.178.90:80 
    root@dm900uhd:~#  echo $CACHE|sed 's/ /\n/g'
    192.168.1.90:80
    192.168.1.90:22
    192.168.1.90:8001
    192.168.1.90:22
    192.168.1.90:80
    root@dm900uhd:~#


    Aber ich such auch noch nach anderen Lösungen, vielleicht kann man die Infos direkt aus /proc oder /sys auslesen - ohne netstat

    Gruß Fred

    Die Dreambox ist tot, es lebe die Dreambox

  • @MartiniB: that's what I meant with one of my previous posts. Everyone comes up with fancy ideas but the focus must be on an initial solution and afterwards one can think about the fancy stuff

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • separate independent tread for such small `feature` equals to another dead tread
    sometimes, when building something big, is better to know most of possible details,
    just have a choice leave some for later.

  • I see differently, it's so annoying to immediately have all the fancy stuff being brought up. Especially, as noone knows yet if the basic requirements can be realised

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource