premiereepg-plugin (absturz bei p direkt)

Moin,

funzt hier ohne irgendwelche Beeinträchtigungen. -->

Gentoo
gcc-4.1.2
vdr-1.5.12
vdr-premiereepg-0.0.8

Cheers

Servus,

ich habe das gleiche Problem, dachte aber bisher es liegt am director-Plugin, ich muss mal testen, ob es vielleicht doch am premiereepg-Plugin liegt.

Ging früher immer problemlos und plötzlich fing es mit den Abstürzen an? Ich weiß nicht was ich geändert habe.

CafeDelMar

Ich hatte auch das Problem, dass vdr 1.5.x (e-tobi) mit premiereepg unstabil lief (beim Schalten auf P-Direkt Kanäle). Es stellte sich heraus, dass das premiereepg plugin nicht mit UTF8 klar kommt! Also habe ich "VDR_LANG=de_DE@euro" (bzw. de_DE.ISO-8859-15@euro) gesetzt. Seit dem habe ich keine Probleme mehr mit dem premiereepg plugin. Nachteil ist, dass nun die Aufnahmen nicht mehr als UTF8 auf der Platte gespeichert werden und Umlaute komisch dargestellt werden

Kann es sein, dass ihr auch UTF8 einsetzt???
Ich hoffe das hilft euch weiter...

Ha, jetzt fällts mir wie Schuppen aus den Haaren,

ich hab meinen VDR gepatcht um das Problem bei Premiere zu beseitigen.
Das mit dem falsch codierten epg wurde schon mehrmals angesprochen auf der ML.
Premiere macht da aber nix , weils ja mit den zertifizierten Recivern keine Probleme gibt
KLS macht da auch nix, der hält sich an den standard

diff -Naur vdr-1.5.8.orig/libsi/si.c vdr-1.5.8/libsi/si.c
--- vdr-1.5.8.orig/libsi/si.c   2007-09-04 23:11:15.251886425 +0200
+++ vdr-1.5.8/libsi/si.c    2007-09-04 23:11:39.800199275 +0200
@@ -339,7 +339,7 @@
 // default ISO6937 is returned. If a table can be determined, the buffer
 // and length are adjusted accordingly.
 static const char *getCharacterTable(const unsigned char *&buffer, int &length, bool *isSingleByte = NULL) {
-   const char *cs = "ISO6937";
+   const char *cs = "ISO8859-15";
    if (isSingleByte)
       *isSingleByte = false;
    if (length <= 0)

Damit rennts dann hier ohne irgendwelche weiteren Änderungen auf 'nem reinen utf-8 System.
Ronny, du bist ja auch einer der noch selbst compiliert, dann sollte der patch kein Problem für dich darstellen...

Ich habe das Problem aber mit dem vdr 1.4.7, da kann es ja eigentlich nicht an UTF liegen, oder?

Hi,

ich habe das selbe Problem mit dem vdr 1.6.0. Dieser wird gestartet mit der Umgebungsvariable
export VDR_CHARSET_OVERRIDE=ISO-8859-15
was meines Verständnisses nach ja in etwa das selbe macht, wie der unten angegebene Patch. Das Problem tritt trotzdem auf. Hat jemand eine Idee, wie sich das lösen lässt?

Vielen Dank!

Ich konnte das Problem auf die folgenden Zeilen im Premiereepg einschränken:

for(int i=0; i<5; i++) {
                 int l=data[0];
                 if(l>0) p+=snprintf(&buff[p],sizeof(buff)-p,"\n%s: %.*s",tr(text[i]),l,&data[1]);
                 data+=l+1;
                 }

Dies ist etwa um die Zeile 550 im Plugin.

Weiß jemand, wie das in Zusammenhang mit utf-8 zu einem Absturz führen kann?

Ich vermute mal das es was mit dem Zielbuffer zu tun hat (steht drei Zeilen über der For Schleife), erhöhe mal den Buffer und teste mal ob es was bringt. Also die Zeile char buff[512] auf z.B. char buff[512*4] ändern. UTF-8 kodierter Text ist ja größer als ASCII und evtl. knallts hier deshalb.

Das schaut recht plausibel aus. Ich hab's mal auf 2048 geändert. Beim ersten Zappen ist kein Problem aufgetreten. Wie sicher bist du dir, dass es exakt daran lag und die Änderung keine anderen Fehler verursacht? Ansonsten würde ich, wenn es dauerhaft funktioniert, den Patch an den ebuild-maintainer weiterleiten.

Vielen Dank für die Hilfe,
Michael.

Schätze schon das dies die Problemursache ist, der Buffer ist der einzige in den in dieser Funktion reingeschrieben wird, und wenn man übers Bufferende rüberschreibt kommts halt zur ner Exception weil damit der Stack überschrieben wird.

Ausser das temporär 1,5Kb mehr RAM auf dem Stack verbraucht werden, sollte der Patch keine Nebenwirkung haben, ist ja sehr überschaubar was da gepatcht wird.

Hi,

verstehe ich das richtig ? Mit dem Patch und dem override brauch man das Premiereepg Plugin nichtmehr ??

Grüße Magicdragon67

Nein. Mit dem Patch stürzt das Plugin in einer UTF-8 Umgebung (hoffentlich) nicht mehr ab.