[epgsearch] Kleinigkeiten, die aufgefallen sind

  • Im Code sind mir ein paar Kleinigkeiten aufgefallen, die vielleicht berichtigt werden sollten:

    Keine Ahnung, wer von den sieben Kontributoren in GitHub nun der Haupt-Maintainer ist: TomJoad, schau dir das doch bitte mal an und entscheide, ob der Patch in die offizielle Codebasis übernommen werden soll. Hier eine Übersicht der wichtigsten Änderungen:

    • Der README-Link sollte nicht eingecheckt sein, weil er jedes Mal neu erzeugt und bei make clean zudem gelöscht wird.
    • In cSearchExt ist search ein Array, sodass dessen "Pointer" nicht nicht NULL sein kann. Aus diesem Grund wirft der Compiler unschöne Warnungen aus.
    • Weil ich keine Warnungen beim Kompilieren haben möchte, habe ich die Compiler-Warnung von Zeile 105 in blacklist.c per #pragma GCC diagnostic selektiv abgeschaltet.
    • Dito in md5.c, nur dass hier sizeof(chEach) – ähnlich wie in den Zeilen davor – durch die entsprechende Konstante ersetzt wurde.
    • Statt strncpy sollte man besser das im VDR implementierte strn0cpy verwenden, welches ein terminierendes NUL-Zeichen bei einem Pufferüberlauf erzwingt.
    • Beim Anlegen eines Suchtimers aus einer Vorlage wird skipRunningEvents nicht übernommen.
    • Beim Schreiben der Suchtimer-Konfiguration werden Sonderzeichen in contentsFilter zwar in tmp_contentsFilter ersetzt, dieser String aber irrtümlich nicht gespeichert.
    • Weil der Vergleich des Untertitels vom Vergleich des Titels unabhängig ist, sollte er die gleiche Einrückungstiefe wie der Titel haben.
    • Bei Berechnung der prozentualen Zeitspanne in services.c ist eine Division durch null nicht ausgeschlossen.

    Noch ein paar Gedanken zum Schluss:

    • Unschön ist, dass bei der Expansion von Strings zum Speichern der Konfiguration einzelne Zeichen durch 8- bzw. 9-stellige "Makros" ersetzt werden, sodass die originalen Strings beim Speichern eventuell abgeschnitten werden könnten. C++11 als Minimalstandard vorausgesetzt, ließe sich das vielleicht auch dadurch lösen, dass für die reservierten Zeichen anstelle der Makros beim Speichern UTF8-Sonderzeichen genutzt würden, die eh keiner verwendet. Und die Konversion der Konfigurationsdateien beim ersten Einlesen nach der Umstellung sollte kein großes Problem sein.
    • Da reguläre Ausrücke seit C++11 von der Standard-Bibliothek unterstützt werden, stellt sich die Frage, ob man die Suche mit regulären Ausdrücken nicht vielleicht auf diese umstellen sollte. Damit hätte man auch keine Kompatibilitätsprobleme zwischen den drei alternativen Regex-Bibliotheken mehr.

    Sagt Bescheid, wenn ich euch bei solchen Arbeiten helfen kann.

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.5 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

    Edited once, last by SHofmann (May 15, 2025 at 3:32 PM).

  • Darf man Wünsche äußern?

    Display Spoiler

    Was ich schon lange vermisse ist bei den Suchtimern eine Spalte wo man das Datum sieht, wann der letzte gefunden wurde. Habe weit über 200 Suchtimer und viele davon sind obsolete, weil die entsprechende Serie eingestellt wurde. Mit der Datumsangabe würde man in der Liste schön sehen, welche Suchtimer schon seit Jahren nichts mehr gefunden haben. ;)

    Und vielen Dank an SHofmann. epgsearch ist eines der wichtigsten Plugins für den VDR

    Kanallogos: Picon.cz2VDR | Picons2VDR | MP-Logos
    Backupskripte:
    MV_Backup (RSync) | MV_BorgBackup (Borg)

    Skin: Skin FlatPlus  VDR-Add_MSGT

    "Es gibt keinen Grund, warum irgendjemand einen Computer in seinem Haus wollen würde."
    [Ken Olson], Präsident der Digital Equipment Corp., 1977

    VDR01 - yaVDR 0.7 (VDR 2.7.3)

    VDR 2.7.3; Gehäuse: Antec Fusion V2 Black & iMon LCD; Atric IR-Einschalter Rev. 4; Board: Intel DH77EB, Core i5-3550, GTX 1050 Ti, 8 GB RAM; DVB: 1x Digital Devices CineS2 Quad V6.5

    >Systeminfo.txt< [VDR-User #1540]

  • Da reguläre Ausrücke seit C++11 von der Standard-Bibliothek unterstützt werden, stellt sich die Frage, ob man die Suche mit regulären Ausdrücken nicht vielleicht auf diese umstellen sollte. Damit hätte man auch keine Kompatibilitätsprobleme zwischen den drei alternativen Regex-Bibliotheken mehr.

    Das hat auf Seite der Nutzer ggf. den Nachteil, dass bereits existierende Suchtimer nicht mehr funktionieren und angepasst werden müssen (falls das überhaupt möglich ist, PCRE bietet ja deutlich mehr Möglichkeiten als https://en.cppreference.com/w/cpp/regex ).

    Meine VDRs

    VDR 1: Intel DH67BL, Celeron 540, 4 GB Ram, POV Geforce GT 1030, Ubuntu 24.04 (yavdr-ansible), VDR 2.7.4, CIR-Empfänger
    VDR 2: Acer Revo 3610, Pinnacle PCTV SAT 452e, Medion X10, yaVDR 0.6
    Client 1: Raspberry Pi 2, Ubuntu 22.04 (yavdr-ansible), VDR 2.6.1

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • PCRE bietet ja deutlich mehr Möglichkeiten…

    Ich habe mir die Spezifikation für die regulären Ausdrücke von std::regex vor einiger Zeit und auch gerade eben nochmals angesehen. Und obwohl ich reguläre Ausdrücke selbst oft mit "allen Schikanen" nutze, vermisse ich eigentlich nichts, was man für Suchtimer so braucht.

    Das hat auf Seite der Nutzer ggf. den Nachteil, dass bereits existierende Suchtimer nicht mehr funktionieren…

    Was ich bislang nicht gemacht habe, ist, die Features der derzeit genutzten Bibliotheken tre, prce und pcre2 miteinander bzw. mit std::regex zu vergleichen. Ich würde aber erwarten, dass es in der Praxis nur wenige Problemfälle geben sollte. Dennoch ist das Risiko unerwartet fehlschlagender Suchtimer nicht einfach von der Hand zu weisen.

    Vielleicht wäre es ja eine Alternative, std::regex im Makefile als vierte (Standard-)Option vorzusehen, um damit die anderen Bibliotheken über die Zeit ausphasen zu können. Wir müssen sowieso damit rechnen, dass irgendeine Distribution eines der Pakete früher oder später nicht mehr unterstützt. Bei Ubuntu ist mir Vergleichbares mit anderen Paketen schon das eine oder andere Mal passiert.

    Unschön ist, dass bei der Expansion von Strings zum Speichern der Konfiguration einzelne Zeichen durch 8- bzw. 9-stellige "Makros" ersetzt werden…

    Vielleicht muss man gar nicht so weit gehen, wie ich es hier skizziert habe. Wir haben einen MAXPARSEBUFFER von derzeit 10 KBytes. Jeder String hat eine Größe von MaxFileName (entspricht NAME_MAX) = 255 Bytes. Damit erfordert im Worst Case ein String von 254 Sonderzeichen (vereinfacht gerechnet) zur Codierung mit jeweils 10 Escape-Zeichen knapp 2,5 KBytes. Da wir derzeit fünf Strings pro Suchtimer haben (von denen derzeit nur Suchmuster, Kategorien und Serien-Verzeichnis derart kodiert werden), wäre der Puffer etwas zu knapp bemessen. Die Puffergröße (und damit die maximale Zeilenlänge der Konfigurationsdatei) sicherheitshalber auf 20 KBytes (vielleicht auch auf MaxFileName * 10 /*escaping*/ * 5 /*strings*/ + KILOBYTES(5) /*remainder*/) zu ändern, wäre aber wohl einfacher und weniger invasiv.

    Die Codierung solcher Sonderzeichen selbst ist natürlich nach wie vor unschön und auch nicht für alle Strings einheitlich, siehe auch epgsearchext.c, Zeile 301 ff. für Kategorien:

    Code
    while (strstr(catvalue, ":"))
        catvalue = strreplace(catvalue, ":", "!^colon^!"); // ugly: replace with something, that should not happen to be part of a category value
    while (strstr(catvalue, "|"))
        catvalue = strreplace(catvalue, "|", "!^pipe^!"); // ugly: replace with something, that should not happen to be part of a regular expression

    … bzw. Zeile 248 ff. für Suchmuster, Inhaltsfilter und Verzeichnisse:

    Code
    char* replaceSpecialChars(const char* in)
    {
        char* tmp_in = strdup(in);
        while (strstr(tmp_in, "|"))
            tmp_in = strreplace(tmp_in, "|", "!^pipe^!"); // ugly: replace a pipe with something
        strreplace(tmp_in, ':', '|');
        return tmp_in;
    }

    Was nach wie vor nicht passt, ist, dass in epgsearchext.c, Zeile 424, beim Parsen die Stringlänge auf MaxFileName begrenzt wird:

    Code
    if (valuelen > MaxFileName) valuelen = MaxFileName;
    strn0cpy(value, pos, valuelen);

    … obwohl die Sonderzeichen an dieser Stelle noch nicht "dekodiert" sind (was erst nach dem vollständigen Parsen aller Felder in Zeile 647 und somit auf Basis der potentiell gekappten Strings erfolgt). Und damit werden Konfigurationsdaten – wie eingangs angemerkt – möglicherweise gekappt. Man müsste die Dekodierung also bereits hier vornehmen. Vielleicht sollte man besser grundsätzlich jeden String kodieren bzw. dekodieren; eine Dekodierung von Nicht-String-Daten wäre wohl unkritisch, weil solche Daten (Zahlen, Transponderkennungen usw.) die Escape-Sequencen wohl kaum enthalten dürften.

    Alle Strings zentral zu kodieren und dekodieren müsste ich allerdings noch testen. Der Kompatibilität halber wäre dieser Ansatz aber die am wenigsten invasive Methode.

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.5 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • Weil viele Strings kontextbezogen unterschiedlich kodiert werden, habe ich einen anderen Ansatz gewählt:

    Der Puffer zum Lesen der Konfigurationsdatei ist jetzt 20 KBytes groß und der Puffer für das Zwischenspeichern eines Suchtimer-Felds auf 10-Byte-Sequenzen für Sonderzeichen ausgelegt. Jedes potentiell kodierte Feld wird sofort dekodiert und in den ursprünglichen Puffer geschrieben.

    Damit sollte das Abschneiden von Strings bei maximaler Kompatibilität eigentlich sichergestellt sein. Bitte seht euch das einmal an.

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.5 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • Nochmal eine kleine Überarbeitung:

    … und der Nachweis, dass die Korrektur das Gewünschte leistet, denn der Suchtimer:

    Code
    0:!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!S:0:::0:0:0:0:1:1:1:0:::1:0:0:1:!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!D:50:99:2:10:0:0:0::0:0:0:0:0:0:0:0:0:0:0:0::1:0:0:0:0:0:0:0:0:0:90::0

    … wird ohne den Patch verkürzt angezeigt:

    … mit dem Patch aber korrekt:

    Der Inhaltsfilter sollte ebenfalls funktionieren. Aufgrund der Art der Speicherung (zwei Hex-Digits pro ID) sollte das aber eh kein Problem sein.

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.5 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • Danke erstmals, ich habe keine Einwände gegen die Verbesserungen und werde sie ins git einpflegen

    vdr-2.7.5

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver
    ubuntu focal, yavdr-ansible, linux-6, AsRock J4105, CIne CT-V7 DVB-C

  • Post by SHofmann (May 15, 2025 at 9:06 PM).

    This post was deleted by the author themselves: Hat sich erledigt, die Fixes sind schon im Git. (May 15, 2025 at 9:08 PM).
  • Leider vergessen:

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.5 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • Der Inhaltsfilter sollte ebenfalls funktionieren. Aufgrund der Art der Speicherung (zwei Hex-Digits pro ID) sollte das aber eh kein Problem sein.

    Ich muß hier mal einhaken, weil ich in meinem Programm ein kleines Problem mit den Inhaltsfiltern habe. Die Filter bestehen ja wie oben geschrieben nur aus hexadezimalen Zahlen, aneinandergehängt in einem String. Wieso muß hier dann eine Ersetzung stattfinden? Das "|" sollte im String gar nicht vorkommen. Oder übersehe ich hier etwas?

    Mein Problem besteht darin, daß bei Übermittlung eines Suchtimers über SVDRP die Contentfilter nicht mehr gelöscht werden können. Sende ich z.B. :x:10:0 (10 für Film) funktioniert das einwandfrei. Allerdings bekomme ich den ContentFilter nicht mehr weg, egal ob ich :x:"":0 oder :x::0 sende. Die 10 bleibt bestehen. Leider konnte ich im Code die Stelle nicht herausfinden, wo die Prüfung stattfindet bzw. was da genau passiert.

    SHofmann Vielleicht kannst du mir da etwas helfen?

  • Wieso muß hier dann eine Ersetzung stattfinden? Das "|" sollte im String gar nicht vorkommen.

    Diese Frage habe ich mir auch gestellt. Der Einfachheit halber habe ich den bestehenden Code aber nur adaptiert, bevor es an einer mir unbekannten Stelle knirscht. Vielleicht waren da früher mal Pipes als Trennzeichen vorgesehen, oder es ist eine Vorbereitung auf Kommendes. Falls man solche Trennzeichen wirklich nicht benötigt, sollte TomJoad die Substitution besser wieder aus dem Code entfernen.

    Leider konnte ich im Code die Stelle nicht herausfinden, wo die Prüfung stattfindet bzw. was da genau passiert.

    SVDRP habe ich für EPGsearch noch nie benutzt. Doch wenn ich den Code von epgsearchsvdrp.c, Zeile 257 ff.:

    Code
    cSearchExt *searchTemp = SearchExts.GetSearchFromID(search->ID);
    if (searchTemp) {
        searchTemp->Parse(Option);
        LogFile.Log(1, "modified search '%s' (%d) via SVDRP", searchTemp->search, searchTemp->ID);
        SearchExts.Save();

    … richtig verstehe, muss man für das Ändern eines Suchtimers als Option einen String senden, wie er auch in epgsearch.conf gespeichert wird. Einen solchen erhältst du, wenn du dir per LSTS <ID> den gewünschten Timer zum Editieren abrufst. Danach musst du in diesem String den Contents-Filter entsprechend setzen bzw. abändern und das Resultat per EDIS zurückschreiben.

    Anhand meines Beispiels von oben:

    Code
    [BASH 1176] svdrpsend plug epgsearch lsts 0
    220 Virtual-Ubuntu24 SVDRP VideoDiskRecorder 2.7.5; Sat May 17 16:02:13 2025; UTF-8
    900 0:!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!S:0:::0:0:0:0:1:1:1:0:::1:0:0:1:!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!D:50:99:2:10:0:0:0::0:0:0:0:0:0:0:0:0:0:0:0::1:0:0:0:0:0:0:0:0:0:90::0

    Die Contents-Filter (oder jedes andere Feld) zu isolieren (oben zwischen den letzten zwei Doppelpunkten), ist in dieser Form nicht wirklich banal: An Doppelpunkten splitten und daraus ein Array generieren, das entsprechende Element ändern und das Array wieder rücktransformieren. In Bash könnte das etwa so aussehen:

    Code
    OLDIFS="$IFS"; IFS=":" read -r -a fields <<< "$searchtimer"; IFS="$OLDIFS"
    # update the contents filter in ${fields[52]}
    searchtimer="`printf "%s:" "${fields[@]}"`"
    # use "${searchtimer%%:}" for eliminating the trailing colon

    Schön wäre, etwas besser strukturierte Datenformate wie XML oder JSON zu nutzen, bei denen sich Felder bspw. per RegEx leichter isolieren und manipulieren ließen. Weil eine solche Änderung aber alle Skripten und Plugins tangiert, fürchte ich, dass wir einen solchen Schritt wohl eher nicht gehen werden.

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.5 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

    Edited 4 times, last by SHofmann (May 17, 2025 at 5:27 PM).

  • Genauso mache ich es, wie du schreibst, auf der Konsole, mit LSTS <id> den Suchtimer holen. Dann im Ergebnis das Feld mit den Contentfiltern auf :: setzen. Ist zum Glück das vorletzte. Im Beispiel oben wäre das die Stelle 90::0. Dann mit EDIS zurückschicken. Leider werden in dem Fall die Contentfilter nicht entfernt. Im Qellcode wird quasi nur der String geparst (Parse()) und dann gespeichert. Sieht man auch schön am obigen Codeausschnitt.

    Ich weiß nicht, ob es sich lohnt hier mehr Zeit reinzustecken. Werden die Contentfilter überhaupt von jemanden genutzt? In "Live" kommen sie gar nicht vor.

  • Ich weiß nicht, ob es ein Bug oder ein Feature ist: Der Parser überspringt leere Felder (x::y) und behält für diese den bisherigen Wert bei. Beim Einlesen von Suchtimern aus der Konfigurationsdatei bzw. beim Neuanlegen von Suchtimern stehen in den Feldern die Defaultwerte, sodass dies nicht weiter auffällt. Beim Editieren werden aber die alten Werte des Suchtimers mit den neuen überschrieben, weshalb das Überspringen hier den beobachteten Effekt zeigt.

    Ich bin schon an einem Patch dran, muss jetzt aber leider an dieser Stelle erst einmal die Arbeiten unterbrechen…

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.5 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • Hier nun der avisierte Patch:

    Wie bisher gilt, dass :: den bisherigen Wert des entsprechenden Felds beibehält, selbst im Falle eines Strings. Um einen String zu löschen, muss das Feld als : : (also mit mindestens einem Leerzeichen) übergeben werden. Ein Beispiel (der Übersichtlichkeit halber mit per :...: ausgelassenen Feldern):

    EPGsearch erlaubt beim Bearbeiten eines Suchtimers ja auch, unveränderte Felder am Ende wegzulassen, sodass deren Werte einfach beibehalten werden. Wenn man als letztes Feld einen String übergibt und diesen Löschen möchte, muss zwingend noch ein Doppelpunkt als Schlusszeichen folgen. Überzählige (Folgen von) Doppelpunkte(n) am Ende schaden ja glücklicherweise nicht…

    Dieses Schema der String-Behandlung gilt ebenfalls für das Serien-Verzeichnis, die Ausschlusslisten und die erweiterten EPG-Kategorien (ExtCats). Die letzten beiden konnte man schon immer einfach abschalten, deren Einstellungen jetzt aber auch endlich löschen.

    Nutzt man statt SVDRP das API von egpsearchservices.h, gilt – weil der Parser für alle Schnittstellen identisch ist – das gleiche Verhalten.

    TomJoad, kannst du dir den Patch bitte ansehen und gegebenenfalls ins Git übernehmen?

    Die switch-case-Anweisung liefert ja die Referenz für die Feld-Indizes. Weil aber praktisch bei allen Sprachen, die im Kontext von EPGsearch zum Einsatz kommen (siehe den Bash-Code weiter oben oder bspw. auch Python) die Arrays-Indizes bei 0 beginnen, habe ich mir erlaubt, die Feld-Indizes in der switch-case-Anweisung statt von 1 bis 53 nun von 0 bis 52 laufen zu lassen. Damit muss man beim Feld-Index nicht mehr daran denken, dass noch ein Offset von 1 abzuziehen ist. Hoffe, das ist OK für dich.

    Die entsprechenden Anpassungen für Live habe ich ebenfalls in Arbeit. Dort ist sowieso noch mehr zu tun, weil die Felder ab 50 (neue Zählung) im Suchtimer-Dialog noch nicht unterstützt werden. Man kann sie weder bei der Erstellung eines Suchtimers setzen noch ihre alten, per OSD konfigurierten Werte bearbeiten. Wie gehabt, bleiben die Werte dieser Felder einfach erhalten, was eventuell zu unerwartetem Verhalten von Suchtimern führen kann.

    PS: Beim Experimentieren mit den ExtCats ist mir aufgefallen, dass die Strings aus der Konfigurationsdatei literal in den Setup-Dialog übernommen und auch so in der Konfigurationsdatei gespeichert werden, beispielsweise:

    1#Information, Serie, Spielfilm|2#Abenteuer, Action|3#|4#|5#|6#|7#|8#|9#|10#

    Wenn man viele Kategorien mit jeweils zahlreichen Strings zur Auswahl hat, kann das Feld mit 255 Zeichen schnell zu klein werden. Eine Lösung könnte sein, zur Speicherung der ExtCats nicht einen Puffer fester Größe, sondern wie bei den Contents-Filtern einen std::string zu verwenden; das bin ich im Patch aber nicht angegangen. Vielleicht sollte man in Erwägung ziehen, alle Strings in Suchtimern von char[] / char* auf std::string bzw. char** bei den ExtCats auf std::vector<std::string> umzustellen?

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.5 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • Ich habe noch ein wenig geforscht und festgestellt, dass in EGPsearch das Verhalten von Strings für :: derzeit leider etwas inkonsistent ist:

    1. Der Suchstring wird vorab gelöscht und muss explizit gesetzt werden. Erfolgt dies nicht, hat man einen Suchtimer ohne Suchkriterium, bekommt aber leider auch keine Fehlermeldung.
    2. Das Serien-Verzeichnis wird ebenfalls vorab gelöscht und muss erneut gesetzt werden.
    3. Der Name der Kanalgruppe wird nicht gelöscht, wenn man die Kanalauswahl abschaltet oder auf eine numerische Kanalauswahl wechselt. Nach dem Zurückschalten auf Kanalgruppen erscheint der alten Gruppenname erneut,
    4. Die ExtCats werden nicht gelöscht, sobald man sie abschaltet; nur die Ausgabe wird unterdrückt. Nach dem Wiederanschalten erscheint die vorherige Konfiguration erneut.
    5. Die Ausschlusslisten geben "(null)" als Auswahl zurück, wenn man sie abschaltet. Auch hier erscheint nach dem Wiederanschalten die vorherige Konfiguration erneut.
    6. Die Contents-Filter lassen sich bislang überhaupt nicht löschen. Weil aber immer Paare von Hex-Ziffern erwartet werden und Werte mit nur einer Hex-Ziffer zum Abbruch der Filterung führen, kann man ersatzweise eine einzelne Hex-Ziffer (am besten wohl "0") übergeben.

    Die Effekte von 1 und 2 sind vermutlich die seinerzeit gewählte Lösung, um die Strings löschen zu können. Die Effekte von 2, 3 und 4 treten nach dem Neustart des VDR nicht mehr auf, weil beim Einlesen der Konfigurationsdatei die Strings dauerhaft eliminiert werden. Bei 5 und 6 tritt beim Parsen jeweils ein Fehler auf, der bei 5 zur Auswahl der Blacklist 0 führt und für 6 die Filterung abbrechen lässt.

    Es wäre vorteilhaft, hier eine einheitliche Lösung zu haben. Für alle Felder gilt, dass :: das Feld überspringt und den Wert beibehält. Das sollte auch weiterhin und am besten generell gelten.

    Mit einem überarbeitetem Patch könnte man alle Strings bei :: beibehalten, bis man sie per : : (außer für 1) explizit löscht. Gegebenenfalls könnte man einen String-Parameter intern auch automatisch löschen, wenn ein Modus eingestellt wird, bei dem man den String nicht mehr benötigt. Weil dies aber das Verhalten für SVDRP bzw. das API leicht ändert, könnte das zu Inkompatibilitäten mit bestehenden VDR-Installationen führen.

    Eine andere Lösung wäre, mit den oben geschilderten Eigenheiten und den skizzierten Workarounds zu leben und nur die Null-Pointer beim Formatieren der Suchtimer-Konfiguration abzufangen. Und weil ich einen Puffer von knapp 3 KBytes auf dem Stack für problematisch halte, würde ich im Parser diesen noch auf den Heap verlagern.

    Bevor ich da weitere Arbeit reinstecke: Wie ist eure Sicht der Dinge?

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.5 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • Einige von den den Punkten sind mir auch aufgefallen (3 und 4), daß die Werte wieder da waren. War für mich jedoch unproblematisch, da es dazu passende Aus-/Einschalter gibt. Wie ich schon oben schrieb sehe ich das mit den Inhaltsfiltern nicht so dramatisch. Immerhin kann man sie über das OSD löschen. Ansonsten arbeitet das Plugin über SVDRP einwandfrei, soweit ich feststellen konnte.

  • Immerhin kann man sie über das OSD löschen.

    Aber leider nicht über externe Tools, die das SVDRP-Interface bzw. das API nutzen, wie insbesondere Live. Insofern sehe ich schon Handlungsbedarf.

    Mein derzeitiger Ansatz wäre, möglichst nahe am alten Stand zu bleiben und nur für solche Strings, die keinen Ein/Ausschalter haben, das explizite Löschen vorzusehen. Die von solchen Schaltern abhängigen Strings würde ich löschen, wenn die zugehörige Einstellung deaktiviert wird.

    TomJoad, im Code werden Heap-Operationen durchgeführt (in Parse() wird in Zeile 413 etwa strdup() aufgerufen), ohne den zurückgegebenen Pointer auf NULL zu prüfen. Solche Sunny-Day-Ansätze sind nicht unproblematisch, weil selbst der lesende Zugriff zu einer Null-Pointer-Exception führen kann. Auch wenn Out-of-Memory-Szenarien relativ selten sind: Willst du den Plugin-Code mal auf andere solcher Szenarien überprüfen und die gefundenen Stellen absichern?

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.5 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • @SHofmann: vielen Dank, dass Du dir die Mühe machst, den Code auf derart vermeintliche "Kleinigkeiten" abzusuchen. :respekt
    Der Qualität und Zuverlässigkeit des Plugins dürfte das echt gut tun!

    Beim Blick in den Patch "0001b" sind mir zufällig, wegen der Inkonsistenz (2x da, 1x nicht), die while-Schleifen um strreplace aufgefallen.
    strreplace() hat, auch in der "String-Variante", eine vergleichbare while-Schleife mit strstr() schon drin.
    Ich denke die extra while-Schleife ist redundant und kann weg, das macht die Sache auch gleich übersichtlicher.

    Ich habe noch ein wenig geforscht und festgestellt, dass in EGPsearch das Verhalten von Strings für :: derzeit leider etwas inkonsistent ist

    Ganz zu Anfang war sogar das Verhalten von Aufnahmen, die über Mitternacht gingen inkonsistent. ;)
    Vermutlich ist das hier einfach noch niemandem aufgefallen.

    Wenn ich das noch recht erinnere, sind 1,2 jeweils nur ein String, wenn man den löscht ist der Inhalt weg.
    Bei 3,4,5 gibt es noch eine weitere "Schalter-Variable", die den Modus wählt. Es wäre auch extrem unpraktisch, wenn zB. die Kanalgruppe jedes mal sofort weg wäre, wenn man im OSD versehentlich da was verstellt.
    Da hat man wohl das Aufräumen der Strings beim Verlassen des Menüs vergessen. Wobei das eigentlich auch so bleiben kann wie es ist, so viel RAM verbraucht das ja nicht.

    Contents-Filter verwende ich nicht und SVDRP im Zusammenhang mit EPGsearch auch nur seltenst, daher halte ich mich da raus.
    Aber irgendwie ist es schon merkwürdig die Contents-Filter mit SVDRP nur ein aber nicht abschalten zu können. :schiel

    m Code werden Heap-Operationen durchgeführt (in Parse() wird in Zeile 413 etwa strdup() aufgerufen), ohne den zurückgegebenen Pointer auf NULL zu prüfen.

    Im VDR selber gibt es aber auch einige solche Stellen, wenn ich nicht irre.

    Gruss
    SHF

    Mein (neuer) VDR:

    Software:
    Debian Wheezy mit Kernel 3.14
    VDR 2.0.7 & div. Plugins aus YaVDR-Paketen
    noad 0.8.6

    Hardware:
    MSI C847MS-E33, onboard 2x1,1GHz Sandybridge Celeron 847, 4GiB RAM
    32GB SSD (System), 4TB 3,5" WD-Red HDD (Video)
    TT FF DVB-S 1.5 FullTS-Mod PWM-Vreg-Mod, DVB-Sky 852 Dual DVB-S2
    Das ganze im alten HP Vectra VLi8-Gehäuse versorgt von:
    PicoPSU-160-XT und Meanwell EPP-150 im ATX-NT-Gehäuse

  • vielen Dank, dass Du dir die Mühe machst, den Code auf derart vermeintliche "Kleinigkeiten" abzusuchen.

    Das rührt eher daher, dass ich gerne eine Erweiterung um ein zusätzliches Feld in Arbeit habe und deshalb in den Code eingetaucht bin. So sehr ich EPGsearch auch schätze, sehe ich doch etliche problematische Stellen im Code.

    strreplace() hat, auch in der "String-Variante", eine vergleichbare while-Schleife mit strstr() schon drin.
    Ich denke die extra while-Schleife ist redundant und kann weg, das macht die Sache auch gleich übersichtlicher.

    Ich habe das für den nächsten Patch bereinigt. Unschön ist, dass alle Varianten von strreplace() intern schon alle Vorkommen des Strings ersetzen, strreplacei() aber nicht. Das ist darin begründet, dass keine der Varianten (auch nicht die originale im VDR) gegen Endlosschleifen gehärtet sind. Auch das werde ich fixen, und kls habe ich schon informiert.

    Es wäre auch extrem unpraktisch, wenn zB. die Kanalgruppe jedes mal sofort weg wäre, wenn man im OSD versehentlich da was verstellt.

    Spätestens beim Speichern und Neuladen ist ein nicht genutzter String sowieso verloren gegangen. Da ist mir das konsistente Verhalten am SVDRP-Interface bzw. API schon lieber. Außerdem betrifft das ja sowieso nur dem Parser. Solange du ausschließlich über das OSD arbeitest, ist der Parser sowieso außen vor.

    Da hat man wohl das Aufräumen der Strings beim Verlassen des Menüs vergessen. Wobei das eigentlich auch so bleiben kann wie es ist, so viel RAM verbraucht das ja nicht.

    Wir sollten keine Annahmen treffen, wie problematisch Memory-Leaks sind. Auf kleinen Raspis oder Servern, die 24/7 laufen, kann das irgendwann doch zum Crash führen.

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.5 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • So sehr ich EPGsearch auch schätze, sehe ich doch etliche problematische Stellen im Code.

    Ich bin da schon mal rein gefallen, daher schätze ich dein Vorgehen die gefundenen Probleme gleich gescheit zu beheben, auch wenn das etwas mehr Arbeit macht. :thumbup:

    Unschön ist, dass alle Varianten von strreplace() intern schon alle Vorkommen des Strings ersetzen, strreplacei() aber nicht.

    strreplace() wird eigentlich immer so eingesetzt, dass das Verhalten Sinn macht. Das ist also gewollt, denke ich.

    Die Sache mit den möglichen Endlosschleifen wäre ein anderes Thema.

    Außerdem betrifft das ja sowieso nur dem Parser. Solange du ausschließlich über das OSD arbeitest, ist der Parser sowieso außen vor.

    Das hatte ich dann falsch verstanden.
    Ich dachte das Verhalten wird durch den nicht zurück gesetzten String im Suchtimer-Objekt verursacht.
    Das wäre nicht wirklich kritisch, solange der Destructor am Ende sauber aufräumt.

    Gruss
    SHF

    Mein (neuer) VDR:

    Software:
    Debian Wheezy mit Kernel 3.14
    VDR 2.0.7 & div. Plugins aus YaVDR-Paketen
    noad 0.8.6

    Hardware:
    MSI C847MS-E33, onboard 2x1,1GHz Sandybridge Celeron 847, 4GiB RAM
    32GB SSD (System), 4TB 3,5" WD-Red HDD (Video)
    TT FF DVB-S 1.5 FullTS-Mod PWM-Vreg-Mod, DVB-Sky 852 Dual DVB-S2
    Das ganze im alten HP Vectra VLi8-Gehäuse versorgt von:
    PicoPSU-160-XT und Meanwell EPP-150 im ATX-NT-Gehäuse

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!