epg.data mit Dauer=0

  • Hallo zusammen,


    ich habe Probleme mit meinem EPG wie hier geschildert.

    System ist eine streamdev Client/Server Umgebung.

    Server:

    Client ebenfalls Version 2.6.1.

    Auf dem Client habe ich eine epg.data Datei, die in der "E"-Zeile bei allen Einträgen 0 bei Dauer stehen hat.


    cat epg.data | grep ^Eauf dem Client:

    cat epg.data | grep ^Eauf dem Server:

    Für mich sieht das aus, als tauchten die 2400s vom Server als Hexwert 0x960 auf dem Client eine Spalte weiter hinten wieder auf. Wer kann dafür verantwortlich sein, bzw. wo im Code müsste ich suchen?


    Danke

    Andreas

  • So, gleich nochmal ich:


    Ich habe jetzt in der epg.h gesehen, dass starttime als time_t definiert ist. Wenn ich mich richtig erinnere, gabs mal was mit time_t auf 32 und 64bit...

    Server ist ein i686 32bit System (ja, wirklich), Client ein aarch64.


    Kanns damit zusammenhängen?

    Gruß

    Andreas

  • Da die Anfangszeiten ja richtig erscheinen glaube ich nicht, dass es mit time_t zu tun hat.


    VDR schreibt die Zeile raus mit

    fprintf(f, "%sE %u %ld %d %X %X\n", Prefix, eventID, startTime, duration, tableID, version);


    Beim Client fällt auf, dass die Version fehlt, also nehme ich an, dass diese Zeilen nicht von VDR geschrieben wurden, sondern von irgend einem Plugin.

  • Auf dem Client läuft nur streamdev, skinnopacity, softhddevice-drm und tvguide.

    In streamdev ist "Filter Daten streaming" aktiviert, so dass sich vdr seine epg.data nach meinem Verständnis selbst baut. Ich habe sie gerade gelöscht und nach dem nächsten epg data writer thread stimmts wieder nicht. Duration ist 0 und starttime taucht als Hex-Wert eine "Spalte" später auf. TableID ist in der letzten Spalte und Version gibts gar nicht. Ein epgscraper-irgenwas habe ich nicht.


    Der fprintf Aufruf schaut ja eigentlich gut aus, wo werden startTime und duration geholt? Für mich schaut es so aus, als wäre bei dem Aufruf duration schon 0 oder NULL? Und in tableID steht duration, in version die tableID und version dann irgendwo...

  • Es liegt an dem fprintf. Wenn ich mir hier mit esyslog die 4 Werte starttime, duration, tableid und version getrennt ausgeben lasse, stimmt es. Nur in der epg.data landen sie nicht richtig. (Das %10ld) stammt von mir.

  • Könnte gut die Ursache sein. 'long' kann 32 oder 64 bit sein.


    Eine Alternative wäre so etwas wie PRId64 und parsen mit int64_t


    Code
    printf("%" PRId64 "\n", t);
  • Ja, fprintf und %ld wars. Wenn ich im fprintf mit (long) caste, funktioniert es hier auf aarch64.

    Ich bin mir allerdings nicht sicher, wie das am sichersten gemacht wird, damit 32bit/64bit und sämtliche time_t Größen abgedeckt sind.

    Ich denke, da spielen die Y2038 Patches im Kernel evtl. auch mit.


    Gruß

    Andreas

  • Da ich das automatisch mit github actions bauen lasse, ist es mir nicht aufgefallen. Aber ja, die Warnungen kommen. Im Prinzip immer, wenn time_t als %ld geschrieben werden soll:

    https://pastebin.com/Xt12eej0

    z.B. Zeile 592


    time_t ist auf dem System ein long long int und das beißt sich mit %ld. Betrifft auch andere Stellen und auch in den Plugins ist das nicht überall sauber...


    Gruß

    Andreas

  • rell Danke, ich gehe dem nach.


    Hat jetzt nicht direkt mit dem Problem zu tun, ich wundere mich nur, woher die '10' in '%10ld' kommt:


    fprintf(f, "%sE %u %10ld %d %X %X\n", Prefix, eventID, startTime, duration, tableID, version);

    Original sieht die Zeile so aus:


    fprintf(f, "%sE %u %ld %d %X %X\n", Prefix, eventID, startTime, duration, tableID, version);


    Das Gleiche gilt für die entsprechende scanf()-Zeile weiter unten.

  • Die "10" ist von mir. Das Log ist von einem Code-Stand, wo ich gestern rumprobiert habe...


    Und ja, da sind ein paar Patches drin... ;) Aber die sollten mit dem Problem nichts zu tun haben.

  • Die Meldungen bei den Zeilen sind schon mal weg, bei scanf ist sie (natürlich) noch da. Wie die epg.data aussieht, teste ich später.

    Danke schonmal.

  • Schaut gut aus, VPS stimmt auch wieder.

  • https://pastebin.com/raw/DUzxYtCH


    Hier nochmal das Log. Ich sehe nur noch -Wparantheses und eine -Wdangling-else Warnung.

    Danke!

  • 2022-11-22T15:26:42.5188725Z menu.c: In constructor 'cMenuRecording::cMenuRecording(const cRecording*, bool, bool)':

    2022-11-22T15:26:42.5189533Z menu.c:2922:6: warning: suggest explicit braces to avoid ambiguous 'else' [-Wdangling-else]

    2022-11-22T15:26:42.5189813Z 2922 | if (withButtons)

    2022-11-22T15:26:42.5189984Z | ^

    --> da ist kein 'else' (Patch?)


    2022-11-22T15:26:42.5190543Z menu.c: In member function 'void cDisplayChannelExtended::CursorUp(cSkinDisplayChannelExtended*)':

    2022-11-22T15:26:42.5191474Z menu.c:5939:23: warning: suggest parentheses around assignment used as truth value [-Wparentheses]

    2022-11-22T15:26:42.5192015Z 5939 | } else if (state = esGroupsList) {

    2022-11-22T15:26:42.5192307Z | ~~~~~~^~~~~~~~~~~~~~

    --> In VDR gibt es kein 'esGroupsList' (Patch? ggf. Bugreport an Patch-Autor!)

  • 2022-11-22T15:26:42.5188725Z menu.c: In constructor 'cMenuRecording::cMenuRecording(const cRecording*, bool, bool)':

    2022-11-22T15:26:42.5189533Z menu.c:2922:6: warning: suggest explicit braces to avoid ambiguous 'else' [-Wdangling-else]

    2022-11-22T15:26:42.5189813Z 2922 | if (withButtons)

    2022-11-22T15:26:42.5189984Z | ^

    --> da ist kein 'else' (Patch?)

    Das ist der vdr-2.6.1-undelete.patch.

    2022-11-22T15:26:42.5190543Z menu.c: In member function 'void cDisplayChannelExtended::CursorUp(cSkinDisplayChannelExtended*)':

    2022-11-22T15:26:42.5191474Z menu.c:5939:23: warning: suggest parentheses around assignment used as truth value [-Wparentheses]

    2022-11-22T15:26:42.5192015Z 5939 | } else if (state = esGroupsList) {

    2022-11-22T15:26:42.5192307Z | ~~~~~~^~~~~~~~~~~~~~

    --> In VDR gibt es kein 'esGroupsList' (Patch? ggf. Bugreport an Patch-Autor!)

    Und das der vdr-2.4.0_zapcockpit-v2.patch.


    Wie gesagt, über Patches und Plugins müsste man wohl auch irgendwann mal drüber ;)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!