[Patch] trim EPG: Entfernen von Whitespace am Anfang und Ende von Texten

  • Hi,

    der attachte Patch entfernt Whitespace und Steuerzeichen (genauer: alle Bytes mit 0 < Byte <= 32) am Anfang und Ende von Titel, Kurztext und Beschreibung, bevor diese Texte im VDR Event gespeichert werden.

    • Spart Speicher, unnötige Zeichen werden nicht gespeichert
    • Bei der Weiterverarbeitung dieser Texte können solche Zeichen stören

    ~ Markus

  • Kommt das öfter vor, das da Zeichen drin sind, die da nichts zu suchen haben?

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

    "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.7)

    VDR 2.7.7; 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]

  • Kommt das öfter vor, das da Zeichen drin sind, die da nichts zu suchen haben?

    Ja. Je nach dem, wie viele Updates bei einem EPG Scan kommen, werden so etwa 100-10000 entfernt.

    Anbei noch ein Patch, der anstelle des oben geposteten Patches verwendet werden kann. Damit wird im syslog ausgegeben, wie viele Zeichen entfernt wurden.

  • Ich habe mal in meiner eg.data gesucht, konnte aber keinen einzgen Fall finden, wo am Anfang oder Ende von Title oder Description ein Leerzeichen ist. Kommt das nur bei bestimmten Sendern vor?

    Ich denke mal, dass VDR solche Zeichen vor dem Schreiben in die epg.data löscht.

    Hier mal ein Auszug aus dem syslog, mit dem debug patch:

    Also, das soll jetzt nur zeigen, dass auch deutsche öffentlich-rechtliche Sender betroffen sind. Das ist keinesfalls eine vollständige Liste.

    Dass Leerzeichen / Sonderzeichen am Ende der "Description()" stehen, ist sicher (da haben wie eindeutige Belege ...). Ob solche Zeichen auch am Anfang der Texte stehen, kann ich nicht sagen.

  • Ist der Patch "UTF8-tauglich" oder beachtet der nur ASCII-Zeichen?

    Der Patch ist UTF-8 tauglich, es werden alle UTF-8 Zeichen ignoriert.

    Bevor wir noch UTF-8 Zeichen, die einen Whitespace darstellen, mit berücksichtigen, würde ich gerne ein Beispiel sehen, in dem ein Sender ein solches UTF-8 Zeichen am Anfang oder Ende eines Textes sendet.

  • Und sollte nicht bei externem EPG das schon im EPG-Plugin gefiltert werden ?

    Doch, das sollte das EPG-Plugin machen. Solche Zeichen sind aber (auch) im Sender-EPG.

  • Wenn überhaupt im VDR, dann sollte sowas in cEvent::FixEpgBugs() gemacht werden.

    Klar, kann man machen. Der Vorteil meiner Lösung ist, dass

    • Für diese Zeichen gar nicht erst Speicher alloziert wird
    • Sichergestellt ist, dass am Ende von keinem cEvent String ein Whitespace steht.
  • Bevor wir noch UTF-8 Zeichen, die einen Whitespace darstellen, mit berücksichtigen, würde ich gerne ein Beispiel sehen

    Ich würde gerne mal ein Beispiel sehen, welche Zeichen gelöscht werden. Gleich in Deiner ersten Zeile des Beispiellog steht beim BR num_chars_truncated = 216 Was wurde denn da gelöscht? Ich habe meine epg.data mal durchsucht aber auf Anhieb keinerelei Probleme gefunden. Kannst Du mal ein paar Sendungen (Sender + Zeit) aus Deiner epg.data nennen?

  • Ich würde gerne mal ein Beispiel sehen, welche Zeichen gelöscht werden. Gleich in Deiner ersten Zeile des Beispiellog steht beim BR num_chars_truncated = 216 Was wurde denn da gelöscht? Ich habe meine epg.data mal durchsucht aber auf Anhieb keinerelei Probleme gefunden. Kannst Du mal ein paar Sendungen (Sender + Zeit) aus Deiner epg.data nennen?

    Wie schon geschrieben, ich gehe davon aus, dass VDR diese Zeichen löscht, bevor er sie in die epg.data schreibt.

    Du kannst ja den Patch aus #3 nehmen und so erweitern, dass alle für Dich relevanten Informationen ausgegeben werden.

  • ich gehe davon aus, dass VDR diese Zeichen löscht, bevor er sie in die epg.data schreibt.

    Ich kann so eine Stelle aber nicht finden.

    Das müsste wenn, dann ja wohl hier passierren:

  • Ich kann so eine Stelle aber nicht finden.

    Ich würde sagen, es passiert in char *compactspace(char *s)

  • Das ist aber dann doch die zentrale Stelle, durch die alle von EIT kommenden Strings durch müssen. Somit dürfte es in VDR selber keine Title, ShortText oder Description geben, die überflüssige Leerzeichen enthalten.

    Kann es sein, dass bei dir ein Plugin ein cEpgHandler::FixEpgBugs() implementiert, welches "true" zurückliefert? In dem Fall würde nämlich cEvent::FixEpgBugs() nicht aufgerufen werden und damit auch keine Leerzeichen entfernt werden.

  • Kann es sein, dass bei dir ein Plugin ein cEpgHandler::FixEpgBugs() implementiert, welches "true" zurückliefert?

    Nein, das hat bei mir kein Plugin implementiert.

  • Ich fand es gut, bereits vor dem Allozieren von Speicher für diese Strings zu prüfen, ob man da Zeichen am Ende entfernen kann und weniger Speicher braucht. Und dann auch gleich weniger Speicher zu allozieren.

    VDR geht da einen anderen Weg: Erst wird der komplette Speicher alloziert, und danach bereinigt.

    Die tatsächliche Speicherersparnis bei meinem Vorgehen ist aber gemessen am verfügbaren Speicher heutiger Rechner wohl eher gering. Von daher kann ich auch gut damit leben, wenn dieser Patch nicht in den VDR kommt.

  • Prinzipiell keine schlechte Idee, aber FixEpgBugs() macht aber noch mehr Ersetzungen, die die Stringlänge auch beeinflussen können. Wenn müsste das dann auch vor ziehen.
    Dann hätten aber "EPG-Handler-Plugins" keine unverfälschten Daten mehr. Das ist vermutlich nicht so Ideal.

    Bei den Strings ist mir aber auch schon aufgefallen, dass die eigentlich nie schrumpfen können.
    Evtl. wäre eine Art trim()-Funktion was, die man bei Bedarf (zB. am Ende vom FixEpgBugs()) aufruft? So kann die Speicherverwaltung dann aufräumen, wenn nötig.

    Ob sich der Aufwand lohnt bin ich aber am zweifeln. 10000 Zeichen klingt zwar viel, aber das sind lediglich 10kB. Bei den ganzen Pointern, die so ein Objekt hat, fällt das wohl nicht wirklich ins Gewicht.
    Dann sperrt die Speicherverwaltung am Ende vom Block teilweise sowieso ein paar Byte als Puffer. Unter Umständen bringt das Ganze also nahezu nichts.

    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!