XXV: EPG-Daten kastriert wg. Umlauten?

Hallo!

Ich bin erst seit etwa einer Woche am Start mit VDR und habe ein paar Probleme mit XXV.

Das größe davon ist, dass die EPG-Daten beim Übertragen in die Datenbank ziemlich kastriert werden, und zwar endet jeder String spätestens am ersten Umlaut (äöüß), alles was danach gekommen wäre fehlt.

Der Server auf dem VDR und XXV laufen ist ein reines Unicode-System (-> http://gentoo-wiki.com/HOWTO_M…_system_use_unicode/utf-8). Wenn ich die epg.data mit less/cat/vim betrachte, sehen die Umlaute alle sauber aus, im OSD selbst werden sie auch korrekt dargestellt, also das Problem besteht wohl konkret in XXV.

Ich habe schon versucht, LANG die ganzen LC_*-Variablen aufs Geratewohl durch de_DE.iso-8859-1 zu ersetzen und dann XXV zu starten, aber das hat auch nichts gebracht. Bin mir auch nicht sicher, ob ich dafür vielleicht auch diese Locales installiert haben muss.

Mein Standardoutput von locale ist jedenfalls:

LANG=en_US.utf8
LC_CTYPE=de_DE.utf8
LC_NUMERIC=de_DE.utf8
LC_TIME=de_DE.utf8
LC_COLLATE=de_DE.utf8
LC_MONETARY=de_DE.utf8
LC_MESSAGES=en_US.utf8
LC_PAPER=de_DE.utf8
LC_NAME=de_DE.utf8
LC_ADDRESS=de_DE.utf8
LC_TELEPHONE=de_DE.utf8
LC_MEASUREMENT=de_DE.utf8
LC_IDENTIFICATION=de_DE.utf8

...und locale -a sagt:

C
de_DE
de_DE@euro
de_DE.utf8
en_US
en_US.utf8
POSIX

Ich hoffe, ihr könnt mir da weiterhelfen. Vielen Dank im Voraus!

Chacabaou

Okay, ich musste in der Zwischenzeit peinlicherweise feststellen, ich die ziemlich veraltete Version 0.60 aus dem gentoo-de Portage-Overlay benutzt hab.

Nachdem Upgrade (bzw. war's eine Neuinstallation) bin ich zwar ein nicht erwähntes Problem (völlig kaputte Umlaute in der deutschen Übersetzung) losgeworden, aber das Problem mit dem EPG besteht unverändert.

Sowohl interessant als auch verwirrend finde ich dabei: Unter "Jetzt läuft" wird ja links (im snow-skin) immer das Dropdown mit den Channels angezeigt, wobei auch die Gruppen aufgelistet. Komischerweise wird auch der erste Gruppenname (also allgemein "Channels") übersetzt, und dort findet die "Kastration" auch statt, also steht dort immer nur "Kan".

Hofft immer noch auf Hilfe,
Chacabaou

Hmmm. Das wäre schon sehr komisch.

Warum würdest du meine Locales ausschließen? Wie sieht dein Environment denn diesbezüglich aus?

Und wenn du bei dir im Terminal alles auf de_DE@euro (<- das müsste doch ISO sein?) und dort xxvd startest, nachdem du die EPG-Tabelle geleert hast? Bringt das auch keine Besserung?

Ich war mir gerade nicht sicher, ob ich das in der verzweifelten Gesamtsituation tatsächlich so ausprobiert habe, also bin ich's jetzt nochmal genau durchgegangen, mit dem gleichen Fehlverhalten im Ergebnis.

Für's Protokoll, meine Ausgabe von locale war dann:

LANG=de_DE@euro
LC_CTYPE=de_DE@euro
LC_NUMERIC=de_DE@euro
LC_TIME=de_DE@euro
LC_COLLATE=de_DE@euro
LC_MONETARY=de_DE@euro
LC_MESSAGES=de_DE@euro
LC_PAPER=de_DE@euro
LC_NAME=de_DE@euro
LC_ADDRESS=de_DE@euro
LC_TELEPHONE=de_DE@euro
LC_MEASUREMENT=de_DE@euro
LC_IDENTIFICATION=de_DE@euro
LC_ALL=

...und ausgeführt habe ich (man beachte LANGUAGE

export LANG="de_DE@euro";cd /opt/xxv/bin/;./xxvd --configfile /etc/xxv/xxvd.cfg --logfile /var/log/xxvd.log --pidfile /var/run/xxvd.pid --docudir /opt/xxv/share/xxv/doc/ --poddir /opt/xxv/share/xxv/doc/ --htmldir /opt/xxv/share/xxv/skins/ --contrib /opt/xxv/share/xxv/contrib --newsmods /opt/xxv/lib/xxv/XXV/OUTPUT/NEWS --newstmpl /opt/xxv/share/xxv/news --moduledir /opt/xxv/lib/xxv/XXV/MODULES --verbose 3

misterbighh: Ziemlich genau das meinte ich mit meinem vorigen Post.

PS.: Das weiter oben erwähnte Problem mit den Channelgroups (bzw. die aus meiner Sicht seltsame Tatsache, dass dort auch bei Umlauten abgehackt wurde) hat sich übrigens aufgeklärt: Die Gruppen werden ja genauso wie die EPG-Daten in der DB gespeichert.
Das nährt aber doch wieder den Verdacht, dass es ein MySQL-Problem ist, denn: Wenn XXV ansonsten überall einwandfreie Übersetzungen macht, und nur Channels->Kanäle kaputtmacht, kann es ja schlecht am Prozedere des "EPG-Daten-Einlesens" liegen.

Ich würde ehrlichgesagt nicht sonderlich viel erwarten, weil es "an sich" ja funktioniert. Aber ich probiers aus und werde gleich berichten.

EDIT: Da kam leider gar nichts hilfreiches raus...auch nicht mit level 99.

Der Browser kann es auf keinen Fall sein, aber MySQL hab ich wie gesagt auch schon im Auge. Wobei ich auch nicht wüsste, was daran falsch sein könnte.

Die Serverversion ist 5.* (und damit ziemlich standfest in Charsets) und komplett auf Unicode konfiguriert. Wie ist das bei dir misterbighh?

Bin zwar nicht sicher, ob du davon den Screenshot wolltest, aber hier ist er einfach mal.

[Blockierte Grafik: http://img247.imageshack.us/img247/6733/xxvumlautfehlerrz8.th.jpg]

Man müsste jetzt mal die SQL-Queries von XXV kriegen (wie?), um vielleicht zu sehen, dass dort zwar auch kaputte Umlaute aber immerhin vollständige Strings drin sind. Wobei es mich schon sehr erstaunen würde, wenn MySQL auf kaputte Sonderzeichen in Strings mit abhacken reagiert.