Jump to content

Über Sender EPG neu erzeugte Serie findet nichts


x112

Recommended Posts

Ich klicke im Sender EPG auf diese Sendung

image.png.34b4340a7ba1e622f1c61cfa8040fb15.png

und dann auf "Serie aufnehmen". Im erzeugten Autotimer steht <SearchPhrase>&quot;Once Upon a Time - Es war einmal ...&quot;</SearchPhrase>. Der Rest ist alles auf Standard.

Leider wird damit aber nichts gefunden. Wenn ich das hintere Anführungszeichen oder beide wegnehme und sonst nichts ändere, dann werden die Sendungen gefunden.

Der Autotimer sieht so aus:

image.thumb.png.992ed631e4eeadc8c42e54d290655d0c.png

Link to comment
vor 2 Stunden schrieb x112:

Leider wird mit "Once Upon a Time - Es war einmal ..." nichts gefunden. Wenn ich das hintere Anführungszeichen oder beide wegnehme und sonst nichts ändere, dann werden die Sendungen gefunden.

 

Das Problem sind hier die Punkte am Ende des Titels. Ich konnte es anhand des Titels "Fritz mit..." nachvollziehen.

 

Die Anführungszeichen repräsentieren eine Wortgrenze, d.h. den Übergang von einem Buchstaben zu einem Nicht-Buchstaben oder umgekehrt. Sie verhindern, dass ein Suchbegriff als Teil zusammengesetzter Wörter gefunden wird, z.B. "Rote Rosen" in "Rote Rosensträucher".

 

Da der letzte Punkt in "Once Upon a Time - Es war einmal ..." ein Nicht-Buchstabe ist, und das Ende des Titels ebenfalls, befindet sich dort keine Wortgrenze, und deshalb gibt es keinen Treffer. Gäbe es eine Sendung mit dem Titel "Once Upon a Time - Es war einmal ...oder zweimal", würde sie gefunden.

 

Kurz gesagt, bei der Funktion "Serie aufnehmen" wurde nicht berücksichtigt, dass ein Titel mit einem Nicht-Buchstaben enden kann. Das ist natürlich ein unschöner Effekt, den man nicht durchschaut, wenn man kein Experte für reguläre Ausdrücke ist - intern setzt der DMS auch die vereinfachte Form von Suchbegriffen in einen regulären Ausdruck um (hier in \bOnce Upon a Time - Es war einmal \.\.\.\b) und übergibt ihn der zuständigen Suchengine. Kennt man sich damit aus, sieht man schnell, woran es scheitert.

 

Was dagegen tun? Wenn das letzte Zeichen des Titels kein Buchstabe ist, muss die Funktion entweder auf das abschließende Anführungszeichen verzichten, oder alle Nicht-Buchstaben am Ende entfernen, also den Suchbegriff auf "Once Upon a Time - Es war einmal" kürzen. Das gleiche gilt übrigens für den Anfang des Titels. Dort könnten auch Nicht-Buchstaben stehen.

 

Leider ist das nicht so trivial, wie es sich anhört, denn wir haben es hier mit Unicode zu tun, und da gibt es hunderte sprachspezifische Buchstaben wie z.B. Umlaute, Buchstaben mit Akzent usw. Im Prinzip sollte es aber reichen, am Anfang und Ende alle ASCII-Zeichen zu entfernen, die keine ASCII-Buchstaben (a...z, A...Z) sind. Das würde also Punkte, Leerzeichen, Kommas, Doppelpunkte usw. umfassen. Gleichzeitig würde es dafür sorgen, dass auch Variationen des Titels (z.B. "Es war einmal ..." mit keinem Leerzeichen vor den drei Punkten oder nur zwei Punkten) gefunden werden.

 

Ich denke, so oder so ähnlich werde ich das in Angriff nehmen, auch wenn die Methode nicht ganz sauber ist (man denke an sprachspezifische Interpunktion). Bis zum nächsten Beta-Upload oder Release bleibt jedoch erst mal nur die manuelle Korrektur solcher mit "Serie aufnehmen" erzeugten Suchvorgaben.

 

Zu überlegen wäre übrigens auch, an den Anfang des Suchbegriffs das Zeichen ^ zu setzen. Es bedeutet "Beginn des Textfeldes". Damit könnte man z.B. verhindern, dass "Rote Rosen" in "Wer rote Rosen schenkt und dabei an tote Hosen denkt..." gefunden wird. Nur mal so als Beispiel... :)

 

Link to comment

Die Umlaute sollten aber in dem Fall schon als Buchstaben zählen, sonst gibt das ziemlich seltsame Suchen.

 

Wie verhält sich das bei ^und $ eigentlich wenn man in Titel und Untertitel sucht? Die Suche heißt ja dann Titel*Untertitel. Ein Titel$*Untertitel findet aber nichts.

Link to comment
vor 7 Stunden schrieb x112:

Die Umlaute sollten aber in dem Fall schon als Buchstaben zählen, sonst gibt das ziemlich seltsame Suchen.

 

Umlaute zählen ab DMS 3.1 als Buchstaben. Im DMS 3.0.x war das aufgrund einer veralteten Regex-Engine (Regular Expressions) noch nicht der Fall. Es wurde durch eine neue Version der Engine behoben (pcre.dll im Programmverzeichnis).

 

In der 3.0.x konnte noch so etwas passieren:

 

Suchbegriff (Nicht-Regex-Modus) : "St*rm"

 

Gefunden: Stofferls Wellmusik - Von und mit Christoph Well (Biermösl Blosn)

 

Die Buchstaben, die zum Treffer führen, habe ich farblich markiert, sonst blickt man da zunächst überhaupt nicht durch. Das ö zählte als Nicht-Buchstabe ;)

 

vor 7 Stunden schrieb x112:

Wie verhält sich das bei ^und $ eigentlich wenn man in Titel und Untertitel sucht?

 

Das muss ich erst mal untersuchen...

 

Link to comment

Weiter mit dem Thema:

 

Zunächst musste ich in meinem letzten Post falsch angegebene DMS-Versionsnummern korrigieren. Die aktualisierte Regex-Engine, die auch Umlaute als Buchstaben erkennt, gibt es ab Version 3.1 (nicht 2.1).

 

Weiterhin: Zu den Buchstaben (oder präziser gesagt Wortzeichen) zählt die Such-Engine auch die Ziffern 0..9. Ein Suchbegriff wie "Formel E 2021" inklusive Anführungszeichen wird also funktionieren.

 

Für das Löschen von Nicht-Wortzeichen am Anfang und Ende von Serientiteln habe ich eine vollständig korrekte (auch in Spanien funktionierende) Lösung gefunden. Ich lasse einfach die Regex-Engine innerhalb des Serientitels die längste Zeichenkette finden, die mit einem Wortzeichen beginnt und endet (für Spezialisten: \b.*?\b). Und die wird dann genommen.

 

vor 19 Stunden schrieb x112:

Wie verhält sich das bei ^und $ eigentlich wenn man in Titel und Untertitel sucht? Die Suche heißt ja dann Titel*Untertitel. Ein Titel$*Untertitel findet aber nichts.

 

Im Nicht-Regex-Modus kannst du die Zeichen ^ und $ mit der Sonderbedeutung Textfeldbeginn und Textfeldende nur am Anfang und Ende des Suchbegriffs verwenden. Mittendrin werden sie als als normale Textzeichen angesehen, damit auch Suchbegriffe funktionieren, in denen diese Zeichen vorkommen.

 

Für eine Suche, in der $ mitten im Suchbegriff die Bedeutung "Textfeldende" beibehält, musst du "Reguläre Ausdrücke verwenden" einschalten. Dann funktioniert sowas wie

 

ARD-Morgenmagazin$.*^Moderation

 

Hier bedeuten

 

$ Textfeldende

. beliebiges Zeichen

* vorhergehendes Zeichen kommt beliebig oft vor (auch keinmal)

^ Textfeldbeginn

 

Dazu muss man wissen, dass der DMS für die Suche Titel, Untertitel und Beschreibung zu einer Zeichenkette zusammensetzt, aber jeweils getrennt durch die Steuerzeichen CR, Carriage Return und LF, Linefeed. Diese kann man im Regex-Modus durch den Punkt als Stellvertreter für ein beliebiges Zeichen erfassen. Auch das hier funktioniert:

 

ARD-Morgenmagazin$..^Moderation

 

Reguläre Ausdrücke sind ein sehr mächtiges Suchwerkzeug. Es gibt fast nichts, was man damit nicht machen kann. Wer tiefer in die Materie eintauchen will, suche im Web nach Regex Tutorial oder ähnlichem. Da gibt es reichlich Material.

 

Link to comment

Jetzt wird mir einiges klarer.

Zu den regulären Ausdrücken habe ich eine hervorragende Beschreibung in den Foren Untiefen gefunden:

 

https://www.dvbviewer.tv/forum/topic/43396-epg-suche-etwas-auschliessen/?do=findComment&comment=409081

 

von chris_ac Geschrieben 27. Mai 2014 (bearbeitet).

 

Edited by Griga
Link durch direkten Link auf den genannten Post ersetzt
Link to comment

Bei der Verwendung von regulären Ausdrücken für die EPG-Suche sollte man auch wissen, dass der Media Server mit drei Voreinstellungen in der Regex-Engine arbeitet, die das Verhalten beeinflussen:

  • ^ (Textfeldbeginn) und $ (Textfeldende) passen auch nach/vor den Steuerzeichen für "neue Zeile" (beim DMS CR/LF), nicht nur am Anfang und Ende des gesamten Textes.
  • Der Punkt . passt zu jedem Zeichen, einschließlich den Steuerzeichen für "neue Zeile".
  • Die Wiederholungszeichen * (vorheriges Zeichen kommt beliebig oft oder gar nicht vor) und + (vorheriges Zeichen kommt beliebig oft, aber mindestens einmal vor) sind standardmäßig "faul" (lazy), d.h. die Engine versucht, möglichst kurze Treffer zu finden. Setzt man noch ein Fragezeichen hinter das Wiederholungszeichen, wird es "gierig" (greedy), d.h. die Engine versucht, einen möglichst langen Treffer zu finden.

Ein Beispiel, das den Unterschied zwischen lazy und greedy illustriert: Gesucht sind HTML Tags, die in Posts mitunter auch in der folgenden Form auftauchen

 

<Ironie>Text</Ironie>

 

Eine Regex-Suche mit <.+> (zwischen < und > mindestens ein beliebiges Zeichen) ermittelt im DMS <Ironie> und </Ironie> als Treffer (lazy), während <.+?> den gesamten Text einschließlich Tags als Treffer ermittelt (greedy).

 

Ich gebe die Punkte hier an, weil sich andere Programme/Suchmaschinen eventuell genau umgekehrt verhalten.

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...