/web/epgxmltv can't handle certain chars

[FsxShader2012]

Description Epgxmltv api endpoint returns an error when certain unicode chars are encountered. See related issue: #1012

To Reproduce NOTE: Only reproducible if epg data contains certain chars

1. Make a request to epgxmltv api: http://<yourIP>/web/epgxmltv?<args>
2. If bad char is encountered -> Error

Expected behavior XML Response containing epg data no matter what chars the epg creators decide to use.

Screenshots error on line 7683 at column 53: PCDATA invalid Char value 26 XML Data: epgxmltv.zip

Image

• OS: VTI
• Version 14.0.6

Desktop

• Browser New Edge
• Version 91

[jbleyel]

This is not really a bug in OWF. I don't like to fix problems caused by enigma2. The "bad" chars should be removed inside of the enigma2 epgcache.

[FsxShader2012]

Understandable. I've already tried "sanitizing" the dictionary returned by epgxmltv but that didn't do anything. Would this even be the correct approach?

[jbleyel]

Do you have this issue on VTi 15?

	<programme start="20210617115000 +0200" stop="20210617122000 +0200" channel="1:0:19:C36F:2720:F001:FFFF0000:0:0:0:">
		<title lang="de">The Boss Baby: Wieder im Geschäft</title>
		<sub-title lang="de">Halte durch, Baby! Animations-Serie, USA 2018</sub-title>
		<desc lang="de">Folge 12,</desc>		
	</programme>

The problem is at the end of the title.

https://www.compart.com/de/unicode/U+001A

[FsxShader2012]

I will try upgrading to VTI 15 tomorrow. Thanks for the info about the char, this is one of the characters I tried removing from the "ret" dictionary but that didn't work. Here's what I did:

for value in ret.values():
      value = re.sub('/\u001a/', ' ', str(value))

Would this even work? I'll be honest with you I've never worked with python before.

[wedebe]

This is not really a bug in OWF. I don't like to fix problems caused by enigma2. The "bad" chars should be removed inside of the enigma2 epgcache.

I agree. We've recently fixed a similar issue related to Start of content/End of content characters showing in OpenATV ( https://github.com/openatv/enigma2/issues/1954#issuecomment-861738156 ), but an issue still remained somewhere else. That fix would also need to apply to other images which consume the data, when in fact fixing the issue at source at the supplier would be a far more consistent approach.