TransEdit - Character Decoding fehlerhaft

[ö-r-rf]

Hallo Griga, hallo Lars,

 

bei Versuchen mit einem DVB-SI-Testsystem habe ich festgestellt, dass Transedit (und vielleicht auch der DVBvierwer selbst?) noch ein paar Bugs beim Decodieren von verschiedenen Zeichsätzen nach DVB-Spezifikation hat. Insbesondere der Latin Standardzeichensatz (ISO6937) funktioniert überhaupt nicht korrekt und z. B. bei UTF-8 gibt es mindestens mal Probleme wenn ein Textfeld nicht mit einem ASCII-Zeichen anfängt. Die anderen möglichen Zeichensätze hab ich noch nicht genauer kontrolliert.

 

Ich könnte euch helfen diese Fehler zu beseitigen.

[Griga]

Sind Samples (Testdateien) verfügbar, mit denen sich das Problem nachvollziehen lässt?

[ö-r-rf]

Wäre kein Problem. Kann ich dir gerne nach Wunsch erstellen.

[Griga]

Das wäre gut. Hast du eine Upload-Möglichkeit? Links kannst du, falls sie nicht öffentlich zugänglich sein sollen, auch per PM mittteilen.

 

ein paar Bugs beim Decodieren von verschiedenen Zeichsätzen nach DVB-Spezifikation

Die DVB-Spezifikationen sind nicht allein maßgeblich. Die Behandlung der Zeichensätze enthält diverse Work-Arounds für Anbieter/Länder, die sich nicht nach den Spezifikationen richten oder sie verschieden interpretieren. Die Angelegenheit ist einigermaßen heuristisch, d.h. resultiert zu einem Teil aus Samples, die Anwender bei Problemen zur Verfügung gestellt haben. Außerdem übersetzt letztendlich Windows nach UTF-16, d.h. es spielt auch eine Rolle, ob passende Codepages installiert und korrekt sind. Nichtsdestotrotz dürfte es Verbesserungsmöglichkeiten geben.

[ö-r-rf]

Für einen Analyzer sollten Spezifikationen/Standards zunächst immer maßgeblich sein. Sonst wäre es ja irgendwie kein Analyzer sonder eher ein Orakel

 

Bei der UTF-16-Umwandlung mittels Windows-Codepages (wahrscheinlich mittels MultiByteToWideChar, oder?) musst du ganz vorsichtig sein. Da lauern böse Fallen.

Die sind Codepages sind teilweise fehlerhaft oder entsprechen nicht genau den DVB-Zeichensätzen.

Die ISO6937-Codepage z. B. ist komplett defekt. Das sagt Microsoft sogar selbst.

Dort funktioniert das korrekte Zusammenbauen der Zeichen nicht und alles wird stattdessen in Einzelzeichen zerlegt.

Netter Effekt aber unbrauchbar.

 

Ich hab das letztendlich immer über eigenen Programmcode unter Anwendung von Look-up-Tables und minimaler Programmlogik exakt und effizient gelöst.

So machen es z. B. auch die VLC-Entwickler.

Da kann man dann auch gleich in einem die "DVB-Sonderzeichen" für den Zeilenumbruch und Fettschrift handhaben.

 

Die beiden Beispiele für ISO6937 und UFT-8 habe ich dir schon mal bereitgestellt.

Zugang kommt per PN.

[Griga]

Danke. Jetzt müsste ich noch wissen, was wo bei der UTF-8-kodierten EIT in TransEdit anders erscheint als es soll. Ich finde da nichts. UTF-8 benutzen die Briten beim EPG (Freesat, zusätzlich Huffman-kodiert), bislang ohne Probleme in TransEdit.

 

In der ISO 6937-kodierten EIT gehen die Umlaute baden, soweit klar. Da muss der Encoder als Sprachkennung auch nicht deu, sondern hun, cze, slo oder so einsetzen (also eines der Länder, in denen tatsächlich ISO 6937 gesendet wird), dann funktioniert es Deutsche Anbieter verwenden durchweg ISO 8859-9 (Latin alphabet No. 5), oft so gekennzeichnet, manchmal auch nicht...

 

Für einen Analyzer sollten Spezifikationen/Standards zunächst immer maßgeblich sein.

Da hast du recht. Ich habe allerdings weder Zeit noch ausreichend professionelle Ambitionen, zwei Versionen der Zeichensatzbehandlung zu pflegen, und für den DVBViewer steht halt im Vordergrund, dass es in der Praxis funktioniert.

 

Die ISO6937-Codepage z. B. ist komplett defekt. Das sagt Microsoft sogar selbst.

Ist bekannt. Deshalb ist ISO 6937 die einzige selbst erstellte Übersetzungstabelle. Und die funktioniert auch, vorausgesetzt die Sprachkennung spielt mit.

 

Ich hab das letztendlich immer über eigenen Programmcode unter Anwendung von Look-up-Tables und minimaler Programmlogik exakt und effizient gelöst.

Glückwunsch. Auch für Kyrillisch? Griechisch? Arabisch? Hebräisch? Thai? Koreanisch? Simplified Chinese? Big5? Shift-JIS? Das nenne ich eine Leistung!

 

Hinzu kommen hier noch die Zeichensätze des japanisch-lateinamerikanischen ISDB-Standards. In Japan gibt es zwei Silbenschriften, gut durchmischt mit Zeichen chinesischer Abstammung. Eine Wissenschaft für sich. Ist mir bei japanischen Untertiteln begegnet. Da kann man sich wochenlang mit beschäftigen, und hat keinen, der einem sagt, ob das, was auf dem Bildschirm erscheint, richtig ist. ATSC lassen wir jetzt mal außen vor, da ist wieder alles ganz anders...

 

Ich habe den Zeichensatz-Tabellen-Job einmal für X Teletext-Sprachen durchgezogen (da helfen nämlich keine Windows Codepages), und danach beschlossen, den Rest meines Lebens nicht auf diese Weise zu verbringen. An Arabisch bin ich trotz längerem Bemühen gescheitert, da es mir nicht gelungen ist, die in den Teletext-Spezifikationen abgebildeten Zeichen in den Windows-Zeichensätzen zu identifizieren, und auch die Systematik des Alphabets ist mir trotz Wikipedia-Studium schleierhaft geblieben. Irgendwann tat sich dann eine Quelle auf, von der ich abschreiben konnte...

[ö-r-rf]

Danke. Jetzt müsste ich noch wissen, was wo bei der UTF-8-kodierten EIT in TransEdit anders erscheint als es soll. Ich finde da nichts. UTF-8 benutzen die Briten beim EPG (Freesat, zusätzlich Huffman-kodiert), bislang ohne Probleme in TransEdit.

UTF-8 Problem:

Klapp mal den EIT-Schedule-Baum auf uns scrolle mal einfach die Liste der Events nach unten durch. Mittendrin wirst du einige Event-Knoten ohne Beschriftung sehen.

Das gleiche Phänomen tritt natürlich auch z. B. bei Extended Event Descriptoren auf, aber da muss man genauer suchen bis man da einen passenden gefunden hat.

Tritt offensichtlich immer dann auf, wenn das erste Zeichen kein ASCII ist.

 

Die Briten haben ja auch eher keine Umlaute o. ä.

 

In der ISO 6937-kodierten EIT gehen die Umlaute baden, soweit klar. Da muss der Encoder als Sprachkennung auch nicht deu, sondern hun, cze, slo oder so einsetzen (also eines der Länder, in denen tatsächlich ISO 6937 gesendet wird), dann funktioniert es Deutsche Anbieter verwenden durchweg ISO 8859-9 (Latin alphabet No. 5), oft so gekennzeichnet, manchmal auch nicht...

Ooh das alleine ist aber suboptimal. Die Sprachkennung hat ja schließlich nichts mit der Zeichenkodierung zu tun sondern dient nur der Auswahlmöglichkeit bei Mehrsprachigkeit.

Nur weil die deutschen Sender über Satellit so einen Müll ausstrahlen heißt dies ja im Umkehrschluss nicht, dass es in Deutschland keine Programmanbieter und Plattformbetreiber gibt die sich an die Standards halten. Es gibt ja auch noch zahlreiche DVB-T-, Kabel- und IPTV-Netze. Und eben dort gibt es dann schon Probleme.

Man kann ja nicht die Anbieter bitten die Language Descriptoren auf eine ortsfremde Sprache zu stellen damit der Analyzer richtig geht...

 

Daher wäre mein Vorschlag einfach in TransEdit eine Option einzubauen mit der man bei Bedarf (auch) eine standardkonforme Dekodierung aktivieren kann.

Idealerweise sollte man zusätzlich dann noch eine Liste von Zeichensatzkodierungen zur manuellen Auswahl haben falls wirklich die Codierung komplett daneben liegt und auch mit deinen Sprachen-Workarounds nicht erkannt wird.

Dann hätten alle was davon. TransEdit ist ja ansonsten schon ein sehr leistungsfähiges Tool, was in manchen Bereichen selbst sehr teuren professionellen Tools gut Konkurrenz machen kann.

 

Abgesehen davon ist ISO8859-9 (türkisch) auch für Deutschland der falsche Zeichensatz. Da sollte eigentlich Latin 9 also ISO8859-15(!) verwendet werden. Da hat wahrscheinlich in den Anfängen des Digitalfernsehens irgendjemand irgendwas verwechselt oder nicht verstanden und alle haben es blind nachgemacht (wie so oft in diesem Bereich). Super!

 

Glückwunsch. Auch für Kyrillisch? Griechisch? Arabisch? Hebräisch? Thai? Koreanisch? Simplified Chinese? Big5? Shift-JIS? Das nenne ich eine Leistung!

Nur die Zeichensätze die im DVB-Standard vorkommen.

Die 8 bit ISO8859-XX Zeichensätze sind sehr einfach umzusetzen. Koreanisch, GB und Big5 sind 16 Bit-Zeichensätze mit fester Unicode-BMP-Übersetzung. Das war somit auch recht einfach. Die Übersetzungstabellen gibt es direkt zum download. Und UTF-8 ist ohnehin rein algorithmisch zu lösen. Nur ISO6937 ist ein Mix - aber trotzdem noch gut überschaubar. Mit dem Rest musste ich mich zum Glück noch nie befassen.

Edited July 17, 2012 by ö-r-rf

[Griga]

Tritt offensichtlich immer dann auf, wenn das erste Zeichen kein ASCII ist. Die Briten haben ja auch eher keine Umlaute o. ä.

Haben die. Da tauchen Buchstaben mit Akzenten auf (z.B. Beyoncé Knowles) - dadurch hatte ich erst gemerkt, dass es UTF-8 ist. Spezifikationen gibt es nämlich nur beim Erwerb einer Freesat-Lizenz.

 

Die Ursache ist eine andere: UTF-8-Steuercodes, z.B. C2 8A = LF. UTF8Decode() liefert in dem Fall einen leeren String. Also muss ich sie vorher wegfiltern - ist im nächsten Release gefixt.

 

Ooh das alleine ist aber suboptimal. Die Sprachkennung hat ja schließlich nichts mit der Zeichenkodierung zu tun

Was willst du machen, wenn ein großer polnischer Anbieter mit konstanter Boshaftigkeit Texte als ISO 8859-5 (kyrillisch) ausweist, aber tatsächlich ISO 6937 sendet? Da hilft nur

 

if (CharSet = ISO_8859_5) and (Language = 'pol') then
 CharSet := ISO_6937;

 

Schön war auch der Fall des deutschen Kabelproviders, bei dem ein Sendername oder sowas als ISO 8859-6 (Arabisch) markiert war, obwohl er aus reinem ASCII bestand. MultiByteToWideChar liefert bei fehlender Codepage auch nur einen leeren String. Das gab prompt Reklamationen. Also habe ich den Anwendern empfohlen, arabische Sprachunterstützung zu installieren. Danach war es ok Inzwischen gibt es für solche Fälle einen Work-Around.

 

Verbleiben wir so: Wenn du mir nachweist, dass ein relevanter deutscher Anbieter (d.h. kein konstruierter Testfall) ISO 6937 erfordert, dann unternehme ich etwas in der Hinsicht. Ansonsten nicht, weil ich nicht weiß, was ich sonstwo damit anrichte. Ein gutes Pferd springt nie höher als es muss

 

Daher wäre mein Vorschlag einfach in TransEdit eine Option einzubauen mit der man bei Bedarf (auch) eine standardkonforme Dekodierung aktivieren kann.

Wäre sinnvoll. Irgendwann in den nächsten 10 Jahren vielleicht, wenn gerade nichts anderes zu tun ist.

 

Abgesehen davon ist ISO8859-9 (türkisch) auch für Deutschland der falsche Zeichensatz.

Bei den vielen Türken, die hier leben? Bist du gegen Integration?

 

Nur die Zeichensätze die im DVB-Standard vorkommen.

Die kommen alle vor, außer Shift-JIS, glaube ich. Den brauchen wir für ISDB.

 

Koreanisch, GB und Big5 sind 16 Bit-Zeichensätze

Glaubst du. Davon bin ich auch ausgegangen und hatte Big5 als UTF-16 behandelt. Dann gab es Beschwerden aus China: Zeichensalat. Lars kam schließlich auf die Idee, dass man mal die Codepage 950 heranziehen sollte... also ist Christian per Remote-Desktop nach China und hat es überprüft. Mit Google-Übersetzungen des Outputs. Das ergab natürlich den bekannten Unsinn, aber nach der Konvertierung mit der Big5-Codepage nicht mehr ganz so unsinnigen Unsinn. Wir haben es deshalb überall geändert: DVBViewer Pro/GE, Recording Service, TransEdit. Daraufhin gab es im Forum diverse Posts dieser Art:

 

http://www.DVBViewer.tv/forum/topic/49698-to-big5-encoding-garbled-in-my-system/

 

weil nämlich auf Taiwan die Big5-Zeichensatzkennung anders verstanden wird als auf dem Festland (so wie ich sie anfänglich verstanden hatte). Seitdem müssen chinesische User das konfigurieren.

 

Ich könnte noch einige solche Geschichten erzählen, ebenso wie Lars. Wie auch immer: Schuld ist grundsätzlich der DVBViewer. Auf der einen Seite behaupten es Anwender "Mein (von einem großen Hersteller für Landesverhältnisse lokalisierter) Receiver macht es aber richtig!", auf der anderen Seite Theoretiker "Die DVB-Spezifikationen besagen doch, dass...". Beiden gemeinsam ist die Unkenntnis des realen DVB-Lebens.

[Derrick]

Zu den zeichensätzen will und kann ich mich zwar nicht äussern, aber vielleicht doch allgemein zu ähnlichen themen im zusammenhang mit transedit. Man muss einfach akzeptieren, dass es keinen anspruch erhebt, ein professionelles tool zur fehleranalyse zu sein. Eher ein sehr komfortables dvb_reading_tool zu einem konkurrenzlos niedrigen preis. Als zugabe zum dvbv gibt es transedit nämlich gratis

[Griga]

Eher ein sehr komfortables dvb_reading_tool

Treffend beschrieben.

[ö-r-rf]

Was willst du machen, wenn ein großer polnischer Anbieter mit konstanter Boshaftigkeit Texte als ISO 8859-5 (kyrillisch) ausweist, aber tatsächlich ISO 6937 sendet?

Ich würde Ihn zunächst mal kontaktieren und auf das Problem hinweisen. Die meisten dieser Fehler entstehen leider einfach aus Unachtsamkeit oder auch ein bisschen Unkenntnis. Im Ernst.

 

Schön war auch der Fall des deutschen Kabelproviders, bei dem ein Sendername oder sowas als ISO 8859-6 (Arabisch) markiert war, obwohl er aus reinem ASCII bestand. MultiByteToWideChar liefert bei fehlender Codepage auch nur einen leeren String. Das gab prompt Reklamationen. Also habe ich den Anwendern empfohlen, arabische Sprachunterstützung zu installieren. Danach war es ok Inzwischen gibt es für solche Fälle einen Work-Around.

Auch dies war mit Sicherheit ein unbeabsichtigter Fehler. Wenn ihn jemand meldet kann er behoben werden. Wenn stattdessen lieber für alle Geräte und Software ein "Workaround" erstellt wird nicht.

 

Ist es denn wirklich so ein Aufwand den Code (sinngemäß) so zu erweitern?

if (bCharEncDvbStd = FALSE) then
 if (CharSet = ISO_8859_5) and (Language = 'pol') then
   CharSet := ISO_6937;

 

Verbleiben wir so: Wenn du mir nachweist, dass ein relevanter deutscher Anbieter (d.h. kein konstruierter Testfall) ISO 6937 erfordert, dann unternehme ich etwas in der Hinsicht. Ansonsten nicht, weil ich nicht weiß, was ich sonstwo damit anrichte. Ein gutes Pferd springt nie höher als es muss

 

Sonst hätte ich das Problem ja nicht bemerkt. Die Analyse mit dem SI-System war nur zum Test was da genau schief läuft.

Das "Problem" gibt es bei dem kleinen Anbieter Kabel Deutschland.

 

Glaubst du. Davon bin ich auch ausgegangen und hatte Big5 als UTF-16 behandelt. Dann gab es Beschwerden aus China: Zeichensalat.

Kein Wunder. Ich hab ja auch nicht gesagt das Big5 = UTF-16 ist sondern das beide 16 bit Zeichensätze sind, also jedes Zeichen (bis auf 0-127) mit 2 Bytes codiert wird.

Daher ergibt sich eine 1:1 Beziehungstabelle. Diese kann man natürlich auch sehr einfach mittels WideCharToMultiByte und der Codepage 950 erstellen und anschließend noch bei Bedarf modifizieren. Wenn man das Ergebnis aber dann fest im Programmcode integriert braucht es eben keine externen Codepages mehr die eventuell nicht im System installiert sind.

 

 

 

Das Problem mit den Workarounds - so gut sie auch gemeint sind - ist, dass damit für die Anbieter eine Fehlersituation auf Dauer zementiert wird.

Es ist in einigen Fällen (nicht nur auf dieses Thema hier bezogen) schon nicht mehr möglich ein standardkonformes Signal auszustrahlen weil viele Receiver dann damit Probleme hätten (deren Entwickler hatten eben lieber schnell "Workarounds" eingebaut haben statt Fehler zu melden) und man aber die Kunden mit solchen Produkten auch wieder nicht vergraulen möchte oder kann.

 

Jüngstes Beispiel war der Aufschrei nach der Neuaufschaltung der ÖR-HD-Programme in Deutschland. Plötzlich hatten einige Receiver Probleme und fingen an zu Ruckeln. Grund: Die Entwickler hatten sich nur die bisher ausgestrahlten Signale angesehen und ihre Receiver eben auch gerade nur dafür ausgelegt. Als dann weitere Möglichkeiten des Standards genutzt wurden und das Signal nun etwas anders war fielen sie mit dieser Strategie sofort auf die Nase...

 

Ich verstehe ja deine Haltung aus passiver Anwendersicht aber du solltest den Leuten die an dem grundsätzlichen Problem etwas ändern möchten wenigstens eine Chance geben.

[Lars_MQ]

Griga hat recht, einige Provider entwickeln recht phantasievolle Auslegungen des DVB-Standards und wir haben soviele Ausnahmen und Workarounds im Decodierungscode, das es schon nicht mehr schön ist.

 

Manchmal enthalten die EIT Daten schlichtweg Fehler aber wir bekommen die Schuld.

Ich erinnere mich an den italienischen Sender, der mitten im Wort öfters anstatt eines Buchstaben ein "?" enthielt, was hier prompt als Fehler gemeldet wurde. Nach einigen Nachforschungen stellte sich raus, dass die Daten schon so fehlerhaft übertragen wurden. Dort hat es in der internen Verarbeitungskette auf der Senderseite wohl schon eine Fehlkonvertierung gegeben.

 

Oder diverse ÖR Sender der ARD, die EIT Text mit "'" (also html codierung) übertragen. Das und andere html-codes habe ich auch schon bei anderen Sendern gesehen, aber im Moment werden bei mir nur die ARD Sender nach einer kurzen EPG Suche im RS angezeigt.

[ö-r-rf]

Oder diverse ÖR Sender der ARD, die EIT Text mit "'" (also html codierung) übertragen. Das und andere html-codes habe ich auch schon bei anderen Sendern gesehen, aber im Moment werden bei mir nur die ARD Sender nach einer kurzen EPG Suche im RS angezeigt.

Bitte weist doch dann die Sender auf solche Probleme hin wenn so etwas auffällt! Solche Meldungen werden dort i. d. R. genau geprüft.

Bei den internen Wegen die die Daten vor der Ausstrahlung nehmen kann sowas an vielen Stellen passieren. Da wird ja niemand sitzen und den ganzen Tag EPG schauen.

 

Das wird jedenfalls bestimmt nicht mit Absicht gemacht.

Edited July 18, 2012 by ö-r-rf

[Derrick]

Das Problem mit den Workarounds - so gut sie auch gemeint sind - ist, dass damit für die Anbieter eine Fehlersituation auf Dauer zementiert wird.

Es ist in einigen Fällen (nicht nur auf dieses Thema hier bezogen) schon nicht mehr möglich ein standardkonformes Signal auszustrahlen weil viele Receiver dann damit Probleme hätten (deren Entwickler hatten eben lieber schnell "Workarounds" eingebaut haben statt Fehler zu melden) und man aber die Kunden mit solchen Produkten auch wieder nicht vergraulen möchte oder kann.

Trifft auf den DVBViewer selbst eigentlich nicht zu. Leider sind user (subjektiv gesehen nicht ganz zu unrecht ) anderer meinung und schieben alles auf die applikation, obwohl deutlich darauf hingewiesen wird, dass für dekodierung und rendering primär andere die ansprechpartner sind. Fehler werden aber immer umgehend berichtigt und erweiterungen eingepflegt. Ohne workarounds geht es leider nie, allein schon, weil es auch altlasten gibt.

 

Der DVBViewer ist weder normen-kontrollinstanz noch unterabteilung von ISO, ETSI oder DVB.org. Das eigentliche problem betrifft hauptsächlich receiver, die in fernost entwickelt und produziert werden. Leider gibt es kaum was anderes..

[Lars_MQ]

Das wird jedenfalls bestimmt nicht mit Absicht gemacht.

Das habe ich auch nie unterstellt.

[Griga]

Das "Problem" gibt es bei dem kleinen Anbieter Kabel Deutschland.

Das hätte ich gerne durch ein Sample belegt. Bislang gab es keine diesbezüglichen Meldungen. Und lasse mich bitte diesmal nicht lange suchen, sondern beschreibe gleich, was an welcher Stelle schiefgeht.

 

Bitte weist doch dann die Sender auf solche Probleme hin wenn so etwas auffällt!

In einzelnen Fällen mache ich das, aber es gibt nicht nur Fehler bei Sendern, sondern auch bei Treiber-Herstellern, DirectShow-Filter-Produzenten usw. Die Kommunikation ist zeitaufwändig, man muss die richtigen Ansprechpartner finden und analysieren und dokumentieren und belegen und erklären... wir haben bereits genug damit zu tun, die eigenen Fehler zu bekämpfen.

 

Wenn du meinst, das sollte gemacht werden, kannst du den Job gerne haben. Da du offenbar talentiert, fachkundig und (noch) voller Idealismus bist, ernennen wir dich zum ehrenamtlichen Senderfehler-Bekämpfungs-Beauftragten. Fange am besten gleich hier an:

 

http://www.DVBViewer.tv/forum/topic/45528-selective-epg/page__view__findpost__p__335732

 

Ein kurzer Hotbird-Check ergab, dass sich an der Situation nichts geändert hat. Vergiss die polnischen DVB-T und Kabel-Provider nicht, da sieht es auch arg aus (in einem Sample war CharacterTable = 0x16 - Reserved zu finden). Danach kannst du bei den Chinesen weitermachen...

[ö-r-rf]

Jetzt mal im Ernst. Das ist doch verrückt. Jetzt werden sogar Sender falsch dargestellt die sich 100% an die Standards halten nur weil andere Chaoten nicht in der Lage sind ihre Systeme richtig zu konfigurieren und dafür eine Ausnahmeregel erstellt wurde?

 

 

Ich hab einen guten Änderungsvorschlag der alle derartige Probleme einfach und effizient für DVBViewer und Transedit gemeinsam löst:

1. Das interne Zeichensatzhandling wird streng nach Standard(s) durchgeführt. Keine internen Ausnahmeregeln mehr.

2. Es wird eine zentrale "Zeichensatz-Überschreibedatei" angelegt, in der alle die Netze/Anbieter, Transponder und Services landen bei denen die Zeichensätze falsch signalisiert sind.

 

Dank der DVB-Adressierung über das eindeutige Tripple ist das sehr einfach auch mit Platzhaltern zu machen.

 

Eine solche Datei könnte z.B. wie folgt aussehen:

;ONID.TSID.SID,EIT-Charset,SDT-Charset
61441.10003.52019,0x05,0x00   ;einzelnes Programm auf Latin-5 im EPG und ISO6937 in der SDT
1.*,0x0B   ;alle Transponder eines Anbieters auf Latin-9 im EPG
1.1093.*,0x15   ;einen ganzen Transponder auf UTF-8 im EPG

 

Diese Datei wird dann vom DVBViewer und von Transedit gelesen und bei den darin vermerkten Diensten wie dort angegeben die eigentlich gesendete Zeichensatzcodierung überschrieben.

 

Die Datei kann dann beliebig anhand der Nutzerrückmeldungen erweitert werden (z. B. über Wiki) und bietet dann immer eine korrekte Darstellung ALLER Daten von allen Programmen. Das wäre somit ein enormer Vorteil gegenüber der bisherigen Lösung und würde wahrscheinlich auch den Programmcode entschlacken.

[Griga]

Jetzt werden sogar Sender falsch dargestellt die sich 100% an die Standards halten nur weil andere Chaoten nicht in der Lage sind ihre Systeme richtig zu konfigurieren

Welche konkret?

 

Im polnischen Fall gab es damals - wie man es auch drehte und wendete - immer zumindest einen Anbieter, dessen EPG falsch dargestellt wurde, aber Viva Polska, das damals durchs Raster fiel, hat wohl inzwischen keinen EPG mehr, wie ich gestern festgestellt habe.

 

Es wird eine zentrale "Zeichensatz-Überschreibedatei" angelegt, in der alle die Netze/Anbieter, Transponder und Services landen bei denen die Zeichensätze falsch signalisiert sind.

Also ähnlich wie bei MythTV

 

http://www.DVBViewer.tv/forum/topic/38086-epg-polish-tip/

 

Hatte ich auch schon in Erwägung gezogen. Allerdings muss solche Dateien jemand pflegen - Anwender sind oft damit überfordert, spezielle Einstellungen richtig vorzunehmen und zu verwalten - und generell ist die Thematik uferlos, wenn eine Software weltweit zur Anwendung kommt. Bei intensiven Tests und Analysen finde ich regelmäßig Unstimmigkeiten in SI- oder sonstigen Daten, ob das nun falsche NIT-Einträge auf Astra oder als Untertitel gekennzeichnete Newsflash-Teletextseiten sind... oder letztlich nach langer Fehlersuche im eigenen Code falsche Längenangaben in PES-Paketen mit brasilianischen Untertiteln, wie sich mittels Hex Viewer herausstellte. Man versucht dann halt, den Code so zu gestalten, dass er auf Abweichungen möglichst robust reagiert.

 

Manchmal können Anbieter Fehler auch nicht so einfach beheben. Vor einiger Zeit hatte ich die SRG angeschrieben, weil es massive Probleme mit dem EPG gab - Event IDs wurden bei jeder EPG-Aktualisierung anderen Sendungen zugewiesen, was im DVBViewer, der die Daten dauerhaft speichert, zu Chaos führte. Die Anwort lautete, dass man sich des Problems bewusst wäre, aber zur Zeit nichts daran ändern könne, weil dazu ein Software-Update nötig wäre, und die Umstellung frühestens in einem Jahr stattfinden könne...

[ö-r-rf]

Hatte ich auch schon in Erwägung gezogen. Allerdings muss solche Dateien jemand pflegen - Anwender sind oft damit überfordert, spezielle Einstellungen richtig vorzunehmen und zu verwalten - und generell ist die Thematik uferlos, wenn eine Software weltweit zur Anwendung kommt.

 

Wenn du das entsprechend umsetzt würde ich im Gegenzug bei der Pflege dieser Datei helfen.

 

Ich gehe davon aus, dass dies am Anfang zunächst relativ viel Arbeit ist und dann irgendwann aber nur noch wenige Veränderungen braucht.

Wenn die aktuelle Datei immer mit dem DVBViewer mitgeliefert wird würden die wenigsten Anwender davon überhaupt etwas mitbekommen.

 

Für akute Fälle kann man sie dann im Downloadbereich aktualisieren.

Edited July 19, 2012 by ö-r-rf