[epgsearch] Kleinigkeiten, die aufgefallen sind

Klar, mach ich. Wenn ich auf meinen Terminplan schaue, weiß nur nicht, ob ich es gleich heute oder morgen schaffe.

Der Tests von value == 0 wurde ja an beiden Stellen dazu "missbraucht", zu erkennen, ob überhaupt ein numerischer Wert vorlag und andernfalls den Default-Wert 0 von atoi() als "ignore missing" zu behandeln.

In MatchesExtEPGInfo() führt deine zweite Zeile dazu, dass man in epgsearchcats.conf den Wert 0 nicht als numerischen Vergleichswert heranziehen kann:

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

… weil ein Vergleichswert von 0 zu NULL führt und die Prüfung damit übersprungen wird. Gelangt man zur Prüfung, passiert in MatchesSearchMode() das gleiche für die EPG-Daten:

int testvalue = atoi(szTest);
int value = atoi(searchText);
if (value == 0) return true;

… und führt dazu, dass Abfragen, die den Wert 0 nicht als Erfolg werten möchten, dennoch positiv beschieden werden.

Beide Fälle behandelt der neue Code in MatchesSearchMode() korrekt und liefert false, wenn einer der beiden Werte fehlt oder die Werte die Vergleichsbedingung nicht erfüllen:

char* end = NULL;
long testvalue = strtol(szTest, &end, 10);
if (!end || end == szTest) // no or invalid number
    return false;
end = NULL;
long value = strtol(searchText, &end, 10);
if (!end || end == searchText) // no or invalid number
    return false;
... // condition checks not shown

Der Pull-Request behebt diese Fehlinterpretationen. Deshalb lieber nochmals die Nachfrage: Wollen wir das wirklich zurücknehmen?

PS: Soll ich deine "Direktausstiege" in MatchesSearchMode() beibehalten oder auch zurücknehmen?

PPS: Ich finde, dass lange Codeabschnitte bzw.. tr-Aufrufe nicht in Header-Dateien gehören. Ich habe deshalb die fragliche Funktion von uservars.h nach uservars.c verschoben.

Danke fürs Einordnen. Den Pull-Request habe ich dem entsprechend aktualisiert.

Den zugehörigen Patch für Live hatte ich ja schon weiter oben geposted:

• 0002b Parental rating and matching modes.zip

Damit sollte alles beisammen sein.

MarkusE: Ich habe den Patch nochmals überarbeitet:

• 0002c Parental rating and matching modes.zip

… damit für die Vermeidung von Wiederholungen die Auswahl der zu prüfenden EPG-Kategorien etwas kompakter dargestellt wird:

Siehe Man-Pages:

Quote

55 – Übereinstimmung von Inhaltskategorien

Enumeration mit den folgenden Werten:

0 = alle gewählten Kennungen

1 = eine der gewählten Kennungen

2 = eine gewählte Kennung je Gruppe

Die Optionen 0 und 1 prüfen über alle Kategoriengruppen hinweg, verwenden aber dennoch die Einstellung aus Feld 56 zur Überprüfung der besonderen Merkmale. Daher können Kombinationen wie 'UND' für die Kategoriengruppen und 'ODER' innerhalb der besonderen Merkmale auftreten und umgekehrt.

Option 2 hingegen verwendet einen zweistufigen Ansatz: Zunächst werden die Kategoriengruppen mit ausgewählten Inhaltskennungen geprüft (Gruppen ohne ausgewählte Inhaltskennungen entfallen). Eine Kategoriengruppe stimmt überein, wenn eine Sendung mindestens eine der für die Gruppe gewählten Inhaltskennungen enthält ('eine gewählte', ODER), mit Ausnahme der Gruppe der besonderen Merkmale, die stets die Einstellung aus Feld 56 verwendet. Abschließend müssen alle geprüften Kategoriengruppen übereinstimmen ('je Gruppe', UND).

Display More

Gerne. Magst du das gleich direkt ändern oder soll ich das machen?

Quote from MarkusE

Etwas off-topic: Irgendwie ist mir epgsearch zu kompliziert .Was ist Feld 56? Na ja, die Leser der Man-Page werden das schon wissen ...

Es war schon immer so, dass die Felder in einem EPGsearch-Datensatz ab 1 gezählt werden. Wenn du das mit dem Parser in Live korrelierst, ist Feld 56 (also das dem 55. Doppelpunkt folgende) nach cSplit parts(m_data, ':') das Feld parts[55]. Weil Array-Indizes in fast allen (Skript-)Sprachen bei 0 starten, hatte ich vor einiger Zeit vorgeschlagen, die Zählung bei 0 zu beginnen; das fand aber leider keine Zustimmung. Abgesehen davon, wäre mir ein Interface mit Datentyp-Spezifikation (Boolean, Integer mit Wertebereichen, Strings mit Längenangaben, Enums) und Feldnamen auch lieber…

Quote from MarkusE

Wenn also ein Anwender noch das "alte" epgsearch, also ohne den hier diskutierten pull request hat. Aber schon das neue live, mit diesem Patch. Wird das dann funktionieren?

Das wird funktionieren, da EPGsearch "überzählige" Felder, die es nicht kennt, verwirft. Den Wert für Feld 50 (Übereinstimmung von erweiterten EPG-Kategorien) prüft es nur auf null bzw. nicht null. Je nach CSS-Einstellungen wirft Live eine Warnung aus, dass man EPGsearch aktualisieren soll.

Stimmt schon. Dazu ist die Versionierung erstens nicht kleinteilig genug. Zudem kann man meines Wissens die Versionsnummer derzeit programmatisch nicht abfragen.

Aber letztlich ist das nur ein kurzfristig transienter Zustand. Den hatten wir übrigens auch, weil Live über längere Zeit nicht alle Features von EPGsearch unterstützt hatte…

Das ist mir auch schon aufgefallen und im Pull-Request (der übrigens schon auf den Master gemergt ist) in cSearchExt::ToText() bereits beseitigt:

...
tmp_catvalues ? tmp_catvalues : "",
...
tmp_blacklists ? tmp_blacklists : "",
...

Quote from MarkusE

Geht schon. In live mit…

Genau das ist mir gestern Abend auch noch eingefallen. Ich hatte nur die SVDRP-Kommandos zu Rate gezogen, wo es so etwas wie "INFO" nicht gibt (zumindest wird nirgendwo in epgsearchsvdrp .c die Versionsnummer referenziert); das könnte man noch ergänzen, damit bspw. auch VDRadmin die Versionsnummer abfragen kann. An das Service-Interface hatte ich nicht gleich gedacht…

TomJoad: Die Versionsnummern für die "kleinen" Plugins stehen immer noch auf "0.0.1". Ich finde, sie sollten der der Versionsnummer des Haupt-Plugins entsprechen.

Quote from MarkusE

Besser wäre es, die Version von epgsearch abzufragen und, falls die Version zu klein ist, solche Felder nicht anzuzeigen.

Wenn schon ein adaptives Verhalten benötigt wird, war und wäre mein Ansatz weiterhin, die Zahl der von EPGsearch gelieferten und im Live-Parser detektierten Felder heranzuziehen. Denn deren Konstellation ist unabhängig von der Versionsnummer (bis auf wenige Ausnahmen) aussagekräftig genug.

Ein kleinteiliges adaptives Verhalten macht den Code aber auf jeden Fall komplex und unübersichtlich. Deshalb habe ich auf Basis der detektierten Felder in Live stattdessen Warnungen über fehlende bzw. unbekannte Felder eingefügt, wenn man eine erweiterte Suche oder einen Suchtimer zum bearbeiten aufruft. Das sollte genügen, um zum Upgrade auf eine kompatible Version von EPGsearch bzw. Live zu animieren.