[ANNOUNCE] XBMC LCDproc Support als Python Addon

  • Hallo zusammen,


    "script.xbmc.lcdproc" bzw. "XBMC LCDproc" ist jetzt Bestandteil des offiziellen XBMC.org Addon Repository und kann über dieses installiert werden. Dementsprechend werden Updates zwischen stabilen Versionen automatisch eingespielt. ;)


    Bitte beachten: Im Zuge dessen wird ab den ersten XBMC 13-ALPHA Builds die bisher verfügbare LCDproc-Unterstützung im Core NICHT mehr enthalten sein.


    Vielen Dank an alle, die bis hierhin fleissig getestet und konstruktive Verbesserungs- und Feature-Vorschläge gemacht haben (selbige fliessen natürlich auch in zukünftige Versionen weiterhin ein!) :)


    Viele Grüße,
    Daniel


    ====== Ursprungsposting ======


    Nabend,


    So wie es sich abzeichnet, scheint die LCDproc-Unterstützung ziemlich bald (nach Frodo?) aus dem XBMC Core rausfliegen (macht leider entsprechend die bekannten Patches rund um die SoundGraph/mdm166a Displays obsolet). "Memphiz" (einer der XBMC Entwickler) hat allerdings im Vorfeld bereits angefangen, die LCDproc Unterstützung in Python nachzubauen, hat aber leider wohl relativ schnell das Interesse verloren. Mit seiner freundlichen Genehmigung zur Weiterverwendung seines bisherigen Codes habe ich mich mal rangesetzt und das Addon weitergepflegt:


    - Alles, was in Core funktioniert (oder funktionieren sollte), sollte implementiert sein.
    - Die Verwertung von Sonderzeichen und "BigNums" ist stark verbessert: Anstatt direkt (binäre) Sonderzeichen an LCDproc zu schicken, werden jetzt "ordentlich" passende Widgets zur Darstellung beispielsweise des Play-Icons und vor allem der "BigNums" verwendet. Der grosse Vorteil: Es ist keine Zeichenumwandlung mehr notwendig, und die Anzeige funktioniert auch mit anderen Displays als HD44780 und iMon/mdm166a Displays (selbst Character-Displays sollten - mehr oder weniger - funktionieren!)
    - Die Responses im LCDproc Dialog werden allesamt ausgewertet und bei Bedarf passend reagiert.
    - Allgemein wird die Socket Schnittstelle nicht mehr mit widget_add/del/set geflutet, sondern wirklich nur noch das kommuniziert, was sich wirklich verändert. Dies sollte der Last zuträglich sein und den LCDd nicht zu Fehlern verführen :)
    - Die Initialisierung sollte wesentlich robuster funktionieren und auf Änderungen im LCDd Serverprotokoll reagieren
    - Einige Funktionen aus dem iMon/mdm166a Patch sind (bereits) übernommen (z.B. konfigurierbarer Scroll Separator, Display Refresh Frequenz)
    - Diverse kleine Verbesserungen


    Das Addon wird im Laufe der nächsten (noch zu definierenden) Zeit die Unterstützung für die Extra-Funktionalitäten der SoundGraph LCDs sowie mdm166a Displays erhalten. Wichtig war aber zunächst, den übernommenen Code von Fehlern zu befreien, stabil ans Laufen zu bekommen und möglichst viel aus "Core" reinzubekommen.


    Das Addon funktioniert derzeit mit Eden und mit Frodo/master!


    Für Tests: Unter "System - Video Hardware - LCD/VFD benutzen" abschalten. Das Addon entweder im Addons-Ordner des Homedirs oder im System-Addon-Ordner unterbringen. Dann (ggf. nach XBMC Neustart) über die Addon-Verwaltung unter "Dienste - XBMC LCD/VFD" aktivieren, optional Konfiguration anpassen.


    Das Addon kann von https://github.com/herrnst/script.xbmc.lcdproc gecloned bzw. heruntergeladen werden. Der Originalcode ist unter https://github.com/Memphiz/script.xbmc.lcd zu finden.


    Ich würde mich sehr freuen, wenn sich einige freiwillige finden würden, die das Ganze bei sich mal (länger?) testen könnten, um weiter Fehler bereinigen, und um die Funktion mit anderen Displays verifizieren zu können!


    UPDATE 01.11.2012: Im GIT ist die Unterstützung für SoundGraph iMON LCD sowie Futaba mdm166a VFD Displays in den Master-Branch eingeflossen! Mehr dazu...


    UPDATE 02.02.2013: Das GIT-Repo des Addons ist im Zuge der Aufnahme ins XBMC Addon Repo nach https://github.com/herrnst/script.xbmc.lcdproc umgezogen! Bitte bestehende Installationen entsprechend updaten.


    Viele Grüße,
    Daniel


    P.S.: Unter https://github.com/herrnst/script.xbmc.lcdproc/wiki habe ich ein wenig Doku abgelegt, wie das Addon zu verwenden ist (inkl. Optionen). Fragen selbstverständlich immer gerne her :)

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

    The post was edited 5 times, last by nst: Bugupdate / Link zur GitHub Wiki-Doku eingefügt / Hinweis auf GIT-Änderungen u. iMON/mdm166a Support bzw. Link zum Post / GIT-Repo umgezogen / Final, Announcement ().

  • Leider habe ich keine Zeit zum testen. Trotzdem möchte ich sagen das ist ein sehr guter Ansatz. Klasse dass du dich darum kümmerst. Endlich wieder ein Patch weniger.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Ich habs gleich mal ausprobiert und bekomme beim start des skriptes diese Exception



    Mein PC:
    Openelec frodo 12 Oktober
    IMON LCD



    Und Danke für die Arbeit an dem skript. Die Icons (wenn sie kommen ^^) sind das letzte was mir, für meinen perfekten HTPC, noch fehlt.



    mfg buzzer

  • Ich vermute da gibt es ein locale-Problem (IIRC wird da normalerweise POSIX als Locale genutzt), das dann bei dieser Abfrage fälschlicherweise ASCII als Encoding ausspuckt: https://github.com/herrnst/scr…ources/lib/lcdbase.py#L85
    Unter Ubuntu mit Upstart hatte ich ein ähnliches Problem (http://forum.ubuntuusers.de/to…emencoding-in-upstart-jo/)
    Abhilfe könnte schaffen LC_CTYPE für das System auf die richtige Locale zu setzen oder mal die oben genannte Zeile entsprechend abzuändern (unschön, aber was besseres habe ich noch nicht gefunden):

    Code
    1. elf.m_strInfoLabelEncoding = sys.getfilesystemencoding()


    nach

    Code
    1. elf.m_strInfoLabelEncoding = 'utf-8'

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hi,


    zunächst vielen Dank für das erste Feedback! ;)


    Ich habs gleich mal ausprobiert und bekomme beim start des skriptes diese Exception


    Code
    1. 15:08:26 T:2514754368 ERROR: EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<--
    2. [...]
    3. line = line.decode(self.m_strInfoLabelEncoding).encode(self.m_strLCDEncoding, "replace")
    4. UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 8: ordinal not in range(128)
    5. -->End of Python script error report<--
    6. 15:08:26 T:2514754368 INFO: Python script stopped


    Doof. D.h. die Autoerkennung des Encodings ist/war Mist (auf meinem Gentoo Entwicklungssystem und mein "Production"-HTPC mit Ubuntu 12.04 kam da jeweils "UTF-8" raus, womöglich Zufall...). Der fragliche String dürfte "Hauptmenü" gewesen sein - würde für UTF-8 beim "ü" sprechen - 0xc3 0xbc. Ich hab' den Code abgeändert, es wird jetzt davon ausgegangen, dass XBMC grundsätzlich UTF-8 für InfoLabels zurückgibt. Funktionierts (nach "git pull" usw.) damit besser?


    Und Danke für die Arbeit an dem skript. Die Icons (wenn sie kommen ^^) sind das letzte was mir, für meinen perfekten HTPC, noch fehlt.


    Ja, wird definitiv kommen! :)


    Ich vermute da gibt es ein locale-Problem (IIRC wird da normalerweise POSIX als Locale genutzt), das dann bei dieser Abfrage fälschlicherweise ASCII als Encoding ausspuckt: https://github.com/herrnst/scr…ources/lib/lcdbase.py#L85


    Hintergrund ist, dass ich nicht sicher bin, welches Encoding XBMC zurückliefert bzw. ob dies vom System Locale abhängt. Letzteres scheint aber nicht der Fall zu sein. LCDproc erwartet als Stringeingabe jedenfalls zwingend ISO-8859-1 bzw. -15, UTF-8 führt zu lustigen Sonderzeichen im LCD :) "sys.stdout.encoding" wirft in der XBMC-Umgebung 'ne Exception, laut http://wiki.python.de/Von%20Um…Unicode%20und%20Encodings bietet sich da "sys.getfilesystemencoding()" an, ist aber wohl Fehlanzeige. Daher jetzt fix "UTF-8".


    Habe nebenbei den Firstpost editiert und die Bugs aktualisiert :)


    Viele Grüße,
    Daniel

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Hintergrund ist, dass ich nicht sicher bin, welches Encoding XBMC zurückliefert bzw. ob dies vom System Locale abhängt.


    Meiner Erfahrung nach zählt da was für LC_CTYPE gesetzt ist - laut http://forum.xbmc.org/showthread.php?tid=80845&pid=1119795#pid1119795 ist es in der Voreinstellung POSIX (und damit ermittelt er immer ascii als filesystemencoding), einen sauberen Weg habe ich noch nicht gefunden, aber zumindest die Locale lassen sich unter Openelec.tv erzeugen und wohl auch einstellen: https://github.com/OpenELEC/OpenELEC.tv/pull/1001

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Also bei mir reagiert Python für sys.getfilesystemencoding() auf die Umgebungsvariable LANG, also ein "export LANG=de_DE.UTF-8" vor dem Aufruf von XBMC sollte helfen (ich hatte das Problem das der Aufruf eines Python Scriptes aus cron hier immer ASCII geliefert hat).


    BTW: Python3 unter Windows liefert für sys.getfilesystemencoding() Mist. Zumindest liefert es nicht utf-8 obwohl das Dateisystem unter NTFS immer utf-8 ist.
    (Nur ums Thema komplett zu machen ;) )


    cu

  • Auch grade nochmal im Addon und LOGDEBUG getestet ("log(xbmc.LOGDEBUG, "Encoding: " + sys.getfilesystemencoding())" in lcdbase.py/LcdBase::Initialize()):


    Code
    1. $ LC_ALL=POSIX && xbmc
    2. -> 18:49:25 T:140133657143040 DEBUG: ### [XBMC LCD/VFD] - Encoding: ANSI_X3.4-1968
    3. $ LC_ALL=C && xbmc
    4. -> dito
    5. $ LC_ALL=de_DE.UTF-8 && xbmc
    6. -> 18:51:28 T:140244074575616 DEBUG: ### [XBMC LCD/VFD] - Encoding: UTF-8


    In allen Fällen hat "decode('utf-8').encode('iso-8859-1')" wunderbare Umlaute zurückgegeben. Da scheint tatsächlich prinzipiell UTF-8 aus den InfoLabels rauszukommen.


    EDIT: Auf "LANG=" scheint XBMC nicht zu reagieren, da kommt bei "LANG=POSIX" trotzdem UTF-8 raus.

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Ja, das ist auch so eine Sache, bei der sich Python bei der Zeichen(ketten)behandlung wie eine Diva aufführt. Damit stehe ich auch auf Kriegsfuss - aber wohl, weil ich da noch nicht richtig durchgestiegen bin. Ich verwende:


    Code
    1. import sys
    2. ...
    3. reload(sys)
    4. sys.setdefaultencoding("latin-1") # utf-8 sollte auch funktionieren


    BJ1

  • Das Problem ist ja nicht die Verwendung eines definierten Encodings, sondern die automatische Bestimmung des selben aus den Informationen, die das System bereitstellt...
    Und nebenbei: sys.setdefaultencoding is evil

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ja, das ist auch so eine Sache, bei der sich Python bei der Zeichen(ketten)behandlung wie eine Diva aufführt.


    Ich war auch immer dieser Meinung. Aber tatsächlich macht das Python schon gut und richtig, man muss nur erst mal kapieren was Python da macht, dann ergibt das alles Sinn ;)


    sondern die automatische Bestimmung des selben aus den Informationen, die das System bereitstellt...


    Wobei das hier eher ein xbmc Problem ist. Wenn es immer utf-8 liefert egal was im System eingestellt ist dann kann Python nix dafür. Dann muss man das einfach mal wissen und in den Addons fix utf-8 verwenden.


    Und das sich das reale Dateisystemencoding (also in welchen Encoding die Dateinamen tatsächlich gespeichert sind, eigentlich ist sys.getfilesystemencoding() ja dafür da) nicht ermitteln lässt, das ist eindeutig generell ne Linux schwäche.


    cu

  • Ich verwende:

    Code
    1. import sys
    2. ...
    3. reload(sys)
    4. sys.setdefaultencoding("latin-1") # utf-8 sollte auch funktionieren


    Problem scheint zu sein, dass


    Code
    1. import xbmc
    2. ...
    3. line = xbmc.getInfoLabel(...)


    ... sich anscheinend nicht dran hält bzw. das Encoding der Rückgabe nicht "LC_xx" entspricht bzw. entspechen muss (bisher gefühlt immer UTF-8 ) ?(

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Dann nimm doch einfach uft-8 an (ohne Abfrageversuche). Dann noch ein "replace" hinter dem Encoding dann gibts keinen Abbruch wenn da doch mal was schiefgeht (oder Unicodezeichen kommen die in ISO nicht abbildbar sind).


    cu

  • BTW: Python3 unter Windows liefert für sys.getfilesystemencoding() Mist. Zumindest liefert es nicht utf-8 obwohl das Dateisystem unter NTFS immer utf-8 ist.
    (Nur ums Thema komplett zu machen )


    Das ist ja klar, steht auch in der Doku: http://docs.python.org/py3k/library/sys.html

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Dann nimm doch einfach uft-8 an (ohne Abfrageversuche). Dann noch ein "replace" hinter dem Encoding dann gibts keinen Abbruch wenn da doch mal was schiefgeht (oder Unicodezeichen kommen die in ISO nicht abbildbar sind).


    Jo, "utf-8" ist jetzt statt sys.getfilesystemencoding() drin :)

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Das ist ja klar, steht auch in der Doku: http://docs.python.org/py3k/library/sys.html


    Jetzt wo du es sagst, aber den Sinn dahinter verstehe ich absolut nicht. Überall liefert sys.getfilesystemencoding() das IST und P3 unter Win liefert das, in das man das evtl. Konvertieren könnte.


    IMHO ist das nen Bug in Python.


    cu

  • Bin gespannt :)


    Habe heute noch ein wenig Code-Cleanup betrieben, sollte funktional keine Veränderung bewirken. Falls es nach "git pull" jetzt zu Fehlern kommt, bitte bescheid geben.


    Ausserdem habe ich unter https://github.com/herrnst/script.xbmc.lcd/wiki ein bisschen Doku zu der Geschichte hinterlegt (Top-Post ist angepasst).


    Grüße,
    Daniel

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Das Addon wird im Laufe der nächsten (noch zu definierenden) Zeit die Unterstützung für die Extra-Funktionalitäten der SoundGraph LCDs sowie mdm166a Displays erhalten.

    Wenn du da die Pictogramme (Icons) ausserhalb des Textfeldes meinst, da ist bei LCDproc eine universelle Lösung geplant.
    Das wird dann eine neue Funktionen für die Clients geben, mit denen diese Pictogramme dann per Name geändert werden können.
    Es soll wohl Anfang nächsten Jahres so weit sein.

    Gruss
    SHF


  • danke für dieses addon, damit sind endlich die falschen Encoding verschwunden
    ... die Progressbar besteht jetzt aus Blöcken und nicht mehr aus irgendwelchen Zeichen


    ein Problem habe ich dennoch



    [IMG:http://farm9.staticflickr.com/8334/8102456176_013c78f1d0.jpg]


    das PlayIcon ist nicht in der vierten Zeile plaziert, sondern in der ersten und überdeckt die Schrift


    Auszug aus der .xbmc/userdata/LCD.xml

    Code
    1. <video>
    2. <line>$INFO[System.Date(dd mmm yyyy)] $INFO[System.Date(ddd)] $INFO[System.Time]</line>
    3. <line>$INFO[VideoPlayer.Title]</line>
    4. <line>$INFO[LCD.ProgressBar]</line>
    5. <line>$INFO[LCD.PlayIcon] $INFO[Player.Time] / $INFO[Player.Duration]</line>
    6. </video>



    Ist der Support für mehr als 4 Zeilen schon im addon enthalten, oder ist es nur Zufall das ich die vollen 7 Zeilen nutzen kann?
    Mit dem LCD-Support im Core von XBMC, war dies nämlich nicht möglich.


    grüsse

    Gentoo - Linux-3.12 - VDR-2 - XBMC-13_alpha
    ASRock 890GM Pro3 - Athlon II X3 415e - A-Data 8GB - Radeon HD6450 (OSS-Treiber + uvd) - 1x SanDisk SSD Ultra Plus 128GB - 2x Western Digital WD30EZRX 3TB - Alpahcool Display - Atric IR+ Harmony One