Add support for GZip compressed EPG xml

Hi there. A major drawback with Channels DVR (in my use case at least) is the lack of support for xml.gz, as a lot of these online EPG building tools do not support uncompressed EPG. Not sure if that has to do with saving bandwidth or what.
But it would be nice if you guys could add support for this.
Thanks.

It should work. Is there a specific error you're seeing?

No error. They're just not being detected.
When I use m3u4u.com to build EPG guides, the compressed version doesn't work. The uncompressed one does. I also tried the EPGs over at https://github.com/epgshare01 and they don't work either. However. They do if I download and extract them. So now I've set up a cronjob to do this once a day.

Please submit diagnostics from your DVR

Sure. Here you go: ca8382dd-b60d-4bce-a956-ea65bd26bf7e

Looks like you might have reinstalled so I'm not seeing the previous failures with the gzip sources

Right.
Okay I just re-added the xml.gz list and redownloaded the EPG to see if I could resolve the problem.
I skimmed through the log myself. Couldn't find anything other than this:
2021/09/06 21:58:06.880435 [IDX] Pruned 0 expired airings from XMLTV-USLocalTV in 138.973ยตs..
Not sure why it expired. There's nothing wrong with the EPG. Like I said โˆ’ when I extract it and use the .xml file, it works fine.
The new log is 975ed49c-5a43-4601-998b-6b780d2c427a

And from browsing the forum, it isn't just me.


And also here: XML Guide for M3U tuner?
AeroR1's reply confirmed it.
So I don't think it's an issue on my end. gzip might not be supported.

Thanks I see the issue.

Are the other affected urls ending in .gz also?

Yes.

Okay fix is uploading in next prerelease

1 Like

Great. Thanks.
So .gz was not listed as a supported format, huh?
Glad it was that simple.

v2021.09.06.2051 is available now.

1 Like

Thank you!

The web server this was hosted on was not configured properly to tell our client that the file was compressed. We had to implement a work-around to decompress URLs ending in .gz which is against HTTP specs, but is required to make this work here.

2 Likes

autoprocessing of content has nothing to do with http specs. no http specs have been violated :wink:

He was saying that the server was not correctly setting the header to let the client know the content was compressed. Typically, when the HTTP server sends content that has been compressed/gzipped, a header is present letting the client know. From the dev's comments, the server in question was not setting the header, so Channels did not expect the content to be compressed.

That's not what happened. what header btw? :wink:

Content-Encoding

Edit: Here's the section of the HTTP spec. Note the use of the word MUST when compressed data is sent: https://httpwg.org/specs/rfc7231.html#header.content-encoding

You are confused. This header is only used if the data is compressed by the server on the fly. In our case the client requests already compressed data so no extra header needed.

The problem for channels here is there is no uncompressed data available.

Check also https://nginx.org/en/docs/http/ngx_http_gzip_static_module.html