Add support for GZip compressed EPG xml

#21

I don't have an account at m3u4u.com, so I can't comment to that. However, using the epgshare01 example:

curl -v https://github.com/epgshare01/share01/raw/master/epg_ripper_CA1.xml.gz
> Host: github.com
> user-agent: curl/7.76.1
> accept: */*
...
< HTTP/2 302 
< server: GitHub.com
< date: Tue, 07 Sep 2021 20:06:13 GMT
< content-type: text/html; charset=utf-8

Notice how the returned content-type is text/html? If Channels were receiving content-type: applicaton/x-gzip, then perhaps it would know it is receiving compressed content, but it's not. Also, there is no content-encoding header, either.

#22

How about you follow the redirection (302) via -L option in curl to see what the content-type is? :wink:

content-type: application/octet-stream

Also, there is no content-encoding header, either.

Because no compression was requested. If compression is needed in curl

-H 'Accept-Encoding: gzip'

option needs to be added. HTTP 101 :wink:

#23

Which is neither application/x-gzip for a compressed file, nor text/xml or application/xml for XML content. Basically it's just saying "here's a binary file of indeterminate content". Channels was expecting XML, or in the case of compressed XML, something to indicate compression was used. Neither were the case. Now it will check on file name/magic number, neither of which should have been necessary, but apparently is because others can't follow the rules.

#24

Hmmm... How about Channels user was desperate and requested the only available source which happened to be gzip compressed file

The complaint:

seems out of place.

Further unsubstantiated complaints will result in geek card revocation :wink: