vdr-plugin-live mit OSD-Patch - Encoding Problem

chessplayer · 10. Mai 2014

Hallo zusammen,

auf bitten des Erstellers des Threads [live] Patch für OSD ohne Ausgabeplugin mache ich hier mal ein neues Thema auf, für den Fall, dass andere das gleiche Problem haben, wie ich.

Ausgangssituation

Zum Testen habe ich Folgendes getan: Für meine ARMv5 Kirkwood-Boxen (Pogoplug, Dockstar, GoFlex Net/Home) habe ich einen headless VDR auf sehr neuem Stand gebaut. Dazu habe ich, ähnlich wie in diesem Thread erläutert, das yaVDR testig-vdr-dev PPA als Source-Quelle eingebunden und anschließend die Pakete für ARM auf Debian Wheezy 7.5 gebaut und installiert. Alles läuft soweit zufriedenstellend. Zu meiner Freude habe ich dann festgestellt, dass Lars (= mini73 hier aus dem Portal) offenbar in das Paket für das vdr-plugin-live sogar den Patch aus dem ersten Link oben eingebaut hat und es somit zur Verfügung steht.

Frage

Bei mir ist es nun so, dass ich das System auf dem ARM-Rechner komplett auf Deutsch laufen habe und auch mein Ubuntu auf meinem Hauptrechner auf Deutsch ist, was dazu führt, dass, wie erwartet, mein Live-Plugin auch alles auf Deutsch darstellt mit korrekten Umlauten. Nur das OSD im Live zeigt die Umlaute so an, als wären sie ISO-latin1 codiert (o.ä.) und nicht, wie der Rest, UTF8.

Zur Verdeutlichung der Situation habe ich mal ein Bild angehängt. Im Gegensatz dazu zeigt das im Thread zum Patch verlinkte Bild des Erstellers ja, dass es auch funktionieren kann (da werden die Umlaute überall korrekt dargestellt). Weiß jemand, ob ich irgendeine VDR-spezifische Umgebungsvariable setzen muss, damit das passt, oder ob man irgendetwas anderes tun muss?

Danke im Voraus für Euer Interesse und Eure Hilfe,

chessplayer

Nachtrag:

Ich bekomme z.B.

Code

└──> echo $LANG
de_DE.UTF-8

und als Auszug aus dem syslog:

Code

May 10 17:24:20 wheezy-VDR user.info vdr: [3115] VDR version 2.1.6 started
May 10 17:24:20 wheezy-VDR user.info vdr: [3115] switched to user 'vdr'
May 10 17:24:20 wheezy-VDR user.info vdr: [3115] codeset is 'UTF-8' - known
May 10 17:24:20 wheezy-VDR user.debug vdr: [3115] found 1 locales in /usr/share/locale

Habe aber dennoch zur Sicherheit in /etc/default/vdr noch eingetragen:

Code

VDR_LANG=de_DE.UTF-8

Das holt er sich zwar normalerweise aus dem config_loader.sh Skript, was vom daemon-Skript aufgerufen wird, aber sicher ist sicher ...

All dies nützt leider nichts.

rechner · 10. Mai 2014

HI,

was hast du denn für einen Browser?

Wenn du einmal auf Menu gedrückt hast und dann mal im Browser folgendes eingeben
http://keller:8008/osd.xml (Server und port musst du natürlich anpassen). Dann sollte er dir xml anzeigen. Sind da die Umlaute bereits falsch?
Wenn du dann rechte Maustaste auf das Dokument machst und dann Seiteninformationen drückst, steht dann dort was von utf-8 bei Kodierung?

gruss
Rechner

chessplayer · 10. Mai 2014

Hallo Rechner,

zunächst: das Umlaut-Problem habe ich mit Firefox und Chrome und ebenso auf meinem Android-Tablet mit Chrome. Und ja, die Umlaute sind bereits im XML falsch:

Code

<div class="osd" data-time="-418607296">
  <div class="osdTitle">VDR</div>
  <div class="osdItems">
    <div class="osdItem selected"> 1 Programm</div>
    <div class="osdItem"> 2 KanÃ¤le</div>
    <div class="osdItem"> 3 Timer</div>
    <div class="osdItem"> 4 Aufzeichnungen</div>
    <div class="osdItem"> 5 Resume Output</div>
    <div class="osdItem"> 6 Streamdev Verbindungen</div>
    <div class="osdItem"> 7 Suche</div>
    <div class="osdItem"> 8 Schnellsuche</div>
    <div class="osdItem"> 9 ProgrammfÃ¼hrer</div>
    <div class="osdItem">   Timer-Konflikte</div>
    <div class="osdItem">   Einstellungen</div>
    <div class="osdItem">   Befehle</div>
  </div>
  <div class="osdButtons">
    <div class="osdButtonRed">Aufnehmen</div>
    <div class="osdButtonGreen">Audio</div>
    <div class="osdButtonYellow">Pause</div>
    <div class="osdButtonBlue">Wiedergabe</div>
  </div>
</div>

Alles anzeigen

Nicht nur das, im Seitenkopf steht

Code

Mit dieser XML-Datei sind anscheinend keine Style-Informationen verknüpft. Nachfolgend wird die Baum-Ansicht des Dokuments angezeigt.

Ich würde gerne zeigen, wie der Seitenquelltext aussieht, aber leider behält selbst der Code-Block hier nicht das bei, was darin steht. Daher hier nur Folgendes für Menüeintrag 2 Kanäle, wobei ich hier jeweils händisch ein Leerzeichen nach dem Ampersand eingefügt habe, da der Editor sonst die gleichen Ersetzungen vornimmt:

Code

...
<div class="osdItem"> 2 Kan& #195;& #164;le</div>
...

Es gibt keinen XML-Header (= Style Informationen)! Das könnte natürlich mit das Problem sein, oder?

Dann noch eine weitere Frage: weshalb gibt es für zweistellige Menüeinträge (also ab 10) keine Nummer mehr, die angezeigt wird? Das setzt sich nämlich auch in den Untermenüs entsprechend fort ...

Schönen Gruß,

chessplayer

mini73 · 10. Mai 2014

Zitat

Dann noch eine weitere Frage: weshalb gibt es für zweistellige Menüeinträge (also ab 10) keine Nummer mehr, die angezeigt wird? Das setzt sich nämlich auch in den Untermenüs entsprechend fort ...

Das ist der fehlende menuselections-Patch. Der ist nicht im vdr 2.1.6 Paket.

Bei mir sind die Umlaute in Ordnung.

Lars.

rechner · 10. Mai 2014

Kannst du mal folgende Zeile in der Datei osd_status.cpp ändern:

Code

Zeile 136
	return "<?xml version=\"1.0\" encoding=\"utf-8\" ?><div class=\"osd\" data-time=\"" + mystream.str() + "\">" + GetTitleHtml() + GetItemsHtml() + GetTextHtml() + GetMessageHtml() + GetButtonsHtml() + "</div>";

gruss
Rechner

chessplayer · 10. Mai 2014

Hallo zusammen,

ich werde morgen mal danach schauen.

Lars: was bedeutet "bei mir"? Ubuntu-System mit Eurem testing-vdr-dev als PPA eingebunden?

Zunächst mal danke für Eure Tips.

chessplayer

Gesendet von meinem GT-N8010 mit Tapatalk

mini73 · 11. Mai 2014

Bei mir läuft ein vdr 2.1.6 wie der in testing-vdr-dev unter Ubuntu Precise und getestet hab ich mit Safari auf einem iPad mini. Da werden die Umlaute korrekt angezeigt.

Ich hab gerade keinen Zugriff auf den live-Code. Beinhaltet die Änderung, dass explizit das encoding auf utf8 gesetzt wird?
Ein diff wäre hilfreicher.
Morgen kann ich da auch mal reinschauen.

Lars.

chessplayer · 11. Mai 2014

Hallo Rechner, Lars,

die Änderung in osd_status.cpp habe ich gemacht, schön mit dpkg-source --commit den Patch erzeugt und das Paket neu gebaut. Der String ist dann im Seitenquelltext drin, er bewirkt aber leider nichts (außer, natürlich, dass der String tatsächlich im Seitenquelltext zu finden ist). Alles andere, inklusive der Meldung über die fehlenden Style-Informationen, bleibt gleich.

Habe dann mal den Seitenquelltext gespeichert und aus einer anderen xml-Datei den Vorspann inkl. DOCTYPE und xmlns in die Datei in die Datei kopiert. Damit sind die Style-Informationen dann vorhanden, aber die numeriche Unicode-Notation bleibt (natürlich) erhalten. Nun ist mir nur nicht klar, ob die erst im Browser entsteht oder eben bereits in den GetXYZHtml() Methoden (die ich noch nicht angeschaut habe). Eigentlich vermute ich eher letzeres... Dazu wäre es natürlich gut, wenn ich wüsste, wo genau die Datei osd.xml auf dem Server zu finden ist, damit man da mal direkt mit einem Texteditor reinschauen kann.

Wie dem auch sei, jetzt ist es definitiv zu spät, um weiter darüber nachzudenken. Vielleicht hilft etwas Schlaf ja weiter ...

Bis morgen,

chessplayer

rechner · 11. Mai 2014

Hi,

die fehlenden styleinformationen sind ok. Er sagt dir damit nur, dass er ggf. Ein xslt erwartet, der aus xml html macht. Ein browser mag am libsten html. Ist hier also unrelevant.

Lars
Es war nur ein versuch,ein formal gültiges xml zu erzeugen . Muss aber nicht sein.

Die umlaute werden alle encodiert. Das ist auch richtig so.
Ich glaube, du hast noch irgendwo ein problem in deinem system.

Die osd.xml gibt es nicht real. Die wird dynamisch erzeugt. Als framework wird tnt benutzt, kannte ich vorher auch nicht .
Du könntest mal versuchen, eine xml datei in das plugin/live Verzeichnis zu legen und das mal über live aufzurufen, aber richtig bringen wid das auch nichts.

Gruss
Rechner

mini73 · 11. Mai 2014

In UTF-8 hat das kleine ä den Code 0xC3A4. Die EncodeHtml-Routine geht einfach nur Byte für Byte durch den String, der in diesem Fall ein UTF-8-String ist.
Das bedeutet, dass die einzelnen Bytes auseinandergerissen werden. Der Browser kann die natürlich nicht wieder zusammensetzen, um daraus ein UTF-8-Symbol zu machen.

Mal gucken, ob es in den cxxtools oder tntnet schon eine Routine gibt, die einen UTF-8-String in HTML codieren kann. Bzw., wenn der vdr in UTF-8 läuft, ist es fraglich, ob da überhaupt etwas codiert werden muss.
Mal schauen...

Lars.

mini73 · 11. Mai 2014

Probiere mal folgenden Patch. Die extra Zeile mit dem xml-Header hab ich da auch drin.
Letztendlich wird jetzt geprüft, ob der vdr mit UTF-8 läuft und dann werden nur noch die Sonderzeichen <, >, & und " codiert. Alles andere wird 1:1 durchgereicht.

Lars.

chessplayer · 11. Mai 2014

Hallo,

der VDR läuft in UTF-8, wie man ja an meinem syslog-Auszug oben sieht.

Nochmals zur nicht-realen XML-Datei: der tnt-Webserver hat also nicht so etwas wie ein "htdocs"-Verzeichnis, so dass man dort die auszuliefernden Dateien anschauen könnte?

Ich habe im übrigen auch mal meine M$ Windoofs VM hochgefahren und geschaut: Sowohl Firefox als auch IE haben den Darstellungsfehler (was natürlich bei dem Quelltext auch zu erwarten ist).

Lars: aus dem kleinen "ä", welches vermutlich mit zwei Bytes codiert ist, nehme ich an, werden also zwei einzelne numerische Unicode HTML-Codes, richtig? Fraglich ist in jedem Fall, warum das bei Dir klappt und bei mir nicht.

Ich suche mal ein wenig weiter ...

Schönen Gruß,

chessplayer

chessplayer · 11. Mai 2014

Zitat von mini73

Probiere mal folgenden Patch. Die extra Zeile mit dem xml-Header hab ich da auch drin.
Letztendlich wird jetzt geprüft, ob der vdr mit UTF-8 läuft und dann werden nur noch die Sonderzeichen <, >, & und " codiert. Alles andere wird 1:1 durchgereicht.

Lars.

Das hat sich mit meinem Post überschnitten. Ich teste mal, danke.

chessplayer

mini73 · 11. Mai 2014

Witzigerweise wird bei mir das ä nicht codiert, es kommt einfach als ä an.
Und bei mir läuft der vdr auch mit UTF-8. Da wird es also noch irgendwo ein Detail geben, das anders ist. Keine Ahnung, welches...

Lars.

chessplayer · 11. Mai 2014

Hallo,

ja, in meiner Ubuntu-VM klappt auch alles bestens. Der einzige Unterschied ist da ja, dass ich direkt Euer Binary Package installiert habe, während ich auf der Dockstar eben Eure Source-Packages nehme und übersetze ...

Habe gerade noch eine Idee. Die teste ich mal und melde mich dann wieder ...

Gruß,

chessplayer

rechner · 11. Mai 2014

Zitat

Nochmals zur nicht-realen XML-Datei: der tnt-Webserver hat also nicht so etwas wie ein "htdocs"-Verzeichnis, so dass man dort die auszuliefernden Dateien anschauen könnte?

Es gibt das Verzeichnis /var/lib/vdr/plugins/live/img (kann bei dir ggf. anders sein). Wenn du dort ein xml reinlegst, kannst du das mit http://server:xxx/img/datei.xml aufrufen.

Rechner

chessplayer · 11. Mai 2014

Zitat von rechner

Es gibt das Verzeichnis /var/lib/vdr/plugins/live/img (kann bei dir ggf. anders sein). Wenn du dort ein xml reinlegst, kannst du das mit http://server:xxx/img/datei.xml aufrufen.

Rechner

Hallo Rechner,

der Pfad stimmt so nicht mehr. Er ist jetzt

Code

/usr/share/vdr-plugin-live/

Außerdem ist es so, dass eine xml-Datei dann (zumindest bei Firefox) nicht über das HTTP-Protokoll angezeigt wird, sondern nach /tmp heruntergeladen und per file-Protokoll angezeigt, was ja auch einen Unterschied macht. In Chrome will er die Datei dann einfach nur runterladen.

Gruß,

chessplayer

rechner · 11. Mai 2014

HI Chessplayer,

Bei mir ist der Pfad halt anders, ich habe ja geschrieben, dass ich keine distri habe, sondern selbst compiliert auf einem debian.

Das mit dem runterladen kann schon sein. Der tnt-webserver wird da kein content type mitsenden. Aber du könntest ja mal die runtergeladenen Date untersuchen, in welcher kodierung die vorliegt.

Ich glaube aber wirklich, dass du auf deinem Server noch irgendein codierungsproblem hast. Ich habe da allerdings auch keine Idee mehr.

gruss
Rechner

chessplayer · 11. Mai 2014

Hallo zusammen,

momentan lasse ich alles nochmal neu bauen, da auf meiner Entwicklungsmaschine die Default-Locale nicht gesetzt war (was jetzt mit "dpkg-reconfigure locales" behoben wurde). Dies nur zur Sicherheit.

Dann ist mir noch etwas aufgefallen: bei irgendwelchen Diskussionen im Forum wurde immer mal wieder erwähnt, dass auch das yaVDR/main PPA eingebunden werden müsse. Dort werden z.B. auch cxxtools bereit gestellt, die ja vom live-Plugin benötigt werden. Ich verwende jedoch durch

Code

apt-get build-dep vdr-plugin-live

die libcxxtools8 und libcxxtools-dev aus dem Debian Repo, die laut apt-cache policy allerdings neuer sind, als die im main PPA bereitgestellten (die ich ja ohnehin sonst übersetzen müsste).

Da aber Lars oben davon sprach, dass er mal schauen wolle, ob es gerade in den cxxtools vielleicht Kodierungsroutinen gibt, frage ich mich, ob da ggf. der Hund begraben sein könnte.

Wenn die Übersetzung durch ist und der VDR neu aufgesetzt gebe ich Bescheid, ob sich etwas geändert hat.

chessplayer

mini73 · 11. Mai 2014

Ältere Versionen von cxxtools hatten komische Bugs drin, die in aktuelleren behoben sind. Deshalb konnten wir nicht die von precise benutzen. Ich glaube, in unstable sind wir sogar noch eine Version weiter, hab da aber kein Überblick. Wichtig ist letztlich nur, dass alle Beteiligten gegen die gleiche Version gebaut sind.

Lars

vdr-plugin-live mit OSD-Patch - Encoding Problem

Jetzt mitmachen!

Teilen

Tags