Search EPG - *combination* with "|" (pipe)" and "^" circumflex does not work

[chris_ac]

Hello

it seems the "or - pipe - |" and the "at the beginnig - circumflex - ^ " does not work in combination when Regex is not activated in EPG Search (the default behavior).

Non-working Example:

La belle saison - Eine Sommerliebe|Wet Sand|^Elefant|Das Blau des Kaftans

 

Working Example

La belle saison - Eine Sommerliebe|Wet Sand|Elefant*Film|Das Blau des Kaftans

This issue can be seen when Regex is NOT activated.

 

It should work when I follow the online help definition:
 

Quote

SPECIAL SEARCH CHARACTERS

 

(regular expressions switched off)

 

" is a word boundary
("cat" finds cat, but not tomcat or catfish)

 

? is an arbitrary character
("c?t" finds cat, cut,...)

 

* is an arbitrary number of arbitrary characters
("S*day" finds Saturday and Sunday)

 

^ is the text field start
(^Roses in Winter excludes the title Red Roses in Winter)

 

$ is the text field end
(Roses in Winter$ excludes the title Roses in Winter Fog)

 

| is a logical OR
(The Walking Dead|Games of Thrones finds both titles)">

 

Any help? - or is it just a case of "enhanced user experience" - (a bug) ?

Workaround: activate Regex search ... I know ...

[Griga]

vor 2 Stunden schrieb chris_ac:

it seems the "or - pipe - |" and the "at the beginnig - circumflex - ^ " does not work in combination when Regex is not activated in EPG Search (the default behavior).

 

The special meaning of ^ and $ in non-regex mode is only supported at the beginning and end of a search item. Any ^ or $ in between is "escaped" to the corresponding character, independently of | usage.

 

It was never intended to work differently, so I wouldn't call it a bug. It could be changed in future versions. However, the consequences have to be checked carefully, because there are always compatibility issues lurking around the corner

 

[chris_ac]

THX for the hint - the escaping was not fully clear to me.
I'll use 'explicit' Regex in the future ..

I checked the Wiki (Documentation)
https://de.DVBViewer.tv/wiki/Webinterface_-_EPG_Suche#Suche_nach

https://en.DVBViewer.tv/wiki/Webinterface_-_Search_EPG
 

It's stated sth. of beginning/end of the FIELD - nothing about inside the search string ... so - I could have known it better 😉 

In both descriptions there is no hint to the pipe ("|", or) ...

 

[Griga]

It has to be mentioned that the internal Media Server EPG search always uses regular expressions (PCRE, to b exact). In "Use regular expressions off" mode, search items are simplified by escaping characters with a special Regex meaning, e.g. round brackets to \( and \), so that they are interpreted as the corresponding characters and can be used in search items without having to know what they do in a Regex. However, there are exceptions, e.g. the pipe character |, which remains a logical or. The anchors ^ and $ are not escaped at the beginning/end of a search item. Other characters are translated to Regex, like double quotes " to \b (word boundary).

 

Regarding this, the following points had to be checked:

• Does the Regex engine accept the anchors ^ and $ in the middle of a search item? This is not guaranteed (see here). However, a test showed that it works, at least if ^ is preceded or $ followed by a pipe character |. Hence the conditions under which anchor characters are not escaped can be broadened accordingly.
• Could the change affect already existing search presets so that they don't work anymore as expected? This comes down to the question if there is EPG text containing ^ or $ characters, so that someone may want to search for it. It can easily be determined by searching for *^* and *$* on the Search EPG page. *^* yielded no results here, but *$* quite a lot on British (Astra 28.2° East) and even German channels, e.g. the title "Poker $10k Pot-Limit Omaha..." on SPORT1. Hence the change may cause compatibility issues, because a search item like Poker $|... would not yield the expected result anymore.

Obviously it makes sense to support anchors preceded or followed by a logical or. But is it worth potential compatibility issues? I would rather say yes, because it is not very likely that someone is using a search item like the example above. But that's perhaps a matter of taste...