[Patch] Common Interface - Ressource Date-Time - UTC-Offset abgeschnitten

  • Hallo,
    habe mich mal angemeldet, weil ich in der Implementierung der Date-Time-Ressource im CI-Host einen Bug gefunden habe:

    Wenn über die Ressource Datum/Zeit angefragt werden, antwortet der CI-Host ja mit Datum/Zeit plus dem UTC-Offset in Minuten. Das Ganze ist in einer Struktur von 7 Byte verpackt, die im VDR mit einem struct nachgebildet wird.
    Das Problem ist: Im Speicher belegt das struct dann 8 Byte, weil das 16bit-Feld für den UTC-Offset an einer 2-Byte-Grenze ausgerichtet wird; entsprechend liegt im Speicher vor diesem Feld ein zusätzliches Padding-Byte (0x7F im Beispiel unten). Nachher bei SendData werden dann 7 Byte ab struct-Anfang ausgegeben; dabei entfällt durch das Padding-Byte dann das LSB vom UTC-Offset und ein falscher Wert wird übertragen (inwiefern sich das in der Praxis auswirkt, sei mal dahingestellt).

    Beispiel:

    Code
    Slot 1: ==> Date Time (4)
     	1: --> 00 01 A0 10 01 90 02 00 04 9F 84 41 07 DD 60 17 04 38 7F 00

    Angehängt ist ein Patch, der den Bug behebt, bezogen auf die Version 2.0.5. Statt in einem struct wird die Antwort jetzt in einem Bytearray zusammengebaut.
    (Die beiden 16bit-Werte Jahr und Offset könnte man theoretisch noch vorberechnen, damit man die jeweilige Berechnung nicht pro Byte macht.)

    Edit: Die Vorberechnung ist sogar Pflicht, weil man die Variable nachher in einem Schritt einsetzen muss, damit nach htons die korrekte Bytereihenfolge zum Tragen kommt; also Version 2.
    Edit 2: Ohne Zwischenvariable geht das auch; (letzte) Version 3.

  • Danke
    Nur so rein intressehalber könnte/ist das der Auslöser für:
    https://www.vdr-portal.de/board18-vdr-ha…t-mehr-erkannt/

    sein ???

    Signatur

    Server: ASRock Q1900M + 4GB RAM + cineS2 6.5 + Debian 8 + vdr 2.x , epgsearch, live, streamdev
    Client: Macbook Pro Retina 2015 + 16GB ram 512GB ssd  OSX 10.11.1)
    File-Server/client: GA-Z77-DS3H (Ozmosis 1669 ) + I3 2105 + 16GB RAM NVGF 650GTX 1GB, 250 GB-HD (sys)+ 44TB Storage OSX 10.11.6 VLC 3.x beta , Remote Buddy, PS3-FB
    2x Cubieboard2: 16GB microSD, debian mit VDR 2.0.6 + epgsearch, live(osdpatch), streamdev(0.6), soft-hd-device
    Ausgabe:
    Acer H7530D, T.amp Proline1300, 2x K&H sms 54T + horn sub - Eigenbau


  • Wenn über die Ressource Datum/Zeit angefragt werden, antwortet der CI-Host ja mit Datum/Zeit plus dem UTC-Offset in Minuten. Das Ganze ist in einer Struktur von 7 Byte verpackt, die im VDR mit einem struct nachgebildet wird.
    Das Problem ist: Im Speicher belegt das struct dann 8 Byte, weil das 16bit-Feld für den UTC-Offset an einer 2-Byte-Grenze ausgerichtet wird; entsprechend liegt im Speicher vor diesem Feld ein zusätzliches Padding-Byte (0x7F im Beispiel unten). Nachher bei SendData werden dann 7 Byte ab struct-Anfang ausgegeben; dabei entfällt durch das Padding-Byte dann das LSB vom UTC-Offset und ein falscher Wert wird übertragen (inwiefern sich das in der Praxis auswirkt, sei mal dahingestellt).

    Beispiel:

    Code
    Slot 1: ==> Date Time (4)
     	1: --> 00 01 A0 10 01 90 02 00 04 9F 84 41 07 DD 60 17 04 38 7F 00

    Angehängt ist ein Patch, der den Bug behebt, bezogen auf die Version 2.0.5. Statt in einem struct wird die Antwort jetzt in einem Bytearray zusammengebaut.
    (Die beiden 16bit-Werte Jahr und Offset könnte man theoretisch noch vorberechnen, damit man die jeweilige Berechnung nicht pro Byte macht.)

    Edit: Die Vorberechnung ist sogar Pflicht, weil man die Variable nachher in einem Schritt einsetzen muss, damit nach htons die korrekte Bytereihenfolge zum Tragen kommt; also Version 2.
    Edit 2: Ohne Zwischenvariable geht das auch; (letzte) Version 3.


    Noch einfacher müsste es doch so gehen:

    Code
    #pragma pack(1)
      struct tTime { uint16_t mjd; uint8_t h, m, s; short offset; };
    #pragma pack()

    Klaus


  • Nur so rein intressehalber könnte/ist das der Auslöser für:
    https://www.vdr-portal.de/board18-vdr-ha…t-mehr-erkannt/

    sein ???


    Das Problem dort war offensichtlich in der CAM-Firmware. Mit der V3.27 klappt es wieder anstandslos.
    Warum es allerdings bei der vorherigen FW-Version mit VDR nicht ging, mit dem TV-Gerät aber schon, kann ich mir auch nicht erklären.

    Klaus

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!