Nicht-konforme Zeichen in der Aufnahme-XML

[Mucki]

Das Problem wurde hier schon mal angesprochen, es besteht aber immer noch.

Es geht um nicht-XML-konforme Zeichen in der Aufnahme-XML, und zwar bei der Audiobeschreibung.
Reproduzierbar bei Aufnahmen von arte: "<0x05>französisch".

Ist dieses 0x05 Zeichen nicht der mitgesendetete optionale Code für die Zeichentabelle? Dann könnte es doch genauso herausgefiltert werden wie bei info1, info2...

[Gaucho316]

Wie nimmst du denn auf? Per Direktaufnahme oder mit udrec? Und siehst du die Sonderzeichen auch in der Audioauswahl, wenn du dir den Sender direkt ansiehst?

[weere]

Haste schon ne lösung? Ich habe dieses Problem auch gelegentlich.
Ich habe ne Tuxbox in meine Skoda Gebrauchtwagen und bin richtig gespannt.

[Mucki]

Es geht um Direktaufnahme auf ein NAS. In der Audioauswahl ist das Sonderzeichen nicht sichtbar...

[Gaucho316]

Ich habe versucht rauszufinden, woran das liegt, habe aber leider keinen Anhaltspunkt gefunden.
Da muss dann wohl jemand anders ran.

[Mucki]

Könnte man das hier abfangen?

remotecontrol.cpp

Code: Alles auswählen

void CRemoteControl::processAPIDnames()
...

[Gaucho316]

Da hatte ich auch schon reingeguckt. Man kann hier natürlich gucken, ob das erste Zeichen 0x05 ist und es dann wegschneiden, aber ob das der Weisheit letzter Schluss ist, weiß ich nicht.

Edit: Bei mir (KD) heißen die Tonspuren auf arte übrigens German und French. Merkwürdig ...

[Mucki]

3sat hat das auch, zumindest über Satellit.

Das Sonderzeichen ist nicht zwangsläufig 0x05. Laut DVB-Standard kann alles im Bereich 0x01-0x1F vorkommen. Bei einigen Sendern sogar im Bereich 0x80-0x9F (z.B. Al Arabiya). Bildschirmausgaben sind nicht betroffen, von daher würde ein Check vor dem Zusammenbau der XML schon reichen.

Bleibt die Frage wie das bei info1 und info2 gehandhabt wird...

Edit: Die Zeichen im Bereich 0x80-0x9F dienen der Textformatierung und können an jeder Stelle im Text auftreten. Im DVB Standard sind bisher nur 0x8A (Zeilenumbruch) und 0x86 0x87 (Texthervorhebung) fest definiert.

Außer beim 0x8A wird das m.E. nicht abgefangen. (siehe auch http://www.tuxbox.org/forum/viewt ... =9&t=49609

[Gaucho316]

Probier mal das. Ob der Patch gut ist und überhaupt funktioniert, weiß ich allerdings auch nicht. Ich hab's nicht getestet. Vielleicht kann seife etwas dazu sagen.

Code: Alles auswählen

--- tuxbox-cvs/apps/tuxbox/neutrino/daemons/sectionsd/SIsections.cpp	2011-12-09 12:46:37.477817500 +0100
+++ tuxbox-src/apps/tuxbox/neutrino/daemons/sectionsd/SIsections.cpp	2011-12-09 13:19:52.946369100 +0100
@@ -175,7 +175,11 @@
 void SIsectionEIT::parseComponentDescriptor(const char *buf, SIevent &e, unsigned maxlen)
 {
 	if(maxlen>=sizeof(struct descr_component_header))
-		e.components.insert(SIcomponent((const struct descr_component_header *)buf));
+	{
+		SIcomponent c((const struct descr_component_header *)buf);
+		c.component = CDVBString(c.component.c_str(), c.component.length()).getContent();
+		e.components.insert(c);
+	}
 }
 
 void SIsectionEIT::parseContentDescriptor(const char *buf, SIevent &e, unsigned maxlen)

Edit: Hier mal das Ganze als Datei. Kompilieren tut's, aber ob's hilft, weiß ich nicht.
Link zum Patch entfernt

[GetAway]

Edit: Bei mir (KD) heißen die Tonspuren auf arte übrigens German und French. Merkwürdig ...

Das ist bei mir auf Dbox und Coolstream ebenfalls so, wenn man sofort nach dem Zappen die Tonwahltaste drückt.
Wartet man 3-4 Sekunden wird es in Deutsch angezeigt. Wahrscheinlich dauert das Parsen solange.

[Mucki]

Probier mal das...

Mit dem Patch ist das Sonderzeichen zwar weg, nur gehen damit die Umlaute kaputt (auch in der Bildschirmanzeige).

Code: Alles auswählen

<audio pid="402" name="deutsch"/>
<audio pid="403" name="französisch"/>

[Gaucho316]

Ok, versuche mal das hier. Ich filtere das optionale Zeichen für die Zeichentabelle jetzt einfach raus. So wird es auch an anderen Stellen in SIsections.cpp gemacht. Das ist das Einfachste. Die Klasse CDVBString liefert offensichtlich UTF-8. Und das bringt den Code an vielen anderen Stellen in Neutrino durcheinander.

Link zum Patch entfernt

Edit: Bei mir (KD) heißen die Tonspuren auf arte übrigens German und French. Merkwürdig ...

Das ist bei mir auf Dbox und Coolstream ebenfalls so, wenn man sofort nach dem Zappen die Tonwahltaste drückt.
Wartet man 3-4 Sekunden wird es in Deutsch angezeigt. Wahrscheinlich dauert das Parsen solange.

Ich weiß jetzt, warum das bei mir so ist. Bei KD fehlen seit einiger Zeit "in allen PMTs die Stream-Identifier-Descriptors mit dem Component-Tag". Deshalb können in CRemoteControl::processAPIDnames() die Tonspurnamen aus dem EPG nicht den Tonspuren zugeordnet werden. Diese Trottel von KD ...

[Mucki]

Ok, versuche mal das hier. Ich filtere das optionale Zeichen für die Zeichentabelle jetzt einfach raus...

Bei Aufnahmen von arte und 3sat sieht es gut aus, keine 0x05 Sonderzeichen mehr und die Umlaute sind OK.

Zeichen im Bereich 0x80 bis 0x9F werden aber nicht rausgefiltert. Die gelangen nach wie vor in die XML.

[Gaucho316]

Bei info1 und info2 werden diese Zeichen aber auch nicht rausgefiltert. Dort wird nur geprüft, ob das erste Zeichen kleiner als 0x06 ist. Ist das der Fall, wird es abgeschnitten. Ich habe das für die Namen der Audiospuren so erweitert, das geguckt wird, ob das erste Zeichen im Bereich 0x00 bis 0x1F und 0x80 bis 0x9F liegt. Mehr nicht. Im restlichen Teil der Texte können diese Steuerzeichen noch vorkommen.

Sind wir überhaupt noch bei der Audiobeschreibung oder beziehst du doch inzwischen auf die ganze XML-Datei?

[Mucki]

Ja, es geht noch um die Audiobeschreibung in der XML. Bei Aufnahmen von Al Arabiyah habe ich z.B. 0x83 und 0x9F an erster Stelle bei audio in der XML stehen und komischerweise nicht in UTF-8 konvertiert.

Wenn es um die ganze XML geht, dann ist auffallend, dass diese control codes, wenn sie im "epgtitle" vorkommen, in UTF-8 kodiert sind.

[Gaucho316]

Ich habe nun auch einmal in den Standard geguckt. Die optionale Zeichentabellencodierung am Anfang von DVB-Strings kann von 0x00 bis 0x1F gehen. Das ist im aktuellen Code falsch, da an allen Stellen nur von 0x00 bis 0x05 geprüft wird. Das werde ich korrigieren. Für Linkage und Component Descriptors wird das bis jetzt überhaupt nicht gemacht. Da werde ich das Wegschneiden auch noch einbauen bzw. im Vergleich zu meinen bisherigen Patches nochmals ändern.

Außerdem habe ich vor, an der Stelle, an der die Aufnahme-XML erzeugt wird, die Zeichen 0x80 bis 0x9F in Titel, Info1, Info2 und in den Audiospurnamen durch Leerzeichen zu ersetzen. Oder hat jemand eine bessere Idee?

Ich werde also die Tage meinen Patch nochmals überarbeiten, so dass es dann endlich vernünftig funktionieren sollte.

[seife]

Wegschneiden ist IMHO falsch.
Das mit dem Umweg über DVBString ist schon richtiger. Dass Neutrino noch nicht überall als default utf-8 verwendet ist dann halt ein Problem. Das Wortmarkengeschützte und daher hier vorsichtshalber nicht genannte neutrino-Derivat benutzt schon per default utf-8, vermutlich um solchen Problemen aus dem Weg zu gehen.

[Gaucho316]

Wegschneiden ist IMHO falsch.

Ich weiß. Ein anderer Weg fällt mir aber nicht ein, ohne alles auf UTF-8 umzustellen (worauf ich keine Lust habe).

[Mucki]

Man sollte schon Aufwand und Nutzen abwägen. Und da spricht erstmal alles für Goucho's Vorhaben.

[seife]

Nur wenn du Westeuropäer bist

[Gaucho316]

Was kümmern mich die Anderen ...

Und da das auch schon seit vielen Jahren so falsch ist und sich noch keiner darüber beschwert hat, mache ich es mir eben einfach.

[seife]

Dann macht aber einen Kommentar drüber. Sonst denkt irgendwann mal in 5 Jahren wir wären zu dämlich gewesen

Faulheit lasse ich mir gern nachsagen )

[Mucki]

Außerdem habe ich vor, an der Stelle, an der die Aufnahme-XML erzeugt wird, die Zeichen 0x80 bis 0x9F in Titel, Info1, Info2 und in den Audiospurnamen durch Leerzeichen zu ersetzen. Oder hat jemand eine bessere Idee?

Es genügt die Sondercodes zu entfernen, Leerzeichen sollten nicht rein.

[Gaucho316]

Außerdem habe ich vor, an der Stelle, an der die Aufnahme-XML erzeugt wird, die Zeichen 0x80 bis 0x9F in Titel, Info1, Info2 und in den Audiospurnamen durch Leerzeichen zu ersetzen.

Wäre es eine gute Idee, das direkt in der Funktion Latin1_to_UTF8() in apps/tuxbox/neutrino/src/driver/encoding.cpp abzufangen. Für 0x8a wird das ja da auch schon gemacht.

So habe ich mir das gedacht:

Code: Alles auswählen

--- encoding.cpp.ORIG	2011-12-13 12:45:10.066250300 +0100
+++ encoding.cpp	2011-12-13 12:47:32.390903100 +0100
@@ -34,7 +34,7 @@
 			r += '\n';
 		else if (c < 0x80)
 			r += c;
-		else
+		else if (c > 0x9f)
 		{
 			unsigned char d = 0xc0 | (c >> 6);
 			r += d;

Hier mal der Code als Datei:
Link entfernt, da Patch im CVS

Ich habe nun auch einmal in den Standard geguckt. Die optionale Zeichentabellencodierung am Anfang von DVB-Strings kann von 0x00 bis 0x1F gehen. Das ist im aktuellen Code falsch, da an allen Stellen nur von 0x00 bis 0x05 geprüft wird. Das werde ich korrigieren. Für Linkage und Component Descriptors wird das bis jetzt überhaupt nicht gemacht. Da werde ich das Wegschneiden auch noch einbauen bzw. im Vergleich zu meinen bisherigen Patches nochmals ändern.

Das habe ich nun auch umgesetzt. Testet mal bitte, ob das Probleme macht. Ich habe den Code für den Freesat-EPG auch etwas umgestellt. Es wäre gut, wenn jemand ausprobieren könnte, ob das noch funktioniert.

Link entfernt, da Patch im CVS

[GetAway]

Scheint erstmal zu funktionieren, Aufnahmen habe ich noch nicht getestet.
In encoding.cpp ist das allerletzte Zeichen ("ein Semikolon" )zuviel. Das nur nebenbei.