Support fetching and parsing of referenced M3U files

[khimaros]

Example can be found here: https://github.com/iptv-org/iptv/blob/master/index.m3u

[phunkyfish]

Sorry, the addon is designed to load a single playlist where each item represents a channel. The format you give combines many playlists which is not supported.

[khimaros]

Would you be open to patches adding this functionality?

[phunkyfish]

If it’s the defacto standard for how this is done for M3U (do you know this?) I don’t see an issue with adding the functionality.

Just bear in mind this is a considerable change and doing it correctly could be a large piece of work.

It would need to be added in the matrix version of the addon as architecturally it has changed quite a bit. I’m not sure the extra effort of also porting to Leia would be worth it.

[isaiev]

@khimaros I had same issue, it can be fixed with VLC player by saving playlist after it loaded by VLC

[khimaros]

This is a pattern used in aggregate IPTV lists, such as the popular https://github.com/iptv-org/iptv

[phunkyfish]

Are there other examples apart from the repo you have provided?

The bigger problems to solve are how to manage things like caching and EPG. With so many files this is really hard to do. Plus with refresh in the matrix addon it could try and read hundreds of files every few minutes. GitHub would block your requests after a short time unless you cloned the repo locally. If this is implemented maybe only support it on the local file system?

Then there is the matter of what the logic should be for an embedded M3U file. Should you infer that a relative path means it’s embedded and it’s must have name and assume it’s a group otherwise discard it?

It’s complex. And so seeing other examples is important to see if they are all done the same way.

[maaaatteo]

agree with OP, this situation makes the addon unuseful (it seems that most of m3u list apply this format actually). that's a pity

[phunkyfish]

Please provide examples. So far only a single example has been provided.

This functionally might be better provided via the iptvmerge addon. @matthuisman is this supported in iptvmerge?

[maaaatteo]

here are a couple of lists which the sellers show as "test" before the purchase:

https://tinyurl.com/rwuxrk6 https://tinyurl.com/wa6yus3

[matthuisman]

Would be relatively easy to add to IPTV Merge. I've created an issue on my repo to remind me. https://github.com/matthuisman/plugin.program.iptv.merge/issues/11

[phunkyfish]

Thanks @matthuisman

If this can be added along with support for x-tvg-url then users could supply a single M3U and then merge everything.

With the changes in Matrix it should make things far more reliable going forward.

[phunkyfish]

Nice, thanks ;)

[phunkyfish]

here are a couple of lists which the sellers show as "test" before the purchase:

https://tinyurl.com/rwuxrk6 https://tinyurl.com/wa6yus3

Neither of those links work I'm afraid.

[matthuisman]

Thing with this

#EXTINF:-1,New Zealand
https://iptv-org.github.io/iptv/countries/nz.m3u

vs

#EXTINF:-1,TVNZ 2
https://d3vsmj0a4dgta4.cloudfront.net/master.m3u8

How will my code know that the first needs downloading and processing, and the 2nd doesn't. I suspect you need to download every url until you find EXT-X-STREAM-INF

I guess it could be a bit smart on what it downloads

1) If the EXTINF line has any 'tvg' attributes - assume it's a channel and don't download 2) Skip download if extension is not .m3u or .m3u8 (we don't want to be trying to download an endless stream) 3) Keep downloading down until it hits EXT-X-STREAM-INF

I guess it could do a thread for each required url in the first playlist.

[phunkyfish]

Makes sense, I guess you would need to download the first X bytes of the URL. In iptvsimple I download the first 1024 and test that for any identifiers for HLS streams.