Tester gesucht: XXV und UTF-8

    Hi,


    Die DEV-Version von XXV kann mit r1308 VDR Daten in der Encodierung UTF-8 verarbeiten und anzeigen. Da ich aber noch keinen VDR mit UTF-8 Unterstützung habe, kann ich es nicht komplett austesten.


    Damit des Abwärtskompatibel bleibt muss es in /etc/init.d/xxvd per "xxvd --utf8" gestartet werden.


    Was nicht erfolgt ist eine Encodierung von VDR Daten oder Dateinamen, diese müssen bereits UTF-8 kodiert sein. Ebenfalls zu empfehlen ist das LANGUAGE="de_DE.utf8" in /etc/init.d/xxvd zu setzen.


    Bei der Mirgation der Datenbank könnte folgendes helfen (praktisch ungetestet)
    mysqldump -e xxv > dump.sql
    cat dump.sql | iconv -f latin1 -t utf8 | mysql xxv


    Zum Umbennen der Aufnahmen existiert das Tool "convmv" .


    Falls ich etwas vergessen, habe wäre ich an Hinweisen dazu interessiert.
    Andreas


    Gemäß xxv mit UTF-8-mysql


    In mysql (mysql -uxxv -pxxv xxv):



    bzw gleich eine neue Datenbank ;

    Code
    CREATE DATABASE xxv DEFAULT CHARACTER SET utf8;

    AAAAAAAAh, ist das geil;
    endlich richtige Umlaute....


    Schnell mal ein paar Zeilen,


    System: Gentoo ( was sonst ), per ebuild installiert.
    VDR-1.5.17


    Die Tabellen hab ich mit "alter table...." convertiert.
    Dabei hast Du folgende Tabellen vergessen:
    CHRONICLE EVENTDB SHARE TEMPEPG VERSION


    cat dump.sql | iconv -f latin1 -t utf8 | mysql xxv
    hat bei mir nicht gefunzt, liegt aber wahrscheinlich an meiner Mysql-einstellung:
    ERROR 1153 (08S01) at line 185: Empfangenes Paket ist größer als 'max_allowed_packet' Bytes


    Ich hab dann folgende Tabellen geleert und beim xxv start neu befüllen lassen:
    CHANNELS, CHANNELGROUPS, EPG, OLDEPG, TMPEPG
    Das functionierte ohne Probleme und wird auch mit richtigen Umlauten befüllt und dargestellt.


    Alle Anzeigen in den Skins werden Umlaut-technich richtig dargestellt. :)


    LANGUAGE=de_DE.utf8" gesetzt und xxvd mit --utf8 gestartet worden.


    Nun was nicht (mehr) geht:


    Es werden keine Vorschaubilder mehr in den Aufnahmen angezeigt.
    Vorsichtshalber habe ich die "alten" gelöscht und per vdr2jepg neu erstellen lassen. Narda...


    Logfile: Einträge mit Umlauten werden fehlerhaft erstellt, aber da will ich mich nicht festlegen ob das wieder an meinen System liegt.


    So, das wäre es fürs erste...


    Ich werd das ebuild noch auf den gentoo server legen und in der GEntoo Section ne Info hinterlassen, vielleicht findet sich ja doch noch die eine oder andere Pappnase zum testen ;)


    Cheers :prost2


    Btw, ist mein 777 Posting, ich stell hier mal nen virtuellen Kasten Bier in die Runde :]

    Hi,


    schön zu hören, dass der UTF8 Modus funktioniert.


    Dank für die zusätzlichen Hinweise.


    Die Probleme mit den Vorschaubildern, wundern mich einwenig, da die Dateinamen 1:1 durchgereicht werden. Kann es sein, das nur ein Update des Skins auf den aktuellen Stand fehlt ? Ich werde mir dies aber nochmal anschauen.


    Andreas

    Folgende Fehldarstellung in den Umlauten tritt noch auf:


    Moin Hulk,


    Skin: html


    Medieninhalte -->Aufnahmen


    Wenn ich mich mit dem Mousezeiger über einen (Film)Link befinde/bewege öffnet sich ein Infofenster. Dieser Inhalt wird noch mit gebrochenen Umlauten dargestellt.


    Beim Klick auf den Link wird der Inhalt des Popup-fensters richtig dargestellt.


    Das tritt auch bei meinem Lieblingsskin (blue-flat) auf.


    Cheers :prost2

    Zitat

    Original von hd.brummy
    Wenn ich mich mit dem Mousezeiger über einen (Film)Link befinde/bewege öffnet sich ein Infofenster. Dieser Inhalt wird noch mit gebrochenen Umlauten dargestellt.


    Sind die Daten bzw. der Inhalt der info.vdr bereits im utf-8 Format konvertiert worden ?


    Folgendes könnte zum Konvertieren helfen,

    Code
    #/bin/bash
for FILE in `find /video -name info.vdr` ; do
cp "$FILE" "$FILE.bak"
iconv -t utf8 -f latin1 "$FILE" -o "$FILE.new" 
mv "$FILE.new" "$FILE"
done


    Danach müssen die Aufnahmen in XXV neu eingelesen werden. (?cmd=rupdate oder neustart)

    Naja, ich hab den VDR ja , bedingt durch die immer neuste Version, schon ne ganze Weile auf utf8 zu laufen.


    Um es vielleicht nochmal detailierter zu beschreiben, was nicht hinhaut, noch ein Versuch.


    Am skin blue_flat lässt sich das am besten erklären.


    xxv im Browser anwählen --> oben in der Leiste auf "Aufnahmen" klicken


    Dann erhälst Du zu jeden Film die
    ( Vorschaubild ) ( detailierte Beschreibung ) ( 4 Button )
    hier hauen alle Umlaute hin


    gehe jetzt auf den ( Info ) button (mouseover)
    neben einem Film,dann öffnet sich ein Layer
    !!! hier hauen die Umlaute nicht hin !!!


    klicke jetzt auf den ( Info ) button (mouseklick)
    dann öffnet sich ein neuer grösserer Layer der mit mehr details versehen ist.
    hier stimmen die Umlaute wieder


    Spasshalber mal eine info.vdr mit iconv recodiert und neu eingelesen brachte auch nix ;)


    Beziehen nicht alle 3 Sachen die Information aus der info.vdr , btw aus dem db Eintrag von info.vdr ?


    Cheers :prost2

    Zitat

    Original von hd.brummy
    gehe jetzt auf den ( Info ) button (mouseover)
    neben einem Film,dann öffnet sich ein Layer
    !!! hier hauen die Umlaute nicht hin !!!


    Ich hatte dich schon verstanden, das die Tooltip-Funktion gemeint ist, da Du aber nicht auf die Detailanzeige erwähnt hattest, musst ich erst auf die externen Daten der info.vdr verweisen.


    Die Daten kommen immer aus der Datenbank. Die info.vdr wird nur beim Start oder Update der Daten eingelesen.
    Der einzige Unterschied ist, das die Daten beim Tooltip per AJAX-Request per JSON zum Browser gelangen und bei der Detailanzeige per klassischem HTML-Request. Das Problem müsste eigentlich im Tooltip der EPG-Ansicht genauso auftreten und im Zweifel ein Browser-Bug sein.


    Alle mir zur Verfügung stehenden Browser iceape(mozilla), iceweasel(firefox), opera und ie6 per wine zeigen diese Verhalten nicht.


    Vielleicht hilft es für den AJAX-Request im lib/XXV/OUTPUT/Ajax.pm einen anderen CONTENT-TYPE zugeben. Und das eigentlich korrekte application/json durch ein text/javascript bzw. text/html zu ersetzen.

    Code
    -  $self->{types}->{'json'} = sprintf('application/json; charset=%s',$self->{charset});
+  $self->{types}->{'json'} = sprintf('text/javascript; charset=%s',$self->{charset});


    Andreas

    Moin,


    das ändern des CONTENT-TYPE brachte nix.


    Ich hab jetzt mal mit verschiedenen Version des Moduls JSON rumgespielt.


    Actuell auf Gentoo ist JSON-2.04 # damit gibts Fehldarstellungen
    Update kommt heute, JSON-2.07 # damit gibts Fehldarstellungen


    JSON-1.14 hab ich noch versucht, damit gibts keine Fehldarstellungen, aber die Umlaute werden als SQUARE ( KäseKästchen ) oder Vertical-bar dargestellt.


    Anscheinend ist das von der Versionsnummer von JSON abhängig?


    Welche Version setzt Du denn ein?


    Gib mal kurz Info, dann teste ich das damit mal hier local...


    btw. Du hast natürlich Recht, die Tooltip-Function im EPG ist natürlich auch kaputt, ist mir bisher aber nicht aufgefallen ...

    Persönlich hatte ich noch 1.00-2 am laufen, und damit den 2.xx Zweig nie getestet. Bei 2.0.7 hat mir jetzt folgendes geholfen, was das Problem beheben sollte.
    Es werden wohl die bereits im UTF-8 Format vorliegende Texte doppelt encodiert.


    Diff
    --- Ajax.pm	(Revision 1313)
+++ Ajax.pm	(Arbeitskopie)
@@ -143,7 +140,6 @@
     if($self->{browser}->{Method} ne 'HEAD') {
       if( $self->{outtype} eq 'json' ) {
         if($self->{json}->can('encode')) { # Version 2.0 see http://search.cpan.org/~makamaka/JSON-2.04/lib/JSON.pm#Transition_ways_from_1.xx_to_2.xx.
-          $self->{json}->utf8(1) if($self->{charset} eq 'UTF-8');
           $content = $self->{json}->encode($self->{output});
         } else { # Version 1.0
           $JSON::UTF8=1 if($self->{charset} eq 'UTF-8');

    Hi,


    Leider ist es nicht ausreichend nur diese Zeile zu entfernen, das nie alle Daten vollständig encodiert waren. Dies Tooltip ist nur ein von mehreren Funktionen, welche das Modul AJAX.pm nutzt. Somit ist in Revision 1315 eine erweiterte Version für das Modul AJAX.pm mit UTF-8/JSON-2.x online. Dies sollte die Probleme mit unencodierten bzw. doppelt encodierten Daten beheben.


    Andreas

    Jo,


    1315 funzt auch hier,
    hab nochmal nen snapshot für die gentoo-user bereitgestellt.


    Mal sehen ob ich die Woche dazu komme das startscript um ne automagische Erkennung auf utf8 zu erweitern und dann --utf8 beim starten mit zu übergeben.


    Der "gemeine User" ist ja immer ein bisschen überfordert mit dem setzen von irgendwelchen Parametern.
    Der will nur auspacken, anschalten und dann muss das funzen ....


    ;)

    Zitat

    Original von hd.brummy


    Der will nur auspacken, anschalten und dann muss das funzen ....


    ;)


    Genauso möcht ich es haben ;)

    Gruß Tom


    99% der ComputerFehler sitzen zwischen Tastatur und Rückenlehne :schiel

    So da es ja jetzt das 1.6 ebuild für gentoo gibt habe ich auch gleich mahl xxv mit utf8 getestet.
    Habe da jetzt aber doch ein par Merkwürdigkeiten.
    So ist das "ä" in "läuft" richtig dargestellt das selbe Zeichen im "März" jedoch nicht. Das ganze im html Skin in der Übersicht mit dieser Zeile " Was läuft am Dienstag den 25.März.2008 um 16:00 Uhr"


    Auch in der Übersicht der Aufzeichnungen werden mahl Umlaute richtig dargestellt mahl nicht. Beim "Mause over" Passt es dann immer so auch in der Detailansicht.


    Selbst nach dem umbenennen mit xxv passt es nicht. Bei "Keine Zeit für Nüsse" wird das zweit "ü" als Rechteck angezeigt. Des weiteren wird das Sonderzeichen in "Die fabelhafte Welt der Amélie" als Rechteck dargestellt


    Edit
    Die beschriebenen Probleme treten nicht mit dem deltap Skin auf.

    @ swer


    schreib mal bitte dazu, welche Version von XXV Du einsetzt.


    Es geht hierbei um eine der Versionen die in diesem Tread --> xxv -mit utf8 Support // Tester gesucht anonciert wurde.


    Bedenke auch das Du das initscript per etc-update actualisieren musst.
    Und ja, das System sollte schon auf utf8 laufen


    locale | grep LANG


    sollte dann das bringen.
    LANG=de_DE.utf8

    @ Hulk


    uiui, ich weiss nicht ob es wieder an dem nicht angepassten skin liegt
    oder ob sich da wirklich nen fetter bug ins Ajax.pm eingeschlichen hat.


    skin blue_flat ( als beispiel der das ajax feature nutzt )
    XXV -- > Aufnahmen --> Button ( Aufnahmen bearbeiten ) klicken


    dann geht der layer auf zum berabeiten der Filmdaten ( info.vdr)


    -r1308


    - Titel der Aufnahme
    - Lebenszeit
    - Priorität
    - Kanal
    - Video
    - Audio
    - Schnittmarken


    -r1315 wird der layer reduziert auf


    - Titel der Aufnahem
    - Lebenszeit
    - Priorität
    - Kanal


    Der Rest erscheint nicht, und wird beim abspeichern aus der info.vdr entfernt. :(


    sagt das log in dem Moment


    Im html skin ist alles ok, naja das öffnet das auch im frameset und greift nicht auf ajax zurück.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden