plugins.btv: fix #5701
Conversation
|
|
||
| return HLSStream.parse_variant_playlist(self.session, stream_url) | ||
|
|
||
| hls_url = update_scheme("hls://https://", stream_url, force=False) |
There was a problem hiding this comment.
update_scheme() doesn't make any sense here and needs to be removed:
hls://is the explicit scheme of Streamlink's HLS plugin, so that direct HLS playlist URL inputs can be handled whose path don't end with.m3u8.
See https://github.com/streamlink/streamlink/blob/6.4.2/src/streamlink/plugins/hls.py#L13-L15update_scheme()does only apply the scheme to the stream URL if it's missing, which is not the case here, hence the reason why you didn't notice any issues withhls://. If you'd actually addhls://to the stream URL, thenrequestscouldn't find a matching adapter for this URL.
| streams = HLSStream.parse_variant_playlist(self.session, hls_url) | ||
| return streams or {"live": HLSStream(self.session, hls_url)} |
There was a problem hiding this comment.
As you can see in #5698, the site started returning HLS multivariant playlists instead of HLS media playlists, so a fix was committed accordingly. The URL test cases returned valid streams (./script/test-plugin-urls.py btv), and they still do that now, I just checked it again.
Does your PR mean that this is not the case 100% of the time, and they return both kinds? You're saying that Streamlink is throwing errors. That shouldn't happen when trying to parse a multivariant playlist on a media playlist. The result should be an empty stream list.
|
Closing, since there hasn't been any response to my comments from two weeks ago. The plugin is still working fine and I don't see any reason why an HLS media playlist fallback should be added when the site has switched to multivariant playlists |
Fix to plugin btv.tv which was broken though changes on stream provider.
Plugin is now parsing the hls URL and starting it directly, instead of only throwing error.