Unable to Add IPTV XMLTV (m3u works fine)

[sub]

If you want to PM me the urls, I can briefly check the import against them in the debugger, and fix if necessary/possible.

(I have no interesting watching your channels, and will only need the urls for a few minutes to check the import logic)

[add45]

If you want to PM me the urls, I can briefly check the import against them in the debugger, and fix if necessary/possible.

(I have no interesting watching your channels, and will only need the urls for a few minutes to check the import logic)

Sure sending the PM now.

[sub]

The problem is happening because the 'content type' of your xmltv url is returning 'application/xml', so it starts processing it as xml. The data is infact gzipped, so it should return a content type of "application/gzip" or "application/x-gzip", to tell it to decompress the stream before processing it.

Unfortunately there isn't anything about the url, or the response from google that indicates it's gzipped, and unfortunately NextPVR doesn't find out until it's too late.

Assuming this is your own google drive, the easiest fix is probably just to use the raw .xml file, rather than gzipping it.

Here if I force it to treat the content as though it was type "application/gzip", then it works fine.

[add45]

The problem is happening because the 'content type' of your xmltv url is returning 'application/xml', so it starts processing it as xml. The data is infact gzipped, so it should return a content type of "application/gzip" or "application/x-gzip", to tell it to decompress the stream before processing it.

Unfortunately there isn't anything about the url, or the response from google that indicates it's gzipped, and unfortunately NextPVR doesn't find out until it's too late.

Assuming this is your own google drive, the easiest fix is probably just to use the raw .xml file, rather than gzipping it.

Here if I force it to treat the content as though it was type "application/gzip", then it works fine.

Ah okay that's a bit annoying that google assigns it that content type. Is that a bug on google or is it being uploaded incorrectly?

And of course the raw XML doesnt work because Google won't allow a direct download link to files of a certain size. Basically google sucks but there isnt much choices available (at least from IPTV Boss for automating).


Thanks for looking into this!

[sub]

I've added a work around for the next build, where you can add "&contentType=application%2Fgzip" to the url and NextPVR will treat it as gzipped regardless of what google says it is. (effectively allowing you to override whatever google says the content type is)

I tried it here, and google is just ignoring this extra data on the url, but it's useful for us to flag that it is gzipped.

[sub]

Ah okay that's a bit annoying that google assigns it that content type. Is that a bug on google or is it being uploaded incorrectly?

What extension are you using on the file name? Maybe make sure you're using ".gz". I would hope google would send the write content type with this. ie guide.gz

[add45]

Ah okay that's a bit annoying that google assigns it that content type. Is that a bug on google or is it being uploaded incorrectly?

What extension are you using on the file name? Maybe make sure you're using ".gz". I would hope google would send the write content type with this. ie guide.gz

Yeah the extension is definitely .gz, it's being generated by an epg tool so it's all good until it makes it to GDrive.

Thanks again for being so quick to add this as a feature lol, hopefully it helps others with the same issue...

[sub]

Is it .xml.gz, or just .gz. You might need to try the latter if it’s currently the former.

[add45]

Is it .xml.gz, or just .gz. You might need to try the latter if it’s currently the former.

It's .xml.gz. Is the docker image updated with the latest version? I can try once it is..

[mvallevand]

Subscribing to the announcements thread https://forums.nextpvr.com/forumdisplay.php?fid=18 rather then posting release question saves everyone time.

Martin