Absturz wegen cEvent::title == NULL - Warum???

Ich habe einen Eintrag bei Sky:

C S19.2E-133-4-143 Sky Sport Austria 1
...
E 45951 1741550400 4500 4E 13
T Live Talk & Tore: Fußball-Talk
S Talk und Tore Fußball-Talk
D Kontroverse Diskussionen mit hochkarätigen Studiogästen und Experten: Österreichs bester Fußball-Live-Talk bietet Zuschauern aktuellste Informationen rund um den heimischen Fußball.
G 40 43
X 5 0B deu 16:9
X 4 2C deu DOLBY
e
E 46365 1741554900 1800 4E FF
e
E 45953 1741556700 1800 4E 17
T Admiral BL: ASAT Kompakt, 21. Runde
S Fußball: Österreich, Admiral Bundesliga ASAT Kompakt, 21. Runde
D Alle Spiele, alle Tore: Der Spieltag der ADMIRAL Bundesliga im Rückblick.
G 40 43
X 5 0B deu 16:9
X 4 2C deu DOLBY
e

wobei die Zeit 1741556700 = So 9. Mär 22:45:00 CET 2025 ist und die Dauer 1800s = 30 min exakt in die Lücke der beiden anderen Events reinpasst, also evtl. ein Filler-Event?
Was mich wundert ist, dass er bis jetzt (14 h später, EPGLinger = 60) noch nicht gelöscht ist. Der VDR wurde mindestens einmal neu gestartet, also auch die epg.data neu eingelesen und der Titel nicht korrigiert.

Die beiden anderen leeren Events finde ich bei mir nicht. Interessant wäre aber deren Sender (in epg.data nach ^C davor suchen)

Edit: Sowohl das VDR-Menü (Version 2.7.3) als auch EPGsearch zeigen den Eintrag korrekt mit "Kein Titel" an wenn man die EPG-Linger-Zeit entsprechend hoch einstellt

Quote from MegaV0lt

Man beachte das e zu beginn der letzten Zeile

Dann liefert die Grep-Regex in dem Fall das ganze Event.

Quote from SHF

Irgendwie sehe aber auch keine ich Möglichkeit, wie sich ein Event an der Korrektur vorbei mogeln kann.

Doch, es gibt genau eine Möglichkeit und die ist an sich völlig offensichtlich!
Keine Ahnung, warum ich das gestern übersehen habe, aber ein continue (Zeile 230) liegt zwischen erstellen des Events (Zeile 177) und FixEpgBugs() (Zeile 411), das muss es sein.

Das mit den obsoleten Kanälen würde da auch passen, wenn Process da false ist, aber normalerweise true wäre.

Wenn man Zeile 229 wie folgt abändert, sollte eigentlich Schluss mit dem Spuk sein.
if (!Process && !pEvent)
Wobei es vermutlich logischer/sinnvoller wäre, das Event zu löschen und aus den Schedule zu entfernen.
Das Process==false soll ja wohl bedeuten, dass man es nicht haben will ???

Irgendwas ist an der Stelle aber komisch.
Die Variable *newEvent wird eigentlich überhaupt nicht benötigt. Ich denke as hat mich gestern in die Irre geführt.
newEvent wird nur 3 mal verwendet und ist immer gleich pEvent, da müsste man doch auch gleich pEvent schreiben können? Evtl. Altlast oder wollte man zB. in Zeile 229 nach !newEvent abfragen ???
Und warum wird erst so spät nach Process abgefragt?

Das muss man sich wohl erst mal in Ruhe ansehen, bevor man was ändert.
Soweit ich das überblicke müsste es sich an der Stelle um now/next-Events handeln, da könnten sich Änderungen aufs VPS auswirken.
Auch die EPG-Samples zeigen, dass es irgendetwas in der Art seine müsste. -Danke an die "EPG-Provider" -
Ob die Events allerdings "sinnvoll" kann ich momentan nicht beurteilen.
Irgendwie passt das mit dem now/next auch nicht wirklich . Für mich sieht es momentan eher nach "Datenmüll" aus.

Dass ich die nicht habe kann an der VDR-Version liegen.
Oder, falls die Events von einem anderen Transponder kommen an diesem Patch: RE: Arte EPG verhindert Suchtimeraufnahmen
Oder einer Kombination aus beiden.
Die ARD-Regionalen und Sky waren immer die Kandidaten mit den Transponder-übergreifenden Events.

Quote from FireFly

Was mich wundert ist, dass er bis jetzt (14 h später, EPGLinger = 60) noch nicht gelöscht ist. Der VDR wurde mindestens einmal neu gestartet, also auch die epg.data neu eingelesen und der Titel nicht korrigiert.

Das hätte ich jetzt auch nicht erwartet.
Evtl. wird die Korrektur beim nächsten EPG-Scan wieder kaputt korrigiert???

Irgendwas ist bei den Events jedenfalls nicht ganz in Ordnung.

Quote from FireFly

Die beiden anderen leeren Events finde ich bei mir nicht. Interessant wäre aber deren Sender (in epg.data nach ^C davor suchen)

Ich muss auch erst noch mal schauen, würde aber stark auf eine Variante des BR tippen.
C S19.2E-1-1023-5809 Franken Plus HD

Bei mir sieht die Stelle aktuell so aus:

E 39062 1741593600 1800 50 13
T Medienwerkstatt (Wh.)
S Dokus und Reportagen aus NÃŒrnberg und der Region. [...]
D Die MEDIENWERKSTATT [...]
e
E 39063 1741595400 900 50 13
T Heute bin ich ... (Wh.)
S Heute bin ich ...
e
E 39064 1741596300 1800 50 13
T Medienpraxis (Wh.)
D Reportagen, Portraits & Dokus. Mehr Informationen finden Sie unter www.medienpraxis.tv
e

(Beschreibung im ersten Event etwas gekürzt [...])

Was die EventID macht ist irgendwie komisch.
Beim Ersten (39062) stimmt die noch überein, dann aber nicht mehr.
Bei mir wird dann lückenlos bis 39466 hoch gezählt, dann springt es auf 38571 zurück.
Die IDs 39470 und 39471 gibt es bei mir bei dem Kanal gar nicht.

Auch die Version "FF" von dem "komischen" Event macht logisch keinen Sinn.
Das bedeutet wohl aber, dass die Version nie gesetzt wurde.

Ich habe mir das mir das mit Process nochmal angesehen.

  bool Check(uchar Version, int SectionNumber);
      ///< Returns true if Version is not the current version, or the given SectionNumber has not
      ///< been marked as processed, yet. Sections are handled in ascending order, starting at 0,
      ///< unless Random is true in the constructor call.

Ich interpretiere das so, dass, wenn Process false wird, keine neuen EPG-Informationen verfügbar sind.

Warum wir dann in Zeile 93 eine Ausnahme für Tid 0x4E gemacht?
Ich vermute mal eine Art Hack fürs VPS um den RunningStatus vom aktuellen Transponder zu bekommen?
Aber sollte nicht eigentlich auch die Änderung des RunningStatus zu einem Process==true führen?

Quote from SHF

Bei mir wird dann lückenlos bis 39466 hoch gezählt, dann springt es auf 38571 zurück.
Die IDs 39470 und 39471 gibt es bei mir bei dem Kanal gar nicht.

Das ist aber nicht ungewöhnlich. Ich habe bei der Entwicklung meines EPG-Plugins festgestelt, dass normalerweise die Event IDs hochgezählt werden, aber wenn z.B. in der ARD ein "Brennpunkt" eingeschoben wird bekommt der die nächste freie (und damit höchste) Nummer. Bei Dir sieht das so aus, als wären alle vor 38571 ersetzt worden, was wohl vollkommen DVB-konform ist. Und jeder Sender (bzw. deren Software) handhabt das etwas anders, aber die EventID ist pro Kanal immer eindeutig (abgesehen davon, dass sie sich irgendwann wiederholen, aber der alte Event ist dann nicht mehr im EPG drin)

Quote from SHF

Auch die Version "FF" von dem "komischen" Event macht logisch keinen Sinn.
Das bedeutet wohl aber, dass die Version nie gesetzt wurde.

Naja, Sinn macht das schon, um anzuzeigen, dass die Version nicht gesetzt wurde - zumindest seit Start des VDR (DVB nutzt nur Versionsnummern von 0 bis 31). Der eingelesene Wert wird ja in cEvent::Read() lt. dem Kommentar absichtlich ignoriert. Ich vermute das passiert, um beim nächsten EPG-Scan immer die aktuelle Version des Events zu erhalten - auch bei Sendern die die DVB-Spezifikation etwas lockerer sehen ...

Ich fürchte wir fangen aber langsam an, die EPG-Software der Sender zu debuggen

Quote from FireFly

Das ist aber nicht ungewöhnlich. Ich habe bei der Entwicklung meines EPG-Plugins festgestelt, dass normalerweise die Event IDs hochgezählt werden, aber wenn z.B. in der ARD ein "Brennpunkt" eingeschoben wird bekommt der die nächste freie (und damit höchste) Nummer.

Was ich merkwürdig fand, war eher, dass ab 39062 sauber hoch gezählt wird.
Keine Spur mehr von Events 39470 und 39471. Das sieht fast so aus, als ob die nie da waren.
Und meine Version ist neuer als die von @kfb77 und MegaV0lt.

Da die Events, soweit ich das sehe, aber eindeutig sind und auch die Zeiten jetzt zu stimmen scheinen, ist das wohl Standard konform.
Trotzdem hatte ich das so irgendwie nicht erwartet....

Immerhin ist das "komische" Event bestätigt.
Eine Race-Condition im VDR also eher unwahrscheinlich.

Quote from FireFly

Naja, Sinn macht das schon, um anzuzeigen, dass die Version nicht gesetzt wurde - zumindest seit Start des VDR (DVB nutzt nur Versionsnummern von 0 bis 31).

Das FF kommt vermutlich noch aus dem Konstruktor vom Event.
Ich gehe davon aus, dass es das Event nie über Zeile 234 von eit.c (pEvent->SetVersion(getVersionNumber());) geschafft hat.

Meine Vermutung, was passiert, ist die folgende (bitte korrigieren, falls jemand eine Fehlannahme sieht):

Trotz Process==false werden die Events mit TableID erneut 0x4E aktualisiert (Zeile 93).
Dabei wird ein neues Event erstellt. Das sollte eigentlich nicht passieren, da die Daten schon mal verarbeitet wurden (daher auch das Process==false), aber es passiert.
Dann wird die Verarbeitung, nach Aktualisierung des RunningStatus, vorzeitig abgebrochen, da man keine Änderung im Event erwartet.

Warum beim rescan ein neues Event erstellt wird ist mir bislang auch unklar, das sollte nicht passieren.
Meine Vermutungen wären, dass entweder das Event aus dem letzten Scan:
a) - schon gelöscht wurde.
b) - nie erstellt wurde, weil im weiteren Verlauf des Erstellens erkannt wurde, dass es sich um Unsinn handelt.
c) - sich noch im Schedule befindet aber nicht gefunden wird.

Mein aktuell bester Vorschlag das zu lösen wäre der folgende:

            continue;
        // If we don't have that event yet, we create a new one.
        // Otherwise we copy the information into the existing event anyway, because the data might have changed.
+        if (!Process) // A rescan should not find new events!
+           continue;
        pEvent = newEvent = new cEvent(SiEitEvent.getEventId());
        newEvent->SetStartTime(StartTime);
        newEvent->SetDuration(Duration);

Zumindest die Fälle a) und b) müssten damit korrekt behandelt sein.

Fall c) muss man sich noch mal ansehen.
Evtl. könnte es Sinn machen mal eine Debug-Meldung vor dem continue einzubauen.
Ich hoffe, dann kann man einschätzen, ob da nur veraltete Events, Datenmüll, usw. kommt oder auch was Wichtiges dabei ist

Sowas in der Art (ungetestet!) :
dsyslog("NoProcess: channel %d (%s) eventID %d times %s-%s", Channel->Number(), Channel->Name(), SiEitEvent.getEventId(), *TimeString(StartTime), *TimeString(StartTime + Duration));

Edit:
Mir ist gerade aufgefallen, dass bei mit im EPG immer nur maximal 2 Events mit TableID 0x4E pro Sender existieren. Was bei Now/Next-Events durchaus logisch ist.
Bei den Beispielen von FireFly und kfb77 sind es aber 3. Da ist also mindestens eines zu viel!
Und ich denke, es ist nicht das "komische" Event. Das ist neu und sollte das Aktuelle, Korrekte sein.

Ich befürchte, der Sender mach da irgendwelchen Unfug mit TableID 0x4E.
Entweder er ändert EventId von solchen Events oder setzt TableID 0x4E bei Events, wo es nicht passt.
Events mit TableID 0x4E sucht der VDR nur anhand der EventId und wenn die sich ändert, wird das Event nicht gefunden.
Eine einmal auf 0x4E gesetzte TableID scheint man auch nicht wieder entfernen zu können, selbst wenn man das Event findet (Zeile 188).
Das Ganze wird doch noch richtig kompliziert ...

Ich habe mir heute noch mal die Mühe gemacht und die Zeiten in ein lesbares Format dekodiert.
Dabei ist mir aufgefallen, dass ich am Montag gedanklich wohl um einen vollen Tag falsch lag .
Meine epg.data ist die ältere und muss wohl irgendwann in der Nacht abgespeichert worden sein.
(Mein VDR hatte ab Nachmittag mehrere Aufnahmen gemacht, daher hatte ich damit gerechnet, dass meine epg.data aktueller ist.)

Mit dem Hintergrund machen auch die Änderungen im EPG Sinn.
Da ist in der Zwischenzeit halt was aktualisiert worden.

Die EPG-Daten von MegaV0ltund kfb77 sind anscheinend aktuell, wenn man den Beitrag bzw. das unvollständige Event als Maßstab nimmt.
Daher scheint die Verwendung von TableID 0x4E auch in Ordnung zu sein. Zumindest sieht das jetzt vom timing her plausibel aus.

Mit dem Hintergrund habe ich, denke ich, auch die (oder zumindest eine plausible) Ursache für das unvollständigen Events gefunden.
Anhand der EPG-Daten lässt sich belegen, dass das fragliche Event die EventID gewechselt hat.
Wenn fragliche Event da schon TableID 0x4E hat, bzw. auf TableID 0x4E wechselt, wird es vom VDR nicht mehr gefunden und ein neues mit der neuen eventID Event angelegt. (Bei Events mit TableID 0x4E nur nach EventID gesucht siehe eit.c Z. 169-170.)
Die Folge ist, dass man zwei Events mit gleicher Startzeit (die hat sich nicht geändert) im Schedule hat.
Das würde zu Problemen führen, daher wird eines davon gelöscht. (eit.c Z. 433 DropOutdated())
In DropOutdated() müsste das in epg.c Z. 1124 geschehen (bei den viele Ausnahmen für TableID 0x4E ist das aber etwas schwierig nachzuvollziehen).
Der Schedule ist nach Startzeit aufsteigend sortiert. Events gleicher Startzeit dann noch aufsteigend nach EventID.
Gelöscht wird bei Events gleicher Startzeit (die nach dem Sortieren ja immer hintereinander auftreten) das zweite, also das mit der höheren EventID. In unserem Fall ist das aber das Falsche!
Da das Event gelöscht wurde, wird es bei erneuten Durchlauf natürlich erneut gefunden.
Damit rechnet aber niemand, keine Neuen Daten vorliegen und der Durchlauf eigentlich nur den Runningstatus aktualisieren soll (?). Daher wird danach auch abgebrochen und das Event nicht vollständig "befüllt". Auch wird am EndeDropOutdated() nicht aufgerufen, das unvollständige bleibt also im Schedule.

Was mit dem Event, was hätte ersetzt werden müssen, passiert ist, bin ich nicht sicher.
Evtl. ist es immernoch im Scheduele aber man sieht es nicht?

Als Workaround könnte man die Erstellung des Events zu Ende durch laufen lassen:
(Das wäre quasi das Gegenteil zu meinem letzten Vorschlag)

              }
           pSchedule->SetRunningStatus(pEvent, RunningStatus, Channel);
           }
-         if (!Process)
+         if (!Process && !newEvent)
           continue;
        }
     pEvent->SetVersion(getVersionNumber());

Irgendwie sieht es fast so aus, als ob das so schon mal angedacht war, jetzt ist die Variable *newEvent auf einmal nützlich.
Eine wirklich fertige Lösung ist das aber so noch nicht. Da fehlt eigentlich noch mindestens ein SortSchedule() und das Problem mit 2 Events gleicher Startzeit besteht potenziell noch immer.
Aber immerhin besser als Events ohne Titel, die eigentlich einen hätte.

Ich denke es ist sinnvoller das weiter vorne abzufangen und hier den vorherigen Patch zu verwenden. Am besten mit zusätzlicher Fehlermeldung.
Bei einem erneuten Scan der gleichen Daten darf einfach kein neues Event entstehen, ansonsten ist was falsch gelaufen.

     cEvent *newEvent = NULL;
     cEvent *rEvent = NULL;
     cEvent *pEvent = NULL;
-      if (Tid == 0x4E || (Tid & 0xF0) == 0x50)
+      if (Tid == 0x4E || (Tid & 0xF0) == 0x50) {
        pEvent = const_cast<cEvent *>(pSchedule->GetEventById(SiEitEvent.getEventId()));
+         if (!pEvent && Tid == 0x4E)
+            pEvent = const_cast<cEvent *>(pSchedule->GetEventByTime(StartTime)));
+      }
     else
        pEvent = const_cast<cEvent *>(pSchedule->GetEventByTime(StartTime));
     if (!pEvent || handledExternally) {

Die Änderung sollte eigentlich nur genau diesen Fall greifen und sonst keine Auswirkung haben.

Auch sollte man es wohl besser nicht den Zufall (bzw. Sender) überlassen, welches Event gelöscht wird:

 // Make sure there are no two events with the same start time:
 for (cEvent *p = events.First(); p; p = events.Next(p)) {
     cEvent *n = events.Next(p);
-      if (n && n->StartTime() == p->StartTime())
-         DelEvent(n);
+      if (n && n->StartTime() == p->StartTime()) {
+         if (n->Version() != Version)
+            DelEvent(n);
+         else
+            DelEvent(p);
+         }
     }
 // Make sure there are no RunningStatusUndefined before the currently running event:
 for (cEvent *p = events.First(); p; p = events.Next(p)) {

Hier bin ich nicht sicher, ob man das so machen darf. Das soll eher zur Illustration dienen.

Weitere Tests muss jemand anderes machen, da bin ich aber leider erst mal raus.
Mein Test-VDR muss sich momentan noch das Sat-Kabel teilen, da sind leider keine vernünftigen Experimente möglich, wenn es ums EPG geht.
Oder ihr habt Geduld, bis ich endlich den Unicable-Multischalter angeschlossen habe. Das kann aber noch ein Bisschen dauern, der liegt schon seit letztem Sommer hier rum (auch eine längere Geschichte ).

Eigentlich sollte man doch immer gefahrlos zuerst nach der EventID suchen können?
Dann ließe sich der Bereich in der eit.c übersichtlicher gestalten:

     cEvent *pEvent = NULL;
     pEvent = const_cast<cEvent *>(pSchedule->GetEventById(SiEitEvent.getEventId()));
      if (!pEvent && !((Tid & 0xF0) == 0x50))
            pEvent = const_cast<cEvent *>(pSchedule->GetEventByTime(StartTime)));
     if (!pEvent || handledExternally) {

Hi,

Es kommt vor (empirisch belegt), dass ein Event mit TableID 0x4E eine andere (neue) eventID bekommt. Wir sollten uns zunächst einigen, wie in einem solchen Fall das korrekte Vorgehen ist:

1. Altes Event löschen, neues Event (mit neuer Event ID anlegen)
2. Altes Event updaten, so dass es danach die neue Event ID hat
3. Neues Event ignorieren
4. ...

Quote from kls

Das würde ja durch deine Änderung wieder rückgängig gemacht.

Ich denke nein, zumindest war das nicht beabsichtigt.
Bei den ganzen Ausnahmen und Änderungen derer, ist es aber schwer den Überblick zu behalten, wenn man nur alle paar Jahre mal rein schaut.

Das alte GetEvent machte das auch anders:

#if DEPRECATED_SCHEDULE_GET_EVENT
const cEvent *cSchedule::GetEvent(tEventID EventID, time_t StartTime) const
{
 // Returns the event info with the given StartTime or, if no actual StartTime
 // is given, the one with the given EventID.
 if (StartTime > 0) // 'StartTime < 0' is apparently used with NVOD channels
    return eventsHashStartTime.Get(StartTime);
 else
    return eventsHashID.Get(EventID);
}
#endif

Es hat also entweder nach der ID oder nach der Zeit gesucht.

Mein Vorschlag wäre erst nach der ID suchen (die sollte ja eindeutig sein).
Wenn dann kein Event gefunden wurde, nach der Zeit suchen.
Erst wenn dann immer noch kein Event gefunden wurde, ein Neues erzeugen.
(Bei gleichzeitiger Änderung von ID und Startzeit würde es also nach wie vor ein Neues Event geben.)

Die Idee dahinter war, möglichst wenig neue Events anlegen zu müssen.
Das verringert die Anzahl an Events die gelöscht werden müssen und Chance, dass dabei was schief geht.

Ob man auf die Weise versehentlich auch falsche Events erwischen kann, bin ich nicht ganz sicher.
Aber da da sowohl ID als auch Startzeit eindeutig sein sollten, wüsste ich nicht wie.

// - Some broadcast tables 0x5X and 0x6X, but use different event ids for the same event in both 
//   sets of tables, and sometimes even use different titles, short texts or descriptions.

Quote from kls

Es bräuchte also eine gute Begründung, warum deine Änderung übernommen werden sollte.

Für mich steht die eine Zeile darüber:

// - Once a schedule has seen events from 0x5X, tables 0x6X are ignored for that schedule.

Wenn das mit dem seen korrekt funktioniert, sollte das Table-Chaos doch eigentlich gar nicht mehr auftreten können .

Quote from MarkusE

Es kommt vor (empirisch belegt), dass ein Event mit TableID 0x4E eine andere (neue) eventID bekommt. Wir sollten uns zunächst einigen, wie in einem solchen Fall das korrekte Vorgehen ist:
1. Altes Event löschen, neues Event (mit neuer Event ID anlegen)
2. Altes Event updaten, so dass es danach die neue Event ID hat
3. Neues Event ignorieren
4. ...

Als allererstes sollte man sich mal überlegen was man an Ende haben will.
Das ist IMHO (EPG-search User) ein aktuelles EPG.
Damit wäre 3. raus.
1. und 2. sollten, wenn es mit rechten Dingen zugeht, zum gleichen Ergebnis führen. (Lediglich die Pointer zu den Objekten sollten unterschiedlich sein, wenn ich nicht völlig daneben liege.)

Wobei 1. in der Praxis so nicht auftreten kann.
Es wird immer erst das neue Event erzeugt, dann eines gelöscht. (Im aktuellen Fall war's leider das Aktuelle und das verursachte letztendlich die Problem.)

Wobei ich da noch immer nicht ganz sicher bin, warum das passiert ist.
Eigentlich sollte die erste Schleife in DropOutdated() ja Events mit alter Version entfernen.

// Special consideration: table 0x4E can only be overwritten with the same id!
Vielleicht ist es dieser Sonderfall gepaart mit ungünstigem Timing?

2. (also Update) wird schwierig, wenn sich ID und Startzeit ändern.
Da man dann aktuell das bisherige Event nicht mehr findet.