Live Streams

[bmlzootown]

The way the API currently works, you have to query the channel itself to see if there is a stream in progress or not. Polling the API repeatedly is a no-go, so a workaround needs to be found if this is ever to be implemented.

[bmlzootown]

Emailed support and they mentioned a webhook endpoint that could be used for push notifications (which I assume should work for live streams as well). Need to figure out where said endpoint is, and how to properly utilize it.

[bmlzootown]

Still waiting for a response from their support, but I have semi-solved the issue... Users can now attempt to play a channel's stream from the options menu (*) after they have selected a channel (or the 'play' button). The current 'fix' assumes that the user knows a channel is streaming, though, which will be problematic when more creators join the platform.

[bmlzootown]

This should be resolved as of the latest commit.

Once the user selects a creator/sub, we grab that creator's info (which gives us the stream path, title, etc.). Then we use a sketchy workaround to see whether the creator is streaming or not (/api/creator/list, unlike more obvious api calls, is actually the only way I've found to check whether a creator is live or not). If they are streaming, the first video shown will be the live stream.

I also accounted for changes in the api which previously broke streaming support completely. The stream path itself previously didn't include the proper .m3u8 file extension, so we had to append it -- now it seems they've changed the stream path completely, and included said extension, so it should be good to go w/o being modified.

I'll hopefully be home in time to properly test this Friday, so I'm going to go ahead and close this issue for now. If it persists, I'll open it back up.

[bmlzootown]

Nope, still not working.

[bmlzootown]

It looks like I was wrong about /api/creator/list showing whether a creator was live or not, as liveStream is null regardless, meaning there probably still isn't a proper API call to check whether a channel is currently live or not. I'll disable checking for now in the next update.

*** ERROR: Invalid path: '#EXTM3U

EXT-X-TWITCH-INFO:NODE=video-edge-c2a9f8.atl01,MANIFEST-NODE-TYPE=weaver_cluster,MANIFEST-NODE=video-weaver.atl01,SUPPRESS=true,SERVER-TIME=1579312986.40,TRANSCODESTACK=2017TranscodeQS_V2,USER-IP=REDACTED,SERVING-ID-3

An unexpected problem (but not server timeout or HTTP error) has been detected.

lvs.758417551536.linustechtips.m3u8.txt

So, I could really use a bit of help with the above error at this point. After poking around during the stream tonight via Chrome's dev tools (element inspector/console), if looks like the LTT livestream is being streamed, at least in part, via Twitch's servers. Accounting for this, the API-provided streamPath works correctly, resulting in a usable (tested in VLC) .m3u8 file. The problem is that, when providing the Roku with the link to the .m3u8 file, it spits out the above error. I'm not quite sure what the problem is, so if anyone has any ideas, I'd greatly appreciate the feedback. Does it simply just not like that specific line? And if so, is that bit necessary?

I'll do some more prodding next week, see what happens when it's provided with a modified m3u8 file. Sorry everyone.

[bmlzootown]

It seems that grabbing the m3u8 file via roUrlTransfer, writing that to a file in temp:/, and then loading it from said file works... For whatever reason.

In any case, I have live-streams (well, at least LTT's live-streams) working again. Still not sure how I'm going to go about detecting whether a stream is currently live or not, however.

I'll push out an update tomorrow after looking over the changes once, or twice, more.

Edit: An idea... Could just attempt to play a stream whenever a creator is selected, in the background, and go from there. If it errors out, they aren't live, and if it doesn't, and the play-time counter progresses, we stop the stream and append the relevant content node to the beginning of the content screen. Would make loading a bit slower, as it wouldn't be asynchronous, but it should work. I'll think on it some more after work/tomorrow.

[bmlzootown]

Live-streams via options menu are working again as of https://github.com/bmlzootown/Hydravion/commit/4f5f3033d8070a8fd87607e14d1e8d70fc947344.

If I'm remembering correctly, Luke and/or Linus had once stated during a WAN show that creators can stream to Floatplane in a few different ways. To accommodate such, I had it check the streamPath for platform specific patterns ("live_abr", "/api/lvs/hls/lvs" being the two examples that I've already seen). If there are any more, I'll work on integrating them when the issue arises.

[bmlzootown]

https://github.com/bmlzootown/Hydravion/commit/335fc20e7306ba88cecd255a23cd4ac341288729 properly accounts for the two possible CDNs already seen (Floatplane itself, and Twitch's servers). There's still room for error here, if they should ever use another (which might introduce more tokens/other variables), but it grabs all the requisite info from cdn/delivery. That said, I'll leave this issue open until I come up with a working solution to detecting whether a stream is currently live or not.

[bmlzootown]

Fixed