[Announce] epg2timer 0.0.3

  • Moin!


    Eins vorweg: Es ist noch lange nicht fertig und momentan nur mit einem Texteditor zu konfigurieren. Aber ich dachte mir, wenn da jemand schon mit rumspielen will, dann soll er es tun.


    Ich hab mal wieder ein kleines Plugin geschrieben, welches ich für meinen täglichen Bedarf brauche. Da leider epgsearch ein wenig Schwierigkeiten mit vdr 2.3.1 hat und mir der Code zu unübersichtlich und die Funktionalität zu mächtig ist, wurde es Zeit für ein neues Plugin, welches aus EPG-Daten Timer anlegen kann.
    Wie immer gilt, dass ich keine Garantie für korrekte Funktion gebe, und auch nicht die Verantwortung für verpasste Aufnahmen übernehme. Insbesondere bei Verschiebungen von Sendungen kann immer alles mögliche passieren.


    Hier nun der Source:
    https://github.com/flensrocker…3/vdr-epg2timer-0.0.3.tgz


    Lest das Readme aufmerksam! Aber ich bin mir sicher, dass es noch viele Fragen geben wird. Die dürfen hier dann auch gerne gestellt werden. Ansonsten gibt's ja den Issue-Tracker bei GitHub.
    Ich habe mir Mühe gegeben, das Dateiformat möglichst lesbar zu gestalten, damit man es mit einem Texteditor vernünftig bearbeiten kann.


    Einen Parallelbetrieb mit epgsearch habe ich nicht getestet, aber es versteht sich eigentlich von selbst, dass man diese beiden Plugins nicht auf die gleichen Sendungen loslassen sollte. :)
    Sollte epg2timer ein Event zu seinen Filtern finden, welches schon einen Timer hat, sollte aber kein neuer erstellt werden. Ich hab keine Ahnung, wie epgsearch sich da verhält...


    Was es kann (Stand 0.0.1):

    • In Titel, Kurztext und Beschreibung nach einzelnen Suchbegriffen filtern (Contains-Filter)
    • Nur Sendungen von Kanälen aus einem bestimmten Bereich filtern (Channel-Filter)
    • Nach Tags in der Beschreibung filtern (Tag-Filter) - dieser ist am komplexesten, aber auch am mächtigsten
    • Werte von Tags aus der Beschreibung in den Aufnahmenamen übernehmen
    • Eigene Vor-/Nachlaufzeiten, Priorität und Lebenszeit pro Filter
    • Inaktive Timer erstellen können
    • Die verschiedenen Filter beliebig mit Und- und Oder-Operatoren verknüpfen können


    Neu in 0.0.2:

    • Der Contains-Filter kann nun auch als "containsnot" benutzt werden.
      z.B. contains "Star Trek" and containsnot "Beyond"

      Code
      type=and {
        type=contains,search=star trek,field=title
        type=containsnot,search=beyond,field=title
      }


    • Neuer Filter für die Startzeit, z.B. zwischen 14:00 und 18:00 Uhr:

      Code
      type=starttime,after=1400,before=1800


      oder zwischen 22:00 und 02:00 Uhr (nächster Tag)

      Code
      type=starttime,after=2200,before=0200


    • libicu kann mit "make DISABLE_LIBICU=1" ignoriert werden, allerdings sind dann die Vergleiche empfindlicher, insbesondere beachtet der Tag-Filter dann Groß- und Kleinschreibung.


    Neu in 0.0.3:

    • Tag-Synonyme: Mit einem Tag Werte aus verschiendene Tags benutzen, z.B. bei Mehrsprachigkeit. Einfach in den globalen Optionen mehrere Zeilen in dieser Art eintragen:

      Code
      tagsynonym=Staffel:stagione:saison
      tagsynonym=Episode:episodio:épisode


      In den Filtern dann nur "Staffel" und "Episode" verwenden. Sobald eine der Tag-Alternativen greift, wird dessen Wert genommen.
      Deshalb sollte man die Tags, zu denen es potentiell die meisten Events gibt, nach vorne in die Liste schreiben.


    Was vermutlich in absehbarer Zeit noch kommen wird:

    • Filter, um nur Sendungen mit einer Startzeit in einem definierten Intervall aufzunehmen (erledigt)
    • Kanal-Filter erweitern, um die Suche auf eine Kanalgruppe einschränken zu können
    • SVDRP-Befehl, um eine Filterdatei auf Korrektheit prüfen zu können (ohne gleich Timer anzulegen)
    • Über das OSD sich die aktuellen Events zu den verschiedenen Filtern anzeigen lassen


    Was vermutlich noch lange dauern wird, bis es kommt (wenn überhaupt):

    • Wiederholungsvermeidung
    • Timer wieder löschen, wenn sie nicht mehr passen


    Wozu ich so gar keine Lust habe:

    • Einen Filter über das OSD konfigurieren können.
    • Reguläre Ausdrücke wird's nicht geben - was auch immer ihr damit vorhabt, das geht bestimmt auch anders. :)


    Ich werde diesen Post aktuell halten, falls sich was tun sollte.


    Viel Spaß
    wünscht Lars.

  • Vielen Dank mini73 für das neue epg2timer plugin.


    Es hat mich besonders gefreut zu lesen, dass es auch die Möglichkeit anbietet, inaktive Timer zu erstellen. Somit steht diese Funktion auch bei einem Übergang zum VDR 2.3.1 zur Verfügung; sogar offiziell im Plugin und nicht über einen Patch, wie zur Zeit beim epgsearch plugin auf meinem VDR 2.2.0. :D


    Wenn ich mich nicht irre, bist du auch der Autor des Patches; vielen Dank nochmals.


    MfG

  • Moin Lars.


    Wiederholungsvermeidung wäre schon echt toll ... ich benutze epgsearch fast ausschliesslich für Serienaufnahmen.
    Wird es die Funktion "Serientimer" auch geben, also mit Konfiguration von Pfad und Namensgebung (analog zu epgsearchuservars usw.)?


    Gruss.
    Markus

  • also mit Konfiguration von Pfad und Namensgebung (analog zu epgsearchuservars usw.)?


    Pfadnamen mit Serieninfos gibt es schon. Ich nutze den vdr eigentlich nur für Serien. Den geschnittenen Kram, was die so aus Spielfilmen machen, tu ich mir nicht an...
    https://github.com/flensrocker…er/blob/master/README#L71


    Lars.

  • Ah. Ok. Bin noch nicht dazu gekommen, es anzusehen.
    Falls Du das mit den Wiederholungen umsetzt, wird es eine Möglichkeit geben, eine gefüllte epgsearchdone.comf zu übernehmen? Meine ist inzwischen glaube ich schon über 5 oder 6 Jahre gewachsen.
    Filme nehme ich nur auf Sky auf, ohne Werbung und mit ordentlichem Abspann :].


    Vllt. kommme ich ja um die Weihnachtszeit mal zum Testen - muss eh mal eine Neuinstallation machen und die neue SSD verbauen.

  • Wozu sind die Dateien .gitignore und pax_global_header im Paket?

  • Das war nicht die Frage; die Frage war: Warum sind diese dateien im Paket - dort machen diese keinen Sinn?


    btw. hat sich erledigt, ich werds nicht nutzen, weil wieder einmal eine neue nutzlose lib gebraucht wird.

  • Muss ich mal schauen. Ich hab nur ein "make dist" aufgerufen und mich nicht weiter drum gekümmert. Werde ich beim nächsten Release drauf achten. Danke!


    Meinst du mit der nutzlosen lib die libicu? Hast du eine bessere Idee, um einen Vergleich von Strings etwas fuzzy und stabiler gegenüber den verschiedenen Abarten von Hochkommata und Apostrophen zu machen? Auch auf Umlaute und Accents hatte ich keine Lust, dann noch verschiedene Encodings usw., weshalb mir libicu da praktischerweise unter die Arme greift. Man muss ja nicht immer alles neu erfinden.


    Der vdr bietet viel, aber nicht alles... Und die STL genauso. Ich bin aber für Anregungen offen. :)


    Lars

  • Hallo,


    Ich hätte eine Frage für Personen, die Sender in verschiedenen Sprachen benutzen. Ich nehme an, die müssen einen Timer pro Sprache erstellen, wenn sie die Staffel- und Episodeninformationen aus dem EPG benutzen möchten.


    Hier ein Beispiel basierend auf deinem Beispiel im Readme. Nehmen wir an, ich suche Star Trek im deutschen, französischen und italienischen EPG. Also bräuchte ich folgende drei Suchtimer:



    Gibt es schon eine Möglichkeit diese drei Suchtimer in einem zusammen zu fassen? Ich könnte mir zum Beispiel so etwas vorstellen:


    Code
    Star Trek {
      type=contains,search=star trek,field=title
      action=inactive,marginStart=5,marginStop=10,priority=90,lifetime=99
      filename=%title%~S%Staffel|saison|stagione:2%~E%Staffelfolge|épisode|episode:2%_-_%shorttext%
    }


    Die Pipes waren jetzt nur als mögliches Beispiel gedacht; du weißt sicherlich besser als ich, wie man die verschiedenen Möglichkeiten kombinieren könnte.


    Eigentlich, stellt sich das Problem nicht nur bei Mehrsprachigkeit: ich kann mir zum Beispiel vorstellen, dass einige Sender "Staffelfolge" und andere nur "Folge" im EPG schreiben.


    Schließlich frage ich mich noch, auf welche Weise die Tags in der Beschreibung vorkommen müssen, damit sie erkannt werden. Muss jeder Tag in einer eigenen Zeile stehen, oder erkennt er sie auch mitten in der Beschreibung?


    Vielen Dank im Voraus für jede Antwort.


    MfG


    Ludi

  • Die Serieninformationen im EPG hast du normalerweise nur mit epgd/epg2vdr bzw. dem xmltv2vdr-Plugin (und damit sind die Feld-Namen im EPG fix) - oder kennst du Sender, die das sauber und in einer eigene Zeile abgesetzt in ihr EPG schreiben?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Über die Mehrsprachigkeit mach ich mir mal Gedanken. Momentan musst du getrennte Filter erstellen, die sollten aber unterschiedliche Namen bekommen. Das sollte ich noch abfangen.


    Was die Tags betrifft: die müssen am Zeilenanfang stehen und dann einen Doppelpunkt haben. Alles danach bis zum Zeilenende wird als Wert des Tags betrachtet. Ich hab mich da in erster Linie an epgd orientiert. Aber xmltv2vdr hat es auch so gemacht.


    Lars

  • Über die Mehrsprachigkeit mach ich mir mal Gedanken.


    Danke wiederum für dein freundliches Entgegenkommen. :applaus


    Im Augenblick bearbeite ich die xmltv Datei, die ich mit dem xmltv2vdr importiere vor dem Import und übersetze die Tags alle ins englische, um eine einheitliche Sprache zu haben. Das lasse ich vorerst mal so weiterlaufen.


    Was die Tags betrifft: die müssen am Zeilenanfang stehen und dann einen Doppelpunkt haben. Alles danach bis zum Zeilenende wird als Wert des Tags betrachtet.


    Danke für die klare Erläuterung. :D Ich hatte bislang angenommen, dass die Zahl hinter dem Tag auch als Zahl erkannt wurde. Folglich war das falsch. :S


  • Meinst du mit der nutzlosen lib die libicu? Hast du eine bessere Idee, um einen Vergleich von Strings etwas fuzzy und stabiler gegenüber den verschiedenen Abarten von Hochkommata und Apostrophen zu machen? Auch auf Umlaute und Accents hatte ich keine Lust, dann noch verschiedene Encodings usw., weshalb mir libicu da praktischerweise unter die Arme greift. Man muss ja nicht immer alles neu erfinden.


    Moin Lars, ja die libicu.
    Ich denke konvertieren mit iconv() in eine bekannte Kodierung und Vergleiche mit std algorithm hätten es ebenso getan.

  • Ich überlege mal, ob ich einen Compiletime-Schalter einbaue, mit dem sich die libicu ausklammern lässt. Dann lässt sich im String-Converter vielleicht eine Alternative einbauen.


    Lars.

  • Wozu sind die Dateien .gitignore und pax_global_header im Paket?


    Ich hab noch mal nachgesehen. In der von mir hochgeladenen Datei sind diese nicht enthalten.
    https://github.com/flensrocker…1/vdr-epg2timer-0.0.1.tgz


    Die Pakete hinter den Links von Github werden vermutlich on-the-fly generiert. Auf die habe ich keinen Einfluss. Ich passe den Link im ersten Post mal an.


    Lars.

  • Im git ist nun eine Version, mit der man libicu ausschließen kann. Momentan hab ich da noch nicht viel Arbeit in einen alternativen Algorithmus gesteckt. Der String wird dann einfach gar nicht bearbeitet und exakt so zurückgegeben, wie er im EPG steht. Das bedeutet dann aber auch, dass der Tag-Filter Groß-/Kleinschreibung beachtet (es wird strstr etc. benutzt, weil mit libicu vorher schon alles in Kleinbuchstaben umgewandelt wird). Der Contains-Filter benutzt strcasestr, weil der nicht ganz so viel Performance schluckt wie der Tag-Filter.
    Wer will, darf dann gerne Alternativen vorschlagen, siehe https://github.com/flensrocker…ols/stringconverter.c#L52.


    Das Plugin muss man dann so übersetzen:

    Code
    make DISABLE_LIBICU=1


    Per Default wird die libicu aber aktiv bleiben.


    Lars.

  • Version 0.0.2 ist raus. Es gibt jetzt einen Startzeit-Filter und der Contains-Filter kann auch als ContainsNot-Filter benutzt werden.
    Außerdem kann das Plugin jetzt ohne libicu übersetzt werden, wobei die Vergleiche dann aber nicht so robust gegen Umlaute, Accents usw. sind.


    Lars.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!