Ich hatte für die Fehlersuche in cEvent::Title() und cEvent::SetTitle() jeweils eine Abfrage eingebaut, ob zu dem Zeitpunkt der jeweilige Thread einen Read- bzw. Write-Lock auf Schedules hat. Das war aber eine eher "krude" Angelegenheit, da ich dazu einen Pointer auf Schedules brauchte und Members von pthread_rwlock_t abfragen musste, die plattformabhängig sind (auf Raspberry Pi anders als auf Linux gcc). Das offiziell einzubauen würde ich gerne vermeiden.
Ich bin nicht ganz sicher ob das funktioniert, aber könnte man nicht einfach die Threadid des erstellenden Threads im Statekey-Objekt mit speichern.
Dann muss man nur prüfen, ob die Threadid des eigenen Thread in der Liste auftaucht und der Lock (read/write) stimmt, dann sollte alles o.k. sein.
An die Threadid des aktuellen Prozesses sollte man mit gettid() (oder besser pthread_self() ???) doch überall recht einfach ran kommen.
Eine einfache Möglichkeit die Locks zu prüfen wäre echt hilfreich.
Da jetzt Jahre nach Einführung (die Locks dürften doch auch bald 10Jähriges Jubiläum haben 
) sogar im VDR noch fehlende gefunden werden, befürchte ich, dass sich bei den Plugins Abgründe auftun werden 
.
dabei ist manchmal der Fall aufgetreten, dass ein cEvent entsteht, bei dem title==NULL ist, der aber anscheinend nicht durch FixEpgBugs() geht.
Das wäre echt blöd, wenn das sporadisch auch mit "sinnvollen" Events passiert, einige von der Korrekturen sind ja nicht nur Kosmetik. Amok laufende Suchtimer wären dann das geringste Problem, was mir so einfällt...
Irgendwie sehe aber auch keine ich Möglichkeit, wie sich ein Event an der Korrektur vorbei mogeln kann.
Das SetTitle() in der epg.c kann man wohl ausschließen, da es nur beim einlesen der epg.data verwendet wird. Dann würden die Fehler nur nach einem Neustart des VDR Auftreten, das hätte auffallen müssen.
Evtl. eine blöde Idee, aber ist wirklich sicher gestellt das FixEpgBugs() nicht aufgerufen wurde und dass das fragliche Event nie einen Titel hatte?
Nicht dass es eine Fehlfunktion in FixEpgBugs() ist, die durch irgendwelche komischen Sonderzeichen ausgelöst wird oder wenn der Titel nach FixEpgBugs() am Ende dann leer ist.
Wirklich gesehen habe ich da bislang nichts, aber könnte eine der Helper-Funktionen einen NULL-String zurück geben?
Schon versucht eine Abfrage auf title==NULL ganz am Ende von FixEpgBugs() einbauen?
Das wäre interessant, ob die anschlägt.
Ehrlich gesagt, verstehe ich trotz der Beschreibung hier noch immer nicht wirklich, was das für Events sind.
Mit ein Bisschen mehr Informationen könnte man vermutlich die Art des Fehlers deutlich eingrenzen.
Gibt es Gemeisamkeiten (außer dass der Titel fehlt 
)?
Trifft es immer den gleichen Kanal?
Sind das echte, sinnvolle Events, also Startzeit in den nächsten Wochen, plausible Länge, ...?
Existieren die Events wirklich im Schedule oder nur im Menü? Lassen sich zB. auch mit SVDRP ausgeben?
Wenn nicht, fehlt wohl immer noch irgendwo ein Lock.
Was passiert, wenn man das EPG mit CLRE komplett löscht und dann neu scannt? Tifft es dann die gleichen Everts erneut?
Tauchen die Fehler auch in der epg.data auf der Festplatte auf?
Wenn ich das richtig interpretiere, sollte da dann einfach der Titel fehlen.
Ich habe bei mir eben gesucht und nichts gefunden.
grep -zoP "\nE.+\n[^T]" ./epg.data (Liefert der Einfachheit halber nur die erste Zeile des Events!)
Im Produktiv-system ist aber eine recht alte VDR-Version am laufen (längere Geschichte).
Was, falls andere die Fehler finden, bedeuten müsste, dass der grundlegende Fehler erst später rein gekommen ist.
Falls jemand so ein Event in der epg.data findet, dann bitte hier mal rein stellen, gern auch mehrere. Ich würde es mir gerne mal ansehen.
Da das Problem anscheinend nicht viele haben und ORF erwähnt wurde, könnte es evtl. an der speziellen Emfangssituation liegen? An der Kombination DVB-S plus deutschem und österreichischem DVB-T, meine ich.
.
.
.
.
.
. Für mich sieht es momentan eher nach "Datenmüll" aus.