Roku app HLS stream fails when 302 redirect in use.

[pir8radio 1312]

Roku app fails to play streams when using a 302 redirect.   

 

Currently i'm under the assumption that it is something within the roku (and firetv) app, if you see something that leads you to believe this is incorrect, please let me know what you find. I have no way to test/troubleshoot a roku client other than it fails to play when using a 302 redirect.  Tested working on Emby Theater, iOS app & browser, as well as the web gui.

Edited January 28, 2017 by pir8radio

[Luke 42077]

it's not our video player, it's the Roku system video player with our UI on top of it. Unless there's some kind of server problem there's not much we can do.

[pir8radio 1312]

Well if any of the roku developers have time to try to connect and play something from my server, and can possibly give me some more info, like what error you are getting..  I just don't have access to those tools, so it's almost impossible for me to troubleshoot. 

 

Thanks for the info Luke.

[speechles 2055]

https://forums.roku.com/viewtopic.php?t=57128

 

They talk about that same thing here. It looks like this might still be a bug in the present roku firmwares. It is possible to work around the bug, and have the relative path use the landing url and not the original url. Suffice to say, its not you, its a limit of the rovideoscreen function not handling cookies, combined with roUrlTransfers use of relative paths and using original page instead of landing page base url's to construct redirects. Together it breaks all your m3u8 links and renders HLS useless. I will look into supporting this.

Edited January 26, 2017 by speechles

[pir8radio 1312]

whats strange is old roku app does nothing, new roku app (new preview) will play everything just fine.  So process of elimination would lead me to believe the issue is in the roku app.

Edited January 26, 2017 by pir8radio

[ebr 16169]

whats strange is old roku app does nothing, new roku app (new preview) will play everything just fine.  So process of elimination would lead me to believe the issue is in the roku app.

 

Did I read that correctly, that the beta Preview does NOT have this problem?

[pir8radio 1312]

correct not sure why....  i assume you only changed the look lol but the preview does NOT have this issue.

[ebr 16169]

No, the new app is a complete re-build pretty much from the ground up using newer methods.

 

What this tells us is the video player is different as well and, we don't need to worry about this issue .

[pir8radio 1312]

No, the new app is a complete re-build pretty much from the ground up using newer methods.

 

What this tells us is the video player is different as well and, we don't need to worry about this issue .

lol...   agreed,  when is the official set to come out? 

[speechles 2055]

Did I read that correctly, that the beta Preview does NOT have this problem?

 

The benefit of scene graph is that is roku's priority. The older brightscript components fall by the way side in favor of xml.

 

The problem is roVideoScreen not being able to carry across cookies from roUrlTranfer when grabbing the m3u8. Without the cookies the session is invalid. There needs to be a helper global var, which keeps track of them, so they can be applied to roVideoScreen.

 

I will look into this more today and see what I can find out.

[pir8radio 1312]

I didn't think Emby used any cookies at all? I thought everything carried over using html5 storage, headers or query strings.. I'm still learning.

Edited January 26, 2017 by pir8radio

[pir8radio 1312]

FYI I have disabled CF on my test domain name..  If someone needs to do further testing let me know I can setup a different url.