Split master.m3u8 into seperate playlists

[bjoerns1983]

I have just recognized that some clients eg. Emby have problems if you use m3u8 Playlists with multiple resolutions.
Emby for example will always take the smallest. Any of you got an idea how we can split it into seperate lists with the least amount of manual interaction?

I dont want to have the channel in the source.yaml several times just to have multiple resolution output m3u.

@plata maybe any suggestions?

https://www.kodinerds.net/index.php/Thread/74586-IPTV-Kodinerds-Liste-in-Emby/?postID=674392#post674392

[plata]

To understand correctly:
Emby doesn't like e.g. https://mcdn.daserste.de/daserste/de/master.m3u8 because it contains multiple resolutions

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-STREAM-INF:BANDWIDTH=1672000,AVERAGE-BANDWIDTH=1460800,CODECS="avc1.4d401f,mp4a.40.2",RESOLUTION=640x360,FRAME-RATE=50.000
master_640p_1328.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1034000,AVERAGE-BANDWIDTH=910800,CODECS="avc1.4d401e,mp4a.40.2",RESOLUTION=480x270,FRAME-RATE=50.000
master_480p_828.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2182400,AVERAGE-BANDWIDTH=1900800,CODECS="avc1.4d401f,mp4a.40.2",RESOLUTION=960x540,FRAME-RATE=50.000
master_960p_1728.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=4224000,AVERAGE-BANDWIDTH=3660800,CODECS="avc1.640020,mp4a.40.2",RESOLUTION=1280x720,FRAME-RATE=50.000
master_1280p_3328.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=6520800,AVERAGE-BANDWIDTH=5640800,CODECS="avc1.64002a,mp4a.40.2",RESOLUTION=1920x1080,FRAME-RATE=50.000
master_1920p_5128.m3u8

https://mcdn.daserste.de/daserste/de/master_1920p_5128.m3u8 would be ok.

It should be relatively easy to parse the .m3u8 (e.g. with https://pypi.org/project/m3u8/) and then build one channel per resolution. I would suggest to separate this to a new directory, though. We don't want to bloat the "clean" lists with it.

Implementation would basically be:

• copy

  kodinerds-iptv/scripts/yaml_to_m3u.py

  Line 6 in 40f50a5

  def write_clean(content):

• parse stream["url"]
• if it contains multiple entries, generate one header_line + line for each entry (add resolution to tvg_id_str)

[bjoerns1983]

Correct Emby does not like those multiple resolution m3u8, seems it would always simply pick the first resolution listed. And the Emby devs do nothing about since min. 2,5 years. Its always the same game with them.

I will have a look at the yaml_to_m3u tomorrow. It is also the question what to do when the m3u8 is parsed.
Simply take the highest possible resolution? Make a new list for every resolution?
At least having the direct links to the m3u's would also have the advantage that it takes least time start the stream compared to the m3u8.

[freddii]

maybe ask at emby for help to not only support the smallest.

[bjoerns1983]

If there would be any chance that the dev's of Emby change that in the near future i wouldnt have asked here.
https://emby.media/community/index.php?/topic/80106-m3u-how-to-make-emby-pick-highest-quality-stream/

[plata]

Simply take the highest possible resolution? Make a new list for every resolution?

I would make a new folder clean_all_res and keep all resolutions. Might be that someone wants to use a lower resolution e.g. because of Internet speed.

[jnk22]

Using the m3u8 library is a great idea, this would also solve the problem that master-streams usually take a lot longer (felt like 1-2s instead of 200-300ms to me at least) when opening them in Tvheadend.

---

We could also create resolution specific sublists for each resolution - if available:

clean (all resolutions, e.g. master-m3u8s)
clean_2160
clean_1080
clean_720
clean_540
clean_480
clean_360

I would propose to handle the other lists (kodi/pipe) the same, as this is also beneficial here.

We would then have to decide how to deal with streams that have no "lower bandwidth" stream, e.g. what to do with a 1080p stream for the 720p list? imo it should be available in that list regardless.

Having a separate list for each resolution makes it possible to "ignore" 4K streams if they become more regular. This might be relevant to users with limited bandwidth in the future.

This might be a bit more complex and would generate some more lists of course - it depends on what we think is required for most or all the users.

What do you think?

[bjoerns1983]

Sounds good. I mean the data is there anyway.
The only thing that could get a little bit complicated is that not all master.m3u8 have the same resolutions inside.

[plata]

The only thing that could get a little bit complicated is that not all master.m3u8 have the same resolutions inside.

Yes.

There are two options:

1. parse twice: in first run, collect all resolutions, then fill the lists
2. define subset of supported resolutions

The 1. is slightly more complicated but a lot more flexible.