Frage zum Restful API Plugin

TheChief · 5. April 2012

Mal eine generelle Frage:
Wäre es damit möglich, beispielsweise mittels HTML/AJAX oder Python, eine Art graphtft-Ersatz zu entwickeln? Also was ich mir vorstelle: Uhrzeit, Kanal und Logo anzeigen, Laufende Sendung anzeigen, Start und Endzeit und eventuell einen Fortschrittsbalken. Gleiches für Aufnahmen. Mehr brauch ich eigentlich nicht.

Grund:
Das Graphtft-Plugin will bei mir nicht mehr so richtig. Siehe hier. Ausserdem ist es langsam in die Jahre gekommen und die ewige Patcherei des VDR muss ja nun auch nicht mehr sein. Das VDR OSD wird durch den Patch auch langsamer.

Grüsse
TheChief

gda · 5. April 2012

Zitat von TheChief

Wäre es damit möglich, beispielsweise mittels HTML/AJAX oder Python, eine Art graphtft-Ersatz zu entwickeln? Also was ich mir vorstelle: Uhrzeit, Kanal und Logo anzeigen, Laufende Sendung anzeigen, Start und Endzeit und eventuell einen Fortschrittsbalken. Gleiches für Aufnahmen. Mehr brauch ich eigentlich nicht.

Klar, das geht, das war ja mein ursprünglicher Hintergedanke dabei. Aktuell müsstest du allerdings pollen, weil restful keinen push macht.

Wobei allerdings der V_R gerade eine App für Android geschrieben hat, die direkt mit graphtft zusammenarbeitet. So ein China-Tablet ist ja inzwischen günstiger als ein TFT, aber du willst ja weg von Graphtft.

Gerald

TheChief · 5. April 2012

Wenn ich wüsste, wo das Problem bei mir liegt, würd ich auch weiterhin graphtft einsetzen. Mich hat aber schon immer die Verlangsamung des OSD gestört. Ich brauch mein kleines TFT im Gehäuse eigentlich nur als Informationsquelle für Uhrzeit
und laufende Sendung/Aufnahme. Die Touchfunktion nutze ich nich und die Menüs müssen mir auch nicht angezeigt werden.

Ein kleines Python-Skript unter openbox laufen lassen, um die Infos anzuzeigen, wäre also nicht verkehrt. Wer programmierts mir oder kann mir ein kleines Beispielskript posten? Mit Python hab ich mich noch nie beschäftigt

seahawk1986 · 5. April 2012

Ich hatte vor 8 Monaten mal angefangen: https://github.com/seahawk1986/pyrestfulapi

Problem war damals allerdings die zuverlässige Anzeige des aktuellen Senders (und damit der aktuellen Sendung): https://bugs.yavdr.com/issues/572 / bzw. http://linuxtv.org/pipermail/vdr/2011-August/025135.html (da scheint sich nichts getan zu haben) - ich habe es auch lange nicht mehr probiert, da graphlcd zusammen mit dem Pearl-DPF genau das tut was es soll.

seahawk1986 · 5. April 2012

Ich muss mal sehen, ich hatte für meine Dockstar noch etwas mit der PIL gebastelt, das regelmäßig den Sender und die aktuelle Sendung vom VDR per restfulapi abgefragt und dann in ein PNG gerendert hat - wenn ich es wiederfinde poste ich es gerne...

TheChief · 5. April 2012

Zitat von seahawk1986

Ich hatte vor 8 Monaten mal angefangen: https://github.com/seahawk1986/pyrestfulapi

Problem war damals allerdings die zuverlässige Anzeige des aktuellen Senders (und damit der aktuellen Sendung): https://bugs.yavdr.com/issues/572 / bzw. http://linuxtv.org/pipermail/vdr/2011-August/025135.html (da scheint sich nichts getan zu haben) - ich habe es auch lange nicht mehr probiert, da graphlcd zusammen mit dem Pearl-DPF genau das tut was es soll.

Danke, ich schau mal rein. Wird wohl Zeit sich mal mit Python zu beschäftigen.

Zitat von seahawk1986

Ich muss mal sehen, ich hatte für meine Dockstar noch etwas mit der PIL gebastelt, das regelmäßig den Sender und die aktuelle Sendung vom VDR per restfulapi abgefragt und dann in ein PNG gerendert hat - wenn ich es wiederfinde poste ich es gerne...

Das wäre natürlich noch besser.

Grüsse
Thechief

mini73 · 5. April 2012

Moin!

Ich bin gerade dabei, dbus2vdr um einen OSD-Provider zu erweitern, der das komplette OSD in ein PNG schreibt und dann ein DBus-Signal mit dem Dateinamen sendet.
Jetzt muss ich aber erst mal Qt lernen, damit ich auch ein Demoprogramm habe, das was anzeigen kann.

Nachteil: Der OSD-Provider des Ausgabeplugins wird überschrieben, im vdr kann es immer nur einen Provider zur Zeit geben.
Ist auch eigentlich eher eine Spielerei, um zu sehen, ob das überhaupt geht. Momentan empfängt meine Qt-App noch sehr unzuverlässig die DBus-Signale, obwohl man die ja direkt an Qt-Slots hängen können soll. Na, mal schauen, wie sich das entwickelt...

Vorteil: Das OSD (inkl. Skin usw.) wie man es kennt in einer externen Anwendung gesteuert durch die normale Fernbedienung.

Lars.

TheChief · 5. April 2012

Klingt zwar auch interessant, wäre aber für mein Vorhaben eigentlich oversized. Das komplette OSD brauch ich eigentlich nicht, sondern nur wenige Informationen. Aber bleib dran!

seahawk1986 · 5. April 2012

So, her ist noch das Skript (ist an einem Abend zum Spielen mit dem Pearl-Display entstanden, daher nicht besonders ausgearbeitet): http://paste.ubuntu.com/915931/
Es braucht IIRC eine recht aktuelle Version vom restfulapi-Plugin (wegen einigen Abfragen) - aber wenn du die draw_* Funktionen rauslässt hast du praktisch alles um an die nötigen Infos zu kommen - die Frage ist nur, wie man sie dann wieder sinnvoll ausgibt...

TheChief · 5. April 2012

Welche Pakete brauch ich denn für das Restful API? oder müsste ich das Makefile auf Debian anpassen?

Hab die Sourcen von github geladen:

cxxtools und tntnet sind installiert (inkl. -dev Pakete).

Code

g++ -g -fPIC -O2 -Wall -Woverloaded-virtual -Wno-parentheses  -fPIC -fPIC -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"restfulapi"' -I/usr/src/DVB/linux/include -I../../../include restfulapi.cpp
In file included from restfulapi.cpp:11:
serverthread.h:11:34: error: cxxtools/http/server.h: Datei oder Verzeichnis nicht gefunden
serverthread.h:12:35: error: cxxtools/http/request.h: Datei oder Verzeichnis nicht gefunden
serverthread.h:13:33: error: cxxtools/http/reply.h: Datei oder Verzeichnis nicht gefunden
serverthread.h:14:37: error: cxxtools/http/responder.h: Datei oder Verzeichnis nicht gefunden
serverthread.h:15:32: error: cxxtools/eventloop.h: Datei oder Verzeichnis nicht gefunden
serverthread.h:17:37: error: cxxtools/jsonserializer.h: Datei oder Verzeichnis nicht gefunden
In file included from serverthread.h:22,
                 from restfulapi.cpp:11:
info.h:5:40: error: cxxtools/serializationinfo.h: Datei oder Verzeichnis nicht gefunden
In file included from info.h:6,
                 from serverthread.h:22,
                 from restfulapi.cpp:11:
tools.h:19:29: error: cxxtools/string.h: Datei oder Verzeichnis nicht gefunden
tools.h:20:32: error: cxxtools/utf8codec.h: Datei oder Verzeichnis nicht gefunden
In file included from info.h:6,
                 from serverthread.h:22,
                 from restfulapi.cpp:11:
tools.h:199: error: ‘String’ in namespace ‘cxxtools’ does not name a type
tools.h:224: error: ‘cxxtools::http’ has not been declared
tools.h:224: error: expected ‘,’ or ‘...’ before ‘&’ token
In file included from info.h:6,
                 from serverthread.h:22,
                 from restfulapi.cpp:11:
tools.h:236: error: ‘cxxtools::http’ has not been declared
tools.h:236: error: expected ‘,’ or ‘...’ before ‘&’ token
In file included from info.h:9,
                 from serverthread.h:22,
                 from restfulapi.cpp:11:
../../../include/vdr/status.h:33: warning: ‘virtual void cStatus::ChannelSwitch(const cDevice*, int, bool)’ was hidden
statusmonitor.h:125: warning:   by ‘virtual void StatusMonitor::ChannelSwitch(const cDevice*, int)’
In file included from serverthread.h:22,
                 from restfulapi.cpp:11:
info.h:13: error: ‘String’ in namespace ‘cxxtools’ does not name a type
info.h:20: error: ‘String’ in namespace ‘cxxtools’ does not name a type
info.h:21: error: ‘String’ in namespace ‘cxxtools’ does not name a type
info.h:31: error: ‘String’ in namespace ‘cxxtools’ does not name a type
info.h:32: error: ‘String’ in namespace ‘cxxtools’ does not name a type
info.h:35: error: declaration of ‘operator<<=’ as non-function
info.h:35: error: ‘SerializationInfo’ is not a member of ‘cxxtools’
info.h:35: error: ‘si’ was not declared in this scope
info.h:35: error: expected primary-expression before ‘const’
info.h:36: error: declaration of ‘operator<<=’ as non-function
info.h:36: error: ‘SerializationInfo’ is not a member of ‘cxxtools’
info.h:36: error: ‘si’ was not declared in this scope
info.h:36: error: expected primary-expression before ‘const’
info.h:37: error: declaration of ‘operator<<=’ as non-function
info.h:37: error: ‘SerializationInfo’ is not a member of ‘cxxtools’
info.h:37: error: ‘si’ was not declared in this scope
info.h:37: error: expected primary-expression before ‘const’
info.h:38: error: declaration of ‘operator<<=’ as non-function
info.h:38: error: ‘SerializationInfo’ is not a member of ‘cxxtools’
info.h:38: error: ‘si’ was not declared in this scope
info.h:38: error: expected primary-expression before ‘const’
info.h:40: error: ‘cxxtools::http’ has not been declared
info.h:40: error: expected ‘{’ before ‘Responder’
info.h:41: error: invalid type in declaration before ‘{’ token
info.h:41: warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x
info.h:42: error: expected primary-expression before ‘public’
info.h:42: error: expected ‘}’ before ‘public’
info.h:42: error: expected ‘,’ or ‘;’ before ‘public’
info.h:45: error: ‘cxxtools::http’ has not been declared
info.h:45: error: expected ‘,’ or ‘...’ before ‘&’ token
info.h:45: error: ‘virtual’ outside class declaration
info.h:46: error: ‘virtual’ outside class declaration
info.h:47: error: ‘virtual’ outside class declaration
info.h:48: error: ‘virtual’ outside class declaration
info.h:49: error: expected declaration before ‘}’ token
make: *** [restfulapi.o] Fehler 1

Alles anzeigen

Grüsse

seahawk1986 · 5. April 2012

Zitat von TheChief

cxxtools und tntnet sind installiert (inkl. -dev Pakete).

Welche Versionen?

TheChief · 5. April 2012

Auf meinem Server (Squeeze)

libcxxtools => 1.4.8-3
tntnet => 1.6.3-4

seahawk1986 · 5. April 2012

Ich bin im Paketbau nicht ganz so weit drin wie viele andere im yaVDR-Team, aber wenn ich mir die control-Datei im Git so ansehe, könnte es durchaus sein, dass die zu alt sind - da wird libcxxtools7 gefordert.
(hatten wir heute schonmal: Yavdr few problems)

TheChief · 5. April 2012

Naja gut, dann versuchs ich später nochmal auf meinem anderen System. Kompilierorgien möchte ich mir eigentlich ersparen.

seahawk1986 · 5. April 2012

Eigentlich kannst du dir da doch gleich ein Debian-Paket draus bauen lassen ohne den Compiler von Hand anzuwerfen...

Keine_Ahnung · 6. April 2012

Unter Squeeze brauchts die Quellpakete aus dem yaVDR PPA, bauen aber Problemlos unter Squeeze. Habs hier auch so (mit den yaVDR Paketen) am laufen.

BTW: Nicht vergessen das Live Plugin neu zu bauen.

BTW2: Das Graphlcd Plugin kann auch auf dem Framebuffer ausgeben. Also geht theoretisch auch Graphlcd -> VGA TFT/Displaylink TFT. Ist evtl. nen Versuch wert?

cu

TheChief · 12. April 2012

So, Ostern ist überstanden, da kann ich mich wieder meinem Problem widmen.

Kann man über das Restful API eigentlich auch Nachrichten des VDR empfangen, z.B. die Shutdown-Meldung?

Graphlcd schau ich mir mal an.

Keine_Ahnung · 12. April 2012

Ohne pollen gibts da AFAIK nix. Nachrichten sind ja nur normales OSD was sehr kurzfristig offen ist.

Du könntest das mlist Plugin modifizieren wenn du an die VDR Nachrichten kommen willst.

Wenn dich speziell der Shutdown interessiert kannst du dich bei den shutdown Hooks einklinken, die können mehr als nur den ACPI Timer setzen.

cu

TheChief · 12. April 2012

Ich bin eben noch hin und her gerissen. Ansich gefällt mir ja graphtft so wie es ist. Das einzige, was mich daran stört, ist, dass man erstens den VDR patchen muss, damit es läuft und zweitens das OSD langsamer wird (denke es liegt daran, dass sich der Patch mit in den OSD Code einklinkt). Jetzt hab ich mal kurz ins GraphLCD Plugin reingeschaut, welches ja anscheinend ohne Patch auskommt. Wenn das bei GraphLCD geht, dan müsste es doch bei GraphTFT auch ohne Patch gehen?! Ich überlege jetzt natürlich, ob ich mir was mit dem RestfulAPI zusammenschustere oder ob ich mich mal GraphTFT annehme und das auf Vordermann bringe - mit dem klaren Ziel, dass es schneller wird und ohne patch auskommt.

seahawk1986 · 12. April 2012

Wer würde sich nicht über ein flotteres GraphTFT freuen

Frage zum Restful API Plugin

Jetzt mitmachen!

Teilen