Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

bmlzootown

Member
  • Content Count

    19
  • Joined

  • Last visited

Awards


1 Follower

About bmlzootown

  • Title
    Newbie
  • Birthday 1994-12-13

Contact Methods

Profile Information

  • Gender
    Male
  • Location
    NC, USA
  • Interests
    Playing music, programming, questioning life choices.
  • Occupation
    Retail, sadly...

System

  • CPU
    Ryzen 7 1700X 3.4GH 8-Core
  • Motherboard
    Asus STRIX B350-F
  • RAM
    G.Skill Aegis 2x8GB DDR4-3000
  • GPU
    Asus GeForce GTX 1060 6GB
  • Case
    Cool Master HAF 932 Advanced ATX Full Tower Case
  • PSU
    EVGA SuperNOVA G2 650W 80+ Gold
  • Display(s)
    Asus VG248QE 24.0"
  • Cooling
    Cooler Master Hyper 212 EVO 82.9 CFM
  • Operating System
    Windows, Debian, MacOS (Hackintosh)
  • PCPartPicker URL

Recent Profile Visitors

353 profile views
  1. And suddenly... The issue appears to be gone. Nothing has changed on my end, so I'm assuming it was something on the server's end. Hopefully the stream will work fine this Friday, but I should be around to test during that time.
  2. Just a slight update (if you can really even call it that): I have yet to figure anything out, and nobody has responded to my thread about live-stream HLS issues on the Roku community forum. I've bumped the post multiple times to no avail. Shamelessly plugging the link here as well, just to get a tad bit more exposure.
  3. It's... a bit complicated. Since I have no paid developer account, I can't really release it on the app store, so you'd have to sideload it (this video gives a basic gist of how to do so -- older devices connect via USB, newer 4k models can be added wirelessly, should be able to figure that bit out with a quick Google search). The source is up on Github. If you have any issues, let me know. I've only tested on the simulator, so I make no promises that everything will work 100%.
  4. Darn it. Well, I'll keep poking. If I come up with anything (or if anyone else looking at this happens to have any ideas), I'll let you all know. Sadly, I'll be at work until 10pm EST next Friday as well (next week is going to be hectic), so I won't be able to test while an actual stream is live for quite a while. Linus... why you no live stream more often?! Edit: No, yeah... it's freezing/stuttering/tiling again when I test it w/ other HLS stream sources. This is weird. May be an OS-related bug? I'll keep poking. Edit #2: This seems to be an issue relative only to Roku. I can play the exact same live stream via VLC, or the port of Hydravion that I wrote for tvOS, with absolutely no issues. I'm going to post on their dev support forum to see if this is a known problem, or if anyone has found a fix.
  5. So I'm not sure what's causing the stuttering when the WAN show is live. Swapping out the stream URL for, say, a Twitch stream does cause issues, but it's not quite the same stuttering that both I and @Elektra57 have experienced (in this case, the video just completely stops after a few seconds). I'll switch back to reading the m3u8 playlist directly via URL and hope for the best. I won't be home tonight (working until 12am), however, so I won't be able to test. If anyone else can, it'd be appreciated. I'll go ahead and push out the update now.
  6. So I may have done a thing... It's a work in progress, but I plan on polishing it up a bit and will do my best to continue updating until the Floatplane team has an official release out. https://github.com/bmlzootown/Hydravion-tvOS

  7. I've been in there for a while, and ya know what... The thought never even crossed my mind, haha.
  8. Anyone watching atm, live streams still aren't working. I'm looking into it asap while the WAN show is currently live. I wan't able to figure it out in time. For anyone that has any experience with proper m3u8 formatting, Twitch, and/or Roku, I'd appreciate it if you'd take a look at the relevant issue that I've reopened on Github. After tinkering all night, I was able to at least get live streams working again (or at least live streams from the LTT channel). Still no way to determine whether a sub is live or not, however. Edit: There have been subsequent updates that I haven't created a new post for, but they are reflected in the changelog (second post), so be sure to check that out!
  9. My download isn't that bad, but the ping sucks -- trying to play games via GeForce Now is still a horrible experience, at least for myself, with that kind of delay. No matter the speed, my ping with Spectrum has always been spotty.
  10. Thanks to some PTO that wasn't going to carry over at the start of the new fiscal year, I've had some extra time on my hands the last few days. v1.5 is now live, with a few of the following changes: Edge servers are (sort of) handled properly now. On login, the channel will pick the fastest connection and use that server. Those of you already logged in are fine, it will pick the best server on startup. If you go into the options menu (asterisk) when viewing the detail screen (screen with the play button), you will now be presented with every possible resolution, per your subscription, for the given video. If your setup supports 4k and you have the $10 sub, that should now be reflected... and, if by some magically chance your Roku device supports 8k, you should totally check out the yule log video in its full glory (if you dare)! Live streams should (hopefully) be fixed. There was an update server-side at some point that broke it completely, but I've fixed what all I could. Any stream that is currently live should, in theory, now be the first video available upon selecting a creator from the subscription screen. Speaking of, if anyone happens to catch the next WAN show, I'd appreciate any feedback as to whether the last two bullet points worked properly for you or not. I should be home by then, but after roughly an entire week away from work, there's no telling how hectic my day will be... Thanks! 1/16/2020 Edit: Updated to 1.5.2, fixed an issue caused by the live-stream check.
  11. Pushed an update (1.4.4) just now. Newer videos were sometimes timing out due to Roku's VideoPlayer's short default timeout. Bumped that up to (an insane) 30s just to be safe, and it seems to be working. If that proves to be too long in the future, I'll dial it down a bit. As always, if anyone has any issues, feel free to poke me/open an issue on github!
  12. Was the channel crashing, or was it loading a grey-ish blank screen? The former was the issue described above, which was entirely my bad. The latter is an issue I've experienced as well in the past on my Roku 3, but I could never keep the app side-loaded long enough to see what the cause was (everything I side-loaded on the Roku 3 would crash after a minute or two). I was able to bypass re-installing all together by logging out (options key), though, which dumps the stored cookies and sends you back to the login screen, hence I believe the issue may be related to said cookies expiring. I'm off tomorrow (well, today), and I also have a few days next week... I'll poke around a bit more and see if I can replicate the issue under more controlled conditions. You're more than welcome! Thank y'all for helping iron out the bugs. If it was just me, half of this stuff would go unnoticed.
  13. The fix to the previous error (AES-key related) meant that the video player couldn't be properly initialized until later as it required access to the proper cookies to grab the relevant key file. I've moved that bit of code to run after the user successfully logs in, so all should be good. The update has already been pushed. Sorry about that! If anyone is still having issues, feel free to open another issue on Github (or reopen #4 if you're still experiencing the same bug @Dr. Pockets).
  14. Were you the one who opened an issue on Github, by chance? If so, I apologize for not seeing it (as well as this) sooner. I haven't been getting any notifications for some reason over there, and the email notifications here look so similar to the notifications for Floatplane that I must have swiped it away on my watch while at work. Are you sideloading the channel, or did you add it through the official Roku site? What's the max resolution of the TV, model, and what firmware is it running? I doubt any of those things would be the cause, but it's better to be safe than sorry. The channel starts by loading the home_screen, where the login screen is initially set to visible, and it checks to see if the necessary cookies (for API calls) are stored in the registry... Perhaps the issue lies therein? I haven't had said issue on either my Roku 3 or Ultra, but that doesn't mean they didn't change something specifically for TCL's devices (although doing so seems unlikely). All that said, the way Roku handles debugging in general is a bit odd, imo -- to view any output from a channel, one has to sideload it and then telnet into the debugging console (port 8085). If you're comfortable with doing that, I can create a separate testing branch for you to sideload, and then you could post the output here (or in the Github issue) so that I can poke around at it. Edit: I created a filter to catch email notifications about replies to this thread, and have it setup to forward them directly to my phone via text. That should definitely catch my attention from here on out.
  15. Welp, here's that update (it's amazing what a few hours of sleep can do for one's mental well-being). Either they switched to using AES-128 recently, or the API call to grab the AES key didn't previously require the proper cookies to grab it... Either way, after telling the video object to pass along the proper cookie headers, it can now grab the key, so everything seems to be in working order. The updated version should be pushed out shortly. Edit: Update has been pushed.
×