[HLS] Playback fails if using substream URL directly

[matthuisman]

Some IPTV urls are only provided as a substream URL with no access to a master URL. Inputstream will fail to play any urls that aren't a master stream.

Would it be possible to also allow playback when using a substream URL?

Here is my debug log: https://pastebin.com/z811jzmU

Parse error at line# 2419

[JinRonin]

Fair warning for you (once again): You can be held liable for restreaming copyright protected material and bypassing geo restrictions.

[matthuisman]

@JinRonin What are you talking about? Way to keep on-topic.

1) All the IPTV streams (And content) I stream are from their official public sources. No different to Netflix KODI add-on or BBC KODI Add-on. 2) Adding a X-Forward header to a request is no different than you adding a User-Agent header to receive a different response meant for a browser or phone. If the site is dumb enough to be that easily tricked (many aren't now) then I'm doing them a favor by exposing it.

And "restream"? WHAT? You think I'm going to pay for enough server bandwidth to download some copyright stream and then re-stream it? And then provide that for free?

[peak3d]

@matthuisman I need a the playlist file to get an idea what you mean.

[matthuisman]

@peak3d

https://rbmn-live.akamaized.net/hls/live/590964/BoRB-AT/master.m3u8 (will play fine) https://rbmn-live.akamaized.net/hls/live/590964/BoRB-AT/master_3360.m3u8 (won't play)

https://tvsn-i.akamaihd.net/hls/live/261837/tvsn_nz/tvsn_nz_750.m3u8 (won't play - no master stream provided)

[peak3d]

@matthuisman

The problem with subURL's is, that I don't have any information what kind of stream it is. Audio? Video?

Opposite to ffmpeg I don't do any stream preparsing to get information whats inside the ts file. I could, but it is much work and we already have ffmpeg working fine for this.

Pls. preanalyze the playlist file, and if its not a multistream master playlist, play it simply with ffmpeg. ffmpeg is doing a nice job for sub files.

[matthuisman]

I tried the below as a master.m3u8 and inpustream played it fine

#KODIPROP:inputstreamaddon=inputstream.adaptive
#KODIPROP:inputstream.adaptive.manifest_type=hls
http://files.matthuisman.nz/master.m3u8

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=0
https://rbmn-live.akamaized.net/hls/live/590964/BoRB-AT/master_3360.m3u8

That doesn't have any useful info in it? Inpustream simply shows the 1x stream with resolution and no bandwith.

Could substreams not be treated as if they just came from a master playlist like above?

Worst case I guess I could generate master playlists like the above for any substream only HLS streams.

[peak3d]

valid argument :-)

[matthuisman]

Thanks @peak3d

Looks like this guy https://github.com/peak3d/inputstream.adaptive/issues/162 had same issue.

In his case, there was a master playlist.

I think it might just save you a few more "this won't play" if they were treated as a single stream master playlist?

Or, maybe even if it possible to have inpustream fallback to simply parsing the url to KODI (ffmpeg) to try? This would then eliminate needing to check if inpustream was a certain version before telling the add-on to use it.

[matthuisman]

I'm going to close this as it's not really an issue. However, maybe an idea to implement in the future.

[matthuisman]

@peak3d I think your commit https://github.com/peak3d/inputstream.adaptive/commit/aa272b13a671468ad4443c32e4fcc3205023fee6 adds support for this issue?

[peak3d]

Yes, thx, I searched for this one, but didn't find it.

[matthuisman]

Awesome! Thank you :)

On Fri, 10 May 2019, 6:30 PM Markus Pfau, notifications@github.com wrote:

Yes, thx, I searched for this one, but didn't find it.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/peak3d/inputstream.adaptive/issues/159#issuecomment-491173078, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPQAKOITEGJ4I6OO57GVETPUUJANANCNFSM4FE7CGRQ .

[matthuisman]

Hi @peak3d

Was testing this and seems there is a url calculation error when using a redirect

http://i.mjh.nz/nz/tv.45/m.m3u8 -> https://tvsn-i.akamaihd.net/hls/live/261837/tvsn_nz/tvsn_nz_4m5_4500.m3u8 -> https://tvsn-i.akamaihd.net/hls/live/261837/tvsn_nz/m.m3u8

Log: https://pastebin.com/raw/N10HRG7d

Using https://tvsn-i.akamaihd.net/hls/live/261837/tvsn_nz/tvsn_nz_4m5_4500.m3u8 directly works fine

[peak3d]

@matthuisman current implementation replaces only the path to file, but not the filename by itself. I'll remove effective path replacement if resulting filename does not match the requested one.

Edit: https://github.com/peak3d/inputstream.adaptive/commit/08b2be65a0344230798a22782ec248f2934bce88

[matthuisman]

That sorted it. Thank you again!