Posts by TomJoad

msprintf ist ein wrapper von vasprintf() aus epgsearchtools.c (kann nicht sagen, warum das eingeführt wurde, war vor meiner Betreuungszeit). Ich habe halt keine Umgebung für 32bit und bei mir crashed nichts.

S:oren Patch scheint ziemlich vollständig zu sein, aber m.E. fehlt noch in searchtimer_thread.c::SummaryExtended()

start und stop bei msprintf()

S:oren was hältst du davon, wie vdr mit %jd und cast auf (intmax_t) zu arbeiten?

machtnix epgsearch kennt genausolang wie der vdr remote Timer. Wenn das eingerichtet ist, gibt es bei "Timer editieren" die Abfrage "Aufnehmen auf ...". Es ist auch der Konfliktcheck remote einrichtbar. Nur Suchtimer sind auf lokale timer beschränkt, weil die Überwachung mit timersdone und epgsearchdone.data auf Wiederholungen und korrekte Aufnahmen nicht mehr leicht realisierbar ist.

Ich habe wegen MainThreadHook() und warten auf SVDRP-Ready das Handling überarbeitet. Bitte kurz testen, bevor ich die Änderungen ins git schiebe

Der Parameter --svdrpsendcmd ist nie entfernt worden und würde auch noch funktionieren.

Wie gesagt, ich könnte einen svdrpsend "PING" absetzen und nur bei Problemen eine Meldung ausgeben, aber das darf nicht den Thread blockieren. Wenn jemand epgsearch nur als bessere Programmansicht nutzt, wird kein svdrp benutzt.

Das svdrp-Handling in epgsearch ist sowieso nicht optimal. Es müssten mehr Fehler abgefangen werden und es müsste ein Abbruchtimer gesetzt werden.

Bei der Gelegenheit hätte ich auch gerne gewusst, ob noch jemand statt des internen svdrp-Calls die Möglichkeit eines externen Skripts nutzt (da kann man dann die Fehlerrückgabe komplett vergessen).

Ich weiss halt nicht, wie lange vdr MainThreadHook() leben lässt. Sonst würde ich es erstmal wieder rückgängig machen und auf einen besseren Vorschlag hoffen.

Das ist das Problem, dass epgsearch sich darauf verlassen muss, dass svdrp funktioniert. Das war bisher durch den ersten Aufruf von MainThreadHook() realisiert.

Jetzt muss man etwas nehmen, was normalerweise bei dem Mainloop des VDR einen ersten Hinweis gibt, dass das Hochfahren abgeschlossen ist. Ohne HasProgramme() bekommen fast alle VDRs kein aktuelles EPG, es sei denn, es wird extern herbeigeführt und aktualisiert. Normalerweise beginnt jetzt epgsearch nach wenigen Sekunden, seine Threads zu starten.

Ohne HasProgramme() wird 90 Sekunden gewartet, dann läuft alles evtl. normal. Ich hatte überlegt, an der Stelle die Warnmeldung nur nach einem svdrp-PING zu bringen, habe aber befürchtet, der könne bei bestimmten Randbedingungen hängenbleiben und dann sieht man überhaupt keine Warnung. Der sd_notify() "VDR Ready" kommt auch schon vor der svdrp-Initialisierung.

Es wäre natürlich schön, einen Hinweis wie MarkusE geschrieben hat, zu bekommen, das muss ja nicht MainThreadHook() sein - oder gibt es etwas anders sinnvolles im Mainloop des VDR?

oder in der Makefile am Ende von export CXXFLAGS = .... flags) -std=c++17

hinzufügen. Braucht die Version 9 wohl.

was sagt bei dir g++ --version? Sollte mindestens 7 sein. Ist wahrscheinlich auch in focal nachinstallierbar

Neue Version v2.4.5 getagged.

Wichtigste Änderungen seit 2.4.4
- Anpassungen an vdr 2.7.7 (CalcStartStopTime, MainThreadHook)
- Codemodernisierung und Dokupflege von Stefan Hofmann
- diverse Fixes und Verbesserungen
- Erweiterungen Contents Filter, Parental Rating von Stefan Hofmann
- Neuer allgemeiner Parameter für Suchtimer: Frist zur Begrenzung der Timererstellung
- Neue Spalte in der Suchtimerliste: Zeitpunkt der letzten Aufnahme
- Neue Variable "aux" zur Ausgabe der AUX-Eintrages EPG

Der gerade bearbeitete Suchtimer wird immer am Anfang ausgegeben, dann kommen die zugehörigen Meldungen

Ich hatte am 3. 12. geschrieben, dass nicht mehr passende Timer gelöscht werden, wenn epgsearch das aus den Eintragungen im Timer erkennen kann. Wenn nicht unbekannte Randbedingungen auftreten, bleibe ich dabei.

Ich wollte die Behandlung der 0 lassen, wie sie ist - und später dann richtig lösen. Im Augenblick wird beim Neuanlegen eines Suchtimers für einen Kagerorienwert, der ein %02i oder so enthält, für diese Kategorie ein Wert 0 eingetragen, der im Editierungsmenü nicht sichtbar ist. "5|Staffel,%02i|Staffel||14" führt zu einem Eintrag "|5#0|". Ich kann die Kategorie im OSD nicht auf "ohne Wert" setzen, dh. die Variable Staffel muss wirklich den Wert 0 haben. Das war bisher nicht so, weil auf 0 nicht geprüft wurde, deshalb ist deine Lösung nicht kompatibel.

Meine Direktausstiege würde ich auch nochmal überdenken. Bei "ignore missing" weiter zu prüfen ist so ein Zwischending zwischen dem alten Verhalten und deinem "ein Wert muss stimmen".

Ich möchte den Pull request loswerden, weil andere Probleme aufgelaufen sind und ich da nicht rebasieren möchte. uservars muss ich mir ansehen, da wäre svdrpclient.h ein nützlicherer Kandidat.

Stefan, kannst du dann den pull request um die "requested changes" ergänzen und erst mal meinen letzten Vorschlag ignorieren. Um maximale Kompatibilität zu erhalten, müsstest du aber in MatchesSearchMode() und in MatchesExtEPGInfo die Sonderbehandlung für die 0 wieder einfügen

           if (value == 0) return true;

if (value && SearchExtCat->searchmode >= 10 && atol(value) == 0) // numerical value != 0 ?
            value = NULL;

dann würde ich den Pullrequest übernehmen.

Erst danach sollte man über Optimierungen und eine vernünftige Behandlung der 0 als numerischen Vergleichswert nachdenken

Ich habe in meinen Test nicht das Verhalten von MegaV0lt nachstellen können. Wenn Variablen neu ins EPG eingetragen wurden oder sich bei Variable ab einem Wert etwas geändert hat, wurden meine Timer entsprechend angepasst (und nicht mehr passende Timer gelöscht, natürlich vorausgesetzt, dass sich das in dem Aufnahmeverzeichnis abbildet).

Wenn ich das richtig verstehe, möchtest Du "ignore missing" beibehalten, aber epgsearch soll sich irgendwie merken, dass doch Variablen nicht versorgt waren und das timer-spezifisch. Dann müssten die Variablen in irgendeiner Form im Aux-Feld des timers gespeichert werden. Relevant sind aber nur die Variablen, die zur Bildung des Aufnahmeverzeichnisses hergenommen werden - oder? Ich dachte immer, wenn sich der Verzeichnisname ändert, wird das mit dem in timers.conf vorhandenem abgeglichen und der timer entsprechend modifiziert.

Quote from MegaV0lt

Wenn sich die Beschreibung ändert, müsste EPGSearch auch wieder schauen, ob die Variablen drin sind

Wie soll epgsearch feststellen, dass sich die Beschreibung geändert hat? Stand heute, wird die Beschreibung weder von vdr in die timers.conf noch von epgsearch in die timersdone.conf geschrieben.

Ich hatte das so ausführlich gemacht, um die Inkompatibilitäten zumindest beim Behandeln von "ignore missing" zu zeigen. Es gibt für mich ebenso keinen erkennbaren Grund, die Logik beim neuen Mode 2 anders zu führen.

Ich hatte auch gehofft, dass sich Benutzer des externen EPGs melden - auch für ein gemeinsames Brainstorming. Ich selber nutze das normalerweise nur am Entwicklungsrechner beim Testen.