epg.data mit Dauer=0

Hallo zusammen,

ich habe Probleme mit meinem EPG wie hier geschildert.

System ist eine streamdev Client/Server Umgebung.

Server:

vdr (2.6.1/2.6.1) - The Video Disk Recorder
conflictcheckonly (0.0.1) - Direct access to epgsearch's conflict check menu
epgsearch (2.4.1) - search the EPG for repeats and more
epgsearchonly (0.0.1) - Direct access to epgsearch's search menu
epgtableid0 (2.4.0) - EPG handler for events with table id 0x00
hello (2.4.0) - A friendly greeting
live (3.1.3) - Live Interactive VDR Environment
markad (3.0.18 (6c73e7c)) - Mark advertisements
osddemo (2.4.1) - Demo of arbitrary OSD setup
pictures (2.4.0) - A simple picture viewer
quickepgsearch (0.0.1) - Quick search for broadcasts
restfulapi (0.2.6.5) - Offers a RESTful-API to retrieve data from VDR
skincurses (2.4.3) - A text only skin
status (2.4.0) - Status monitor test
streamdev-client (0.6.1-git) - VTP Streaming Client
streamdev-server (0.6.1-git) - VDR Streaming Server
svccli (2.4.0) - Service demo client
svcsvr (2.4.0) - Service demo server
svdrpdemo (2.4.0) - How to add SVDRP support to a plugin
vdrmanager (0.15) - VDR-Manager plugin
vnsiserver (1.8.0) - VDR-Network-Streaming-Interface (VNSI) 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:

E 8780 1669592400 0 960 51
E 8781 1669594800 0 A8C 51
E 8782 1669597500 0 A8C 51
E 8783 1669600200 0 A8C 51
E 8784 1669602900 0 A8C 51
E 8785 1669605600 0 A8C 51
E 8786 1669608300 0 A8C 51
E 8787 1669611000 0 960 51
E 8788 1669613400 0 834 51
E 8789 1669615500 0 5DC 51
E 8790 1669617000 0 A14 51
E 8791 1669619580 0 78 51
E 8792 1669619700 0 A8C 51
E 8793 1669622400 0 BB8 51
E 8795 1669625400 0 A8C 51

cat epg.data | grep ^Eauf dem Server:

E 8780 1669592400 2400 51 1E
E 8781 1669594800 2700 51 1E
E 8782 1669597500 2700 51 1E
E 8783 1669600200 2700 51 1E
E 8784 1669602900 2700 51 1E
E 8785 1669605600 2700 51 1E
E 8786 1669608300 2700 51 1E
E 8787 1669611000 2400 51 1E
E 8788 1669613400 2100 51 1E
E 8789 1669615500 1500 51 1E
E 8790 1669617000 2580 51 1E
E 8791 1669619580 120 51 1E
E 8792 1669619700 2700 51 1E
E 8793 1669622400 3000 51 1E
E 8795 1669625400 2700 51 1E

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

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.

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

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!

Quote from kls

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.

Quote from kls

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