kein EPG bei RTL

    schein eher ein skin abhängiges problem zu sein. beim swain hd wird es korrekt angezeigt.

    mfg


    OoZooN


    Support für OoZooN Images gibt es auf forum.oozoon.de , nicht hier!


    Two Beer or not two Beer, thats the Question


    Aktuelle Nachrichten rund um OoZooN-Images gibt es auf Twitter

    Ich habe hier kein Problem, weder mit vox, noch mit rtl.



    Ich weiß auch nicht warum ihr euch nicht direkt beim Provider beschwert. Das dürfte doch dann euer Problem eher lösen. :smiling_face:

    mfg.


    schnubbel
    Schiller Fan

    bei mir war der epg von voxhd über sat, nur so zur info.

    mfg


    OoZooN


    Support für OoZooN Images gibt es auf forum.oozoon.de , nicht hier!


    Two Beer or not two Beer, thats the Question


    Aktuelle Nachrichten rund um OoZooN-Images gibt es auf Twitter

    .

    2 Mal editiert, zuletzt von Kerni ()

    • Offizieller Beitrag

    Hi,


    ich hatte mir das vor nen paar Tagen angeschaut. Und den zeichencode der dort für das ß benutzt wird konnte ich auch nach längeren recherchen im Internet keinem bekannten Zeichensatz zuordnen.. also weder einem der in der DVB Spec erlaubt ist, noch irgendeinem anderen. Also das ist in der Tat total kaputt was die da über den äther schicken.


    cya

    .

    Einmal editiert, zuletzt von Kerni ()

    • Offizieller Beitrag

    Hi,


    also ich hab nochmal nachgeschaut. Also diese im Digitalfernsehen angesprochenen Möglichkeiten der unterschiedlichen Zeichsatztabellen unterstützt enigma(2) schon ewig.


    Das Problem ist eher dass es viele Provider gibt die sich nicht an den Standard halten. Aus diesem Grund gibt es in enigma(2) eine Abweichung vom Standard.
    Und genau dieses macht nun bei dem Eurosport Deutschland Transponder ein Problem mit dem ß.


    Also eigentlich ist es in der DVB-Spec ( ETSI EN300468 ) vorgesehen, dass alle Texte die keine spezielle Kennzeichnung der Zeichensatztabelle besitzen, in ISO6397 encodiert werden müssen.


    Das Problem ist aber, dass viele Provider das nicht so handlen. So dass wenn man das dann so macht wie es der Standard eigentlich vorsieht die Folge ist, dass sehr viele Sendernamen und EPG Texte falsch dargestellt werden.
    Konkret äöü und andere Zeichen. Unter anderem bei Sky Deutschland.


    Aus diesem Grund verwendet enigma(2) als Standard die ISO8859-1. Damit passen dann auf den Sky Sendern und anderen wiederrum äöü und andere "Sonderzeichen".


    Wohlgemerkt .. dieses ist nur ein Fallback wenn nichts anderes im Text selber hinterlegt ist. Vor jedem Text kann man explizit die benutzen Tabelle angeben. Was auch sehr vie genutzt wird. Das ist auch der Grund wieso wiederrum auf Eurosport äöü teilweise richtig dargestellt werden. Das ist immer dann der Fall, wenn vor dem Text explizit die passende Zeichnsatztabelle angegeben wurde.


    Naja wie dem auch sei. Dadurch entsteht nun das Problem, dass Texte der Provider die es eigentlich richtig machen teilweise nicht richtig dargestellt werden. Hier eben Eurosport Deutschland. Für solche fällt gibt es in enigma2.. bzw. auf der Box eine Tabelle wo man solche Transponder eintragen kann. Damit man wieder den Standard herstellen kann.


    Ich finde das auch doof, dass es so ist. Aber momentan müsste man halt viel mehr Ausnahmen in dieser Tabelle eintragen wenn man es nach Standard macht.


    Die bessere Lösung wäre eigentlich es wirklich nach Standard zu machen. Und dann diese Providern das mal mitzuteilen, dass sie das falsch machen. Aber z.b. Sky macht das schon Jahre lang so. Ehemals noch Premiere.


    Nunja. Eine schnelle Lösung ist nun in der /usr/share/enigma2/encodings.conf die folgende Zeile einzutragen:

    Code
    0x443 0x1 ISO6397

    Damit funktionieren dann auch die ß wieder.


    Ich werde das bei Gelegenheit denke ich mal auf Standard stellen. Und dann müssen alle wirklich falschen Transponder in der Tabelle hinterlegt werden. Aber vor 2 Jahren hatte ich das schonmal versucht. Und da gab es jede Menge beschwerden. Aus vielen Ländern von den unterschiedlichsten Providern. Also man könnte meinen das sich eben die ISO8859-1 eher als Standard geeignet hätte.


    cya

    Hallo allerseits.


    Ich hab' mich mal auf bitten eines Betroffenen hier angemeldet um mit zu helfen das in den Griff zu bekommen.
    Von mir ist auch der Beitrag im tvdigital Forum bezüglich der CPs.


    Der Beitrag von Ghost ist schon recht nah dran... Allerdings gibt es da noch tiefer gehende Probleme, nämlich dass die meisten Provider zum Erzeugen der Roh-EPG Daten irgendwelche Windows-basierte Software benutzen, und damit fängt der Ärger richtig an - weil Windows nunmal nicht UTF-8 kann. :thumbs_down:


    Wie Ghost schon sagte, halten sich einige EPG Provider nicht an den Standard - oder sie verstehen ihn einfach nicht (man mag es kaum glauben, aber was soll ich euch sagen...) :astonished_face:
    Das führt zu den derzeitig diskutierten Effekten.
    Ghost, es ist in der Tat so, dass Enigma diese Funktionen kann - mein Beitrag im anderen Forum war nicht als Kritik daran gemeint, dass das nicht ginge... Entschuldige mich wenn das so verstanden wurde.


    Nochmal zum Problem:


    Die Sender sollen lt Standard eine Codepage angeben für jedes Event Feld, und zwar mittels erster Ziffer im Text die < 0x20 sein muss, wobei man sich am besten auf <0x0B beschränken sollte, da die restlichen erst später implementiert wurden. Ist sicherer dass es auch überall klappt.


    Im aktuellen Fall gibt RTL für die SI events einfach mal keine CP an:


    table_id = 0x50
    section_syntax_indicator = 1
    section_length = 589
    service_id = 12020
    version_number = 24
    current_next_indicator = 1
    section_number = 48
    last_section_number = 248
    transport_stream_id = 1089
    original_network_id = 1
    segment_last_section_number = 48
    last_table_id = 0x51
    Events [1]...
    event_id = 39087
    start_time = 55783 (MJD) [GMT: WED 10.AUG 2011 18:14:00]
    duration = 153856 [02:59:00 hh:mm:ss]
    running_status = Status #0x00
    free_CA_mode = 0 [free to air]
    descriptor_loop_length = 562
    Event-Descriptors [4]...
    Descriptor Type = short_event_descriptor, descriptor_tag: 0x4D
    ISO_639_language_code = 0x676572 [ger]
    event_name_length = 44
    event_name = Der groûe deutsche Love & Sex-Test by RTL II
    text_length = 0
    text =
    Descriptor Type = extended_event_descriptor, descriptor_tag: 0x4E
    descriptor_number = 0
    last_descriptor_number = 1
    ISO_639_language_code = 0x676572 [ger]
    length_of_items = 0
    text_length = 249
    text = «codepage 05»Der große deutsche Love & Sex-Test by RTL II. Können Spermien riechen? Was bewirkt die "Spanische
    Fliege"? Und: Ziehen sich Gegensätze wirklich an? Sex spielt in unserem Leben eine entscheidende Rolle. Doch wie viel wissen wir
    wirklich über Liebe, [Der große deutsche Love & Sex-Test by RTL II. Können Spermien riechen? Was bewirkt die "Spanische Fliege"?
    Und: Ziehen sich Gegensätze wirklich an? Sex spielt in unserem Leben eine entscheidende Rolle. Doch wie viel wissen wir wirklich über
    Liebe, ]
    Descriptor Type = extended_event_descriptor, descriptor_tag: 0x4E
    descriptor_number = 1
    last_descriptor_number = 1
    ISO_639_language_code = 0x676572 [ger]
    length_of_items = 0
    text_length = 242
    text = «codepage 05»Lust und Leidenschaft? Bei RTL II kann nun jeder testen, wie aufgeklärt er ist. Prominente wie Dirk Bach
    und Dolly Buster stellen sich ebenso den knifflig-pikanten Fragen von Moderatorin Sonja Zietlow wie das Publikum im Studio. Auch die
    ... [Lust und Leidenschaft? Bei RTL II kann nun jeder testen, wie aufgeklärt er ist. Prominente wie Dirk Bach und Dolly Buster
    stellen sich ebenso den knifflig-pikanten Fragen von Moderatorin Sonja Zietlow wie das Publikum im Studio. Auch die ...]
    Descriptor Type = content_descriptor, descriptor_tag: 0x54
    content_level_1_nibble = 3 [Show/Game Show]
    content_level_2_nibble = 0
    user_level_1_nibble = 0
    user_level_2_nibble = 0
    CRC_32 = 0x04E9AD8F



    Wie man sehen kann, gibt's keinen Codepage-Indikator beim Short_Event_Descriptor... Im Gegensatz zum extended_event_descriptor... (das Zeichen wird im Dump automatisch in einen lesbaren String umgewandelt weil Windows die Control-Codes nicht darstellen kann...)


    Wenn man sich aber nun die short_event_decsriptors mal über Zeit anschaut, dann sieht man dass Umlaute dargestellt werden, nur eben ß nicht.
    Statt ß bekommt man û. Nun fanden wir dass û in CP 5 dem ß in CP 0 entspricht. Und das ist seltsam. Denn zunächst dachten wir dass RTL CP 0 benutzt, viele Receiver aber bei fehlender Angabe der CP einfach CP 5 wählen, die normal wäre für unsere Breiten. Man scheint aber etwas anderes zu machen. Denn CP 0 kann keine Umlaute außer ß.


    Seltsam ist das.


    Was macht Engima wenn keine CP angegeben wird? Nutzt es dann wie im Standard vorgesehen die CP 0?
    Denn dann dürfte es doch keine Umlaute geben...


    Das würde bedeuten, dass schon die Codierung des Textes keiner eindeutigen Codepage zuweisbar wäre...?


    Ideen?



    Gruß,


    C.

    • Offizieller Beitrag

    Hi,


    ich zitiere einfach mal aus der spec:


    "A.2 Selection of character table
    Text fields can optionally start with non-spacing, non-displayed data which specifies the alternative character table to be
    used for the remainder of the text item.
    If the first byte of the text field has a value in the range "0x20" to "0xFF" then this and all subsequent bytes in the text
    item are coded using the default character coding table (table 00 - Latin alphabet) of figure A.1."


    Konkret geht es dabei um das "optionally" ... und wenn nicht.. dann ist der standard diese table 00.. und das ist die ISO6397 tabelle von der ich in meinem vorherigen Posting sprach.


    Und genau diese sollte eben standard sein, wenn dieses zeichen < 0x20 nicht gesetzt ist. Was aber eben in enigma(2) aus oben zitierten Gründen nicht so ist, weil sehr viele Provider davon ausgehen (oder es einfach so wollen) dass eben die ISO-8859-1 standard ist.
    ISO-8859-1 ist aber nicht identisch mit der ISO6397.


    Wie gesagt.. der Fix ist solange enigma(2) ISO6397 nicht als Standard benutzt den Transponder in der angegeben encodings.conf auf ISO6397 zu setzen. Dann klappt das. Bzw. muss man das mit allen Transpondern tun, die sich wirklich an die spec halten und die ISO6397 voraussetzen.


    cu

    Hi,


    das erklärt einiges, danke für die Infos.


    Bei RTL passiert aber dann nochwas seltsames, weil wir uns mit dem Programm, dass den Dump erzeugt hat den ich angegeben hatte, an den Standard halten.
    Deshalb müsste das eigentlich anders aussehen.


    Ich sehe mir das nochmal genauer an und melde mich dann nochmal.



    Gruß,


    C.