EPG images fail to load in iOS apps

Channels DVR Server
#1

I ran into an odd issue with my EPG provider (epg.best). They include an image for each show with the following tags:
<icon src="//www.sms.cz/~tri65dnigalerie/porad_booklet/600/0/08b4017f7551a9200bcb23c41c975887.jpg"/>
This image gets picked up by Channels DVR and displayed correctly in the web interface. However, it fails to display on iOS and TvOS apps (it shows black image instead). Is this an issue with the picture format or EPG format?

#2

Please submit diagnostics from the app on your iPhone/iPad and we can see what's failing

#3

Ok, thanks, I just did. I have the 3 channels using this EPG lined up as 1, 2, 3.

#4

I guess the problem is because it doesn't say https: before the // in the xml file.

#5

Got it, I was thinking the same, but oddly the web DVR interface was able to display it. I will follow up with the provider. Thank you.

#6

Yea browsers can deal with that syntax, but apps cannot.

#7

Thanks, I solved it by switching a provider. Now the syntax works fine.

I had one unrelated question. Is there any way to set a default EPG language? I noticed when multiple titles are present, Channels takes original title (title lang=“xx”) by default and I can’t figure out how to force it to use a local title (title lang=“en”).

#8

Can you provide an example <programme>

#9

This is an example, I’m trying to use the lang=cs title tag, but by default Channels uses the lang=xx tag.
<programme start="20210523180000 +0000" stop="20210523193000 +0000" channel="1040-sport">
<title lang="cs">WRC Vodafone Rally de Portugal - SS20 Fafe 2 WOLF PS</title>
<title lang="xx">Wrc</title>
<desc lang="cs">Záznam 4. podniku Mistrovství světa v rallye (Portugalsko).</desc>
<category lang="cs">Rally</category>
<icon src="https://www.o2tv.cz/img/epg/o2_sport_hd/29871818/profi_cover.jpg" />
</programme>

#10

This must be a bug, since "xx" is not a recognized ISO 3166 two letter CC. I would assume the expected behavior would be for anything with lang="xx" to be ignored, since it is not a valid ISO-3166 CC, and therefore not part of RFC 1766.

#11

Thanks. Since this was unrelated to the topic of this thread and probably requires a longer discussion, I have created a new thread here: