[ANNOUNCE] CEC Plugin 0.1.0

Die neue Version schmiert bei mir im Anlerndialog ab.

Edit: System ist Arch Linux ARM

https://gist.github.com/CReimer/a721d93857944f5734c8

jepp geht mir unter jessie genauso. FB-Anlerndialog kommt und dann gibts einen segfault.

I got the same segfault on raspian, raspberry pi, as well. Interestingly if I simply wait for the remote key learning to end the CEC functionality works surprisingly well.

This is on raspbian with vdr 2.1.6 and changeset 18:20a5ba3bee27 of cecremote. The TV is a Philips.

Most buttons on the remote work as expected. There are a couple of gotchas that I have encountered so far.
The back button does not work... Kind of a showstopper but my workaround while I have time to troubleshoot it properly is to press the subtitles key. That will give the OSD message "No subtitles available" and will take me out of the menus!

While watching recordings the Stop button does not work. Only way to end the recording is to jump to the end of the recording so that it ends and goes back to live mode again. This is slightly similar to problems I encountered with the cec support for vompclient. The solution there was to announce vdr as a CEC_DEVICE_TYPE_RECORDING_DEVICE instead of a CEC_DEVICE_TYPE_TUNER.

I will continue my test and will also familiarise myself with the plugin code so that I can contribute.

- Magnus

I was a bit quick in mentioning that I could access the menu using the "Find" button on the remote. Apparently the "Find" button generate a CEC_USER_CONTROL_CODE_CONTENTS_MENU that is mapped to the Setup menu. Since the "Find" button is the only available button on my Philips remote i experimented changing the mapping to kMenu instead of kSetup.

Also adding the a mapping for the press of the back button, CEC_USER_CONTROL_CODE_EXIT, to kBack made the back button functional.

The following is the diff of the changes made:

diff -r 20a5ba3bee27 cecremote.cc
--- a/cecremote.cc	Mon Feb 16 17:46:18 2015 +0100
+++ b/cecremote.cc	Tue Feb 17 20:47:30 2015 +0100
@@ -357,7 +357,8 @@
     mDefaultKeyMap[CEC_USER_CONTROL_CODE_LEFT_DOWN          ][1] = kDown;
     mDefaultKeyMap[CEC_USER_CONTROL_CODE_ROOT_MENU          ][0] = kMenu;
     mDefaultKeyMap[CEC_USER_CONTROL_CODE_SETUP_MENU         ][0] = kSetup;
-    mDefaultKeyMap[CEC_USER_CONTROL_CODE_CONTENTS_MENU      ][0] = kSetup;
+    mDefaultKeyMap[CEC_USER_CONTROL_CODE_CONTENTS_MENU      ][0] = kMenu;
+    mDefaultKeyMap[CEC_USER_CONTROL_CODE_EXIT               ][0] = kBack;
     mDefaultKeyMap[CEC_USER_CONTROL_CODE_NUMBER0            ][0] = k0;
     mDefaultKeyMap[CEC_USER_CONTROL_CODE_NUMBER1            ][0] = k1;
     mDefaultKeyMap[CEC_USER_CONTROL_CODE_NUMBER2            ][0] = k2;

- Magnus

I have done some investigations on why the Stop key does not work as intended on my setup. Turns out the Stop key is interpreted as a combo key. If no other key is pressed within a timeout the key press will be registered by libcec.

The timeout is configurable by setting iComboKeyTimeoutMs field of CEC:libcec_configuration. By default the timeout is 1000ms.

The Stop key is prevented to be processed since there is a check for key.duration to be equal to zero. I am not sure on the best way to handle this yet. A dirty workaround is to check for:

if ((key.keycode >= 0) && (key.keycode <= CEC_USER_CONTROL_CODE_MAX) &&
    ((key.duration == 0 || key.duration > 1000)))

Hints are welcome to solve it in a more proper way.

- Magnus

Ich hätte da mal was zu meckern, bitte nicht böse sein:

über den Sinn und Unsinn von VDR-Plugin-Configs in XML-Dateien kann man streiten, aber wenn man das macht, nimmt man dann einen XML-Parser, der seit 5 Jahren nicht mehr gewartet wird und die komplette DOM/SAX-Api unterstützt?
Es geht doch nur drum ein Config zu lesen, da hätte man doch auch was schlankes/performates nehmen können?

Hier gibts eine schöne Entscheidungshilfe:
http://stackoverflow.com/quest…-parser-should-i-use-in-c

Ich würde dann bei TinyXML oder PugiXML landen, was übrigens auch vom Satip-Plugin benutzt wird.

Zitat von Ulrich Eckhardt

Wo hast du denn die Info her, das der Code seit 5 Jahren nicht mehr gewartet wird?

http://xerces.apache.org/xerces-c/releases_plan.html

Zitat von Ulrich Eckhardt

Ich schaue mir die noch mal an. Falls die Umstellung nicht zu aufwendig ist, stelle ich das noch auf was schlankeres um.

0.1.1 funktioniert jetzt gar nicht mehr. Neuer Backtrace: https://gist.github.com/CReimer/ca04f30d0afc3b601636

Zitat von Ulrich Eckhardt

Kannst du mal schauen, ob das Plugin noch was ins Logfile geschrieben hat? Das schaut mir danach aus, als hättest du kein CEC-Adapter, bzw der Adapter wird nicht erkannt.

Ja, da war was in der Richtung. Ich habe das System im Moment nicht lauffähig. Wenn der genaue Eintrag wichtig ist muss ich den RPi erst wieder anstöpseln.

Zitat von Ulrich Eckhardt

PugiXML ist aber von der API schlanker und eleganter als xerces, die nächste Version kommt dann mit PugiXML, das macht mir für die konfigurierbaren Keymaps dann das
Leben auch leichter

Dann bekommst du von mir relativ flott einen Patch, der dann auch TinyXML unterstützt. vdr-satip unterstützt auch beide, TinyXML ist aber in den Arch Repositories und PugiXML nicht.

Zitat von Ulrich Eckhardt

PugiXML ist aber von der API schlanker und eleganter als xerces, die nächste Version kommt dann mit PugiXML, das macht mir für die konfigurierbaren Keymaps dann das
Leben auch leichter

Zitat von Copperhead

Dann bekommst du von mir relativ flott einen Patch, der dann auch TinyXML unterstützt. vdr-satip unterstützt auch beide, TinyXML ist aber in den Arch Repositories und PugiXML nicht.

Ich würde auch für TinyXML voten. Ich benutzte Yocto/Openembedded, TinyXML geht da OOTB. Das gilt auch für Raspbian. PugiXML wäre aber auch ok, dann würde ich nen Recipe bauen.

Ich würde auch für TinyXML voten da dies auch von Rasbian unterstützt wird.

Wir können uns auf TinyXML einigen

Im satip-Plugin ist das hier der einzige Unterschied:

#ifdef USE_TINYXML
     TiXmlDocument doc;
     char *xml = MALLOC(char, len + 1);
     memcpy(xml, ptrP, len);
     *(xml + len + 1) = 0;
     doc.Parse((const char *)xml);
     TiXmlHandle docHandle(&doc);
     TiXmlElement *descElement = docHandle.FirstChild("root").FirstChild("device").FirstChild("friendlyName").ToElement();
     if (descElement)
        desc = descElement->GetText() ? descElement->GetText() : "MyBrokenHardware";
     TiXmlElement *modelElement = docHandle.FirstChild("root").FirstChild("device").FirstChild("satip:X_SATIPCAP").ToElement();
     if (modelElement)
        model = modelElement->GetText() ? modelElement->GetText() : "DVBS2-1";
#else
     pugi::xml_document doc;
     pugi::xml_parse_result result = doc.load_buffer(ptrP, len);
     if (result) {
        pugi::xml_node descNode = doc.first_element_by_path("root/device/friendlyName");
        if (descNode)
           desc = descNode.text().as_string("MyBrokenHardware");
        pugi::xml_node modelNode = doc.first_element_by_path("root/device/satip:X_SATIPCAP");
        if (modelNode)
           model = modelNode.text().as_string("DVBS2-1");
        }
#endif

Zitat von Ulrich Eckhardt

Jetzt weiss ich wieder warum ich Xerces verwendet hatte, der Parser ist fast überall dabei. Ich will keine zwei Parser unterstützen, das bläht den Code unnötig auf und ich müsste die beide testen.
Kann man sich auf PugiXML einigen? Ansonsten schmeisse ich meine Änderungen wieder aus dem Repository und es bleibt bei Xerces.

TinyXML ist auch überall dabei. In deinem Repo sehe ich gerade, dass du schon auf PugiXML umgestellt hast, dann lass das einfach so. Inzwischen gibts es auch TinyXML-2, eigentlich sollte man sowieso das nehmen für neue Implementierungen.