Thanks, this seems to work.

As a side note, the plugin is still setting an Android user agent header. The site however now seems to require the user to download a mobile app when accessing it with any mobile phone user agent. HLSStream was used previously because of their old mobile site from what it looks like, which is much more preferred over progressive HTTPStreams that their main site is using (which is ridiculously bad). So if there is a way to request HLS streams again, which is probably what their mobile apps are still doing, then this should be implemented instead.

The browser on pc uses flv, I tried m3u8 first, but adding wsSecret and wsTime to m3u8 can not fix the stopping bug.

Thanks, this seems to work.

As a side note, the plugin is still setting an Android user agent header. The site however now seems to require the user to download a mobile app when accessing it with any mobile phone user agent. HLSStream was used previously because of their old mobile site from what it looks like, which is much more preferred over progressive HTTPStreams that their main site is using (which is ridiculously bad). So if there is a way to request HLS streams again, which is probably what their mobile apps are still doing, then this should be implemented instead.

adding wsSecret and wsTime to m3u8 can not fix the stopping bug

It's possible that those parameters need to get re-calculated / re-obtained for each playlist refresh, while the progressive stream with the single-HTTP request just keeps going without aborting. Subclassing the HLSStream class and implementing refresh logic is not worth the hassle though, so this seems fine.

You'll still need to fix the linting issues before this can get merged.

No, this is just added as a reminder for PRs with multiple commits that need to get squashed when merging.

Thanks for your help.

No, this is just added as a reminder for PRs with multiple commits that need to get squashed when merging.