[solved] epg2vdr - SQL-Error Incorrect string value

Hi *,

nachdem ich doch ziemliche Probleme mit xmltv2vdr habe, habe ich heute mal den epgd-daemon und epg2vdr aufgesetzt.
Nach längerem Gebastel scheint auch alles zu laufen.
Nur eines hat mich beunruhigt - ich bekomme reihenweise Fehler wie den Folgenden im Log:

epg2vdr: SQL-Error in 'execute(stmt_execute)' - Incorrect string value: '\xE4siden...
' for column 'longdescription' at row 1 (1366) 'Incorrect string value: '\xE4siden...' for column 'longdescription' at r
ow 1' [insert into recordinglist set actor = ?, audio = ?, camera = ?, category = ?, channelid = ?, channelname = ?, cou
ntry = ?, director = ?, duration = ?, episodecompname = ?, episodecomppartname = ?, episodecompshortname = ?, episodelan
g = ?, eventid = ?, flags = ?, folder = ?, fsk = ?, genre = ?, guest = ?, inssp = ?, inuse = ?, job = ?, lastifoupd = ?,
 longdescription = ?, md5path = ?, moderator = ?, music = ?, name = ?, numrating = ?, other = ?, owner = ?, path = ?, pr
oducer = ?, rating = ?, screenplay = ?, scrinfoepisodeid = ?, scrinfomovieid = ?, scrinfoseriesid = ?, scrmovieid = ?, s
crnew = ?, scrseriesepisode = ?, scrseriesid = ?, scrsp = ?, shortreview = ?, shorttext = ?, starttime = ?, state = ?, t
ipp = ?, title = ?, topic = ?, txtrating = ?, updsp = ?, vdruuid = ?, year = ?;]

Kann/muss ich da etwas dagegen tun? Stimmt evtl. irgendwo ein Charset nicht?

Danke und ciao.
Michael.

Hi,

jo, ich hatte solche Aufnahmen und die auch gerade mit convmv "begradigt", aber der Fehler bezog sich ja auf das Feld "longdescription".
Da sollte der Dateiname doch keine Rolle spielen, oder?
Scheinbar muss ich die Inhalte aller info Files auch konvertieren - oder? Das sind doch die, aus denen "longdescription" geholt wird, nehme ich an.

Danke und ciao.
Michael.

Zitat von CKone

Ja genau. Ich hatte da damals so einen rekursiven Befehl zu, krieg ich aber auch so nicht mehr auf die Reihe.

Christian

Naja, wenn ich weiß, dass ich die info File konvertieren muss, kriege ich das schon hin.

Danke und ciao.
Michael.

Hi again!

Ne, irgendwie isses das nicht.
Ich hab jetzt alle Dateinamen und die Inhalte aller info Files nach UTF8 konvertiert. Weder convmv (für die Dateinamen) noch file (für die Inhalte der info Files) zeigen noch irgendwas Verdächtiges != utf8 an.
Trotzdem bekomme ich immer noch 1659 dieser Fehler.
Ich habe auch mal nach den recht kurz abgehackten Teilstrings in den Meldungen gesucht (ohne das \xyz Zeichen) - und finde die Teilstrings weder in info Files noch in Dateinamen.
Gibt es noch eine Stelle, die ich anschauen/konvertieren müsste?

Ciao.
Michael.

Zitat von 3PO

Wie sieht denn die "/etc/mysql/my.cnf" aus?

[client]
[mysqld]
innodb_file_format=Barracuda
innodb_file_per_table=ON
character-set-server = latin1
innodb_large_prefix  = ON
datadir	= /home/mysql
server-id	= 1
port = 3306
socket = /var/run/mysql/mysql.sock
bind-address = 192.168.1.4
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
[mysqld_multi]
mysqld     = /usr/bin/mysqld_safe
mysqladmin = /usr/bin/mysqladmin
log        = /var/log/mysqld_multi.log
!includedir /etc/my.cnf.d

Dazu:

MariaDB [(none)]> use epg2vdr;
MariaDB [epg2vdr]> show variables like '%colla%';
+----------------------+-------------------+
| Variable_name        | Value             |
+----------------------+-------------------+
| collation_connection | utf8_general_ci   |
| collation_database   | utf8_general_ci   |
| collation_server     | latin1_swedish_ci |
+----------------------+-------------------+
[...]
MariaDB [epg2vdr]> show variables like '%charac%';
+--------------------------+------------------------------+
| Variable_name            | Value                        |
+--------------------------+------------------------------+
| character_set_client     | utf8                         |
| character_set_connection | utf8                         |
| character_set_database   | utf8                         |
| character_set_filesystem | binary                       |
| character_set_results    | utf8                         |
| character_set_server     | latin1                       |
| character_set_system     | utf8                         |
| character_sets_dir       | /usr/share/mariadb/charsets/ |
+--------------------------+------------------------------+

Die Servereinstellung für Collation und Charset sollte ja irrelevant sein, solange die Datenbank auf UTF-8 ist.

Ciao.
Michael.

Zitat von 3PO

Nun, ich verwende epgdata nicht, aber so wie es aussieht scheinen die Daten nicht sauber als UTF-8 vorliegen.
Die "\xF?" Zeichen sind ASCII Zeichen >128 und scheinen sich wohl nicht mit "normalem" UTF-8 darstellen zu lassen.

Das vermute ich auch, allerdings finde ich diese Zeichen nirgendwo in meinen Aufnahmen - weder in den Dateinamen noch in den info Files - noch dazu, wo es angeblich über 1.600 Stück sind.
Das ist das, was mich eigentlich verwirrt.

[...]

Ciao.
Michael.

Zitat von 3PO

Ich bin mir doch schon ziemlich sicher, dass wenn Du richtig suchst, Du die 1600 Zeichen findest.

Wo du recht hast, hast du recht
Allerdings ging es nicht um die ä's, sondern um die Zeichenfolgen, in denen die vorkommen.
Und die Fehlermeldungen geben ja einen Teil dieser Zeichenfolgen aus - nicht besonders viel, aber genug, um danach suchen zu können (ohne das encodete 'ä' natürlich).
Und da finde ich halt nix Passendes.

Ciao.
Michael.

Zitat von 3PO

Nun, der ausgegebene Fehler war: \xE4siden

Wenn Du nun das "\xE4", wie oben schon geschrieben, durch ein "ä" ersetzt, dann hast Du "äsiden" und mit ein bisschen Fantasie kommst Du sicherlich drauf, dass das "Präsident" heißen könnte.

Jo, genau sowas hatte ich gemacht - ohne Treffer. Aber halt auf Ebene der Dateinamen und der Inhalte der info Dateien.

Zitat

Versuche es doch einfach mal so:

Code

MYSQL_PWD=epg mysql -Ns -u epg2vdr -D epg2vdr -N -e "SELECT longdescription FROM events WHERE longdescription LIKE '%siden%' LIMIT 1"

Der Fehler tritt beim Einlesen der Aufnahmen (recordinglist) auf, von daher:

SELECT longdescription FROM recordinglist WHERE longdescription LIKE '%siden%' LIMIT 1;

Der select liefert denn auch tatsächlich einen Treffer. Die interessanten Fragen:

1. Wieso steht das in der DB, wenn es doch einen Fehler beim Einlesen gegeben hat?
2. Wo kommt der Text her, wenn er nicht in einem der info Files steht?

Ciao.
Michael.

Zitat von CKone

oder wenn was schräg an den epgdata Daten ist nutze doch einen anderen Provider.

Ich hab so langsam die Vermutung das dein ursprüngliches Problem mit xmlt2vdr auch mit diesen kruden Daten zusammenhing...

hmm, wie haben wir denn jetzt die Brücke von den Aufnahmen zum Provider geschlagen, Aufnahmen war doch das Problem oder? Und wenn er einen Fehler auswirft und die nicht schreiben kann wird man die auch nicht auf der DB finden befürchte ich...

Ne, wie du ja oben geschrieben hast - es geht nicht um die epgdata-Daten, sondern um die bestehenden Aufnahmen.
Der Fehler kommt ja beim Einlesen in die recordinglist.
Und da sich xmltv2vdr um die nicht kümmert, kann der Fehler da auch nicht aus demselben Grund entstanden sein - IMHO

Ciao.
Michael.

Zitat von 3PO

Zitat von 3PO

1.] Es gab ja nur ein Problem mit den einzelnen Zeichen und nicht mit dem kompletten Datensatz.

Das kann sein. Der Fehler sieht nur so dramatisch aus, dass ich davon ausgegangen bin, dass der Datensatz überhaupt nicht übernommen wird.

Zitat von 3PO

2.] Aus der DB, evtl. von scraper2vdr.

Ne, ich verwende selbst keinen scraper - wenn dann muss epgd das gemacht haben.

Ok, egal.
Ich lösche jetzt gaudihalber nochmals alles und baue die ganze DB neu auf.

Dann schau mer mal, was vorher oder nachher da drin steht.

Danke für alle Tips.

Ciao.
Michael.