Roku Developer Program

Join our online forum to talk to Roku developers and fellow channel creators. Ask questions, share tips with the community, and find helpful resources.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
axiomy
Visitor

StreamStickyHttpRedirects for url redirect

I want to enable url redirects on my roku channel. I saw some info on StreamStickyHttpRedirects and wanted to know if it would do url redirects.

I am using the video player example.

What would I have to add to by showFeed.brs to allow url redirects?
0 Kudos
8 REPLIES 8
RokuMarkn
Visitor

Re: StreamStickyHttpRedirects for url redirect

Redirects in response to 301, 302, 303 and 307 responses are always enabled. The StreamStickyHttpRedirects boolean simply controls whether the redirect should be remembered permanently, so that the chain of redirects doesn't need to be followed the next time the same URL is accessed.

--Mark
0 Kudos
axiomy
Visitor

Re: StreamStickyHttpRedirects for url redirect

Thank you Mark for your response. The problem I am having is with Vimeo Pro and the HLS link they provide. The mp4 links load no problem but he HLS link won't load at all.

Vimeo does a redirect on the HLS link and was curious if anyone at Roku knows how to get this working?
0 Kudos
TheEndless
Channel Surfer

Re: StreamStickyHttpRedirects for url redirect

"axiomy" wrote:
Thank you Mark for your response. The problem I am having is with Vimeo Pro and the HLS link they provide. The mp4 links load no problem but he HLS link won't load at all.

Vimeo does a redirect on the HLS link and was curious if anyone at Roku knows how to get this working?

There is a firmware bug with redirects to HLS streams that use relative URLs in the playlist. Instead of building the fully qualified URL from the landing URL, it uses the original URL as the base, so the URLs are invalid. To work around it, you should do a HEAD request on the URL using the roUrlTransfer component first, then set the stream URL to the value of the Location header.
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
0 Kudos
lmarder
Visitor

Re: StreamStickyHttpRedirects for url redirect

To work around it, you should do a HEAD request on the URL using the roUrlTransfer component first, then set the stream URL to the value of the Location header.


I am trying to do this with a Vimeo Pro m3u8 file and I am not successful.

This is the Vimeo file: http://player.vimeo.com/.....
This is the redirect location: http://av01.hls.vimeocdn.com/.....

I am setting the stream URL to the redirect location

Any help would be very appreciated!
0 Kudos
sjb64
Roku Guru

Re: StreamStickyHttpRedirects for url redirect

Am getting nowhere with this too fast.

Doing the head request recommended by TheEndless and using the response as the URL, or even reading the contents of that response and saving it to tmp, then playing the source through server code in brightscript where the roku itself feeds the top level m3u8 doesn't want to work (this code is tested and works normally, we use it to embed intros and extros at runtime when playing m3u8's through Azure).

When (if) I find a solution that works I'll post the code here.
0 Kudos
TheEndless
Channel Surfer

Re: StreamStickyHttpRedirects for url redirect

"sjb64" wrote:
Am getting nowhere with this too fast.

Doing the head request recommended by TheEndless and using the response as the URL, or even reading the contents of that response and saving it to tmp, then playing the source through server code in brightscript where the roku itself feeds the top level m3u8 doesn't want to work (this code is tested and works normally, we use it to embed intros and extros at runtime when playing m3u8's through Azure).

When (if) I find a solution that works I'll post the code here.

The streams may be using cookies for authentication. If that's the case, you'll need to read the "Set-Cookie" headers from the stream request (same process as getting the Location header value), and explicitly add the "Cookie" header to the roVideoScreen. The roVideoScreen doesn't support cookies natively, even if you call the EnableCookies() method of its ifHttpAgent interface.
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
0 Kudos
sjb64
Roku Guru

Re: StreamStickyHttpRedirects for url redirect

That was a big part of what it was, the getcookies didn't seem to want to return all the cookies I needed, so parsing the cookies off a getrequestheadersarray call then manually placing them back using addheader worked. Turns out this is all an Akamai issue (Vimeos backend), not a Vimeo issue, which caused the primary domain to change, so the needed cookies didn't automatically follow the chain.

The steps I had to do were:


  • retrieve the main url (the permanent one Vimeo supplies to PRO accounts)

  • pull the URL from the location tag in the headers, retrieve that URL, and save the cookies (using
    getrequestheadersarray since there are multiple Set-Cookie headers)

  • pull each URLs for the various streams from that response, using the cookies from above (addheader), parse them and create the M3U8 files on tmp with my intros and extros (and potentially ads) using the VAST plug in and discontinuity tags

  • create the master M3U8, also on tmp, offering the various resolutions and bitrates

  • add those cookies, again using addheader, to the rovideoscreen player

  • set up a socket listener on rovideoscreen that supplies the main and individual M3U8 files off tmp


So far this works, I'm still cleaning it up, but had to make sure to set enablecookies on the associated rotransferurl and rovideoscreen calls, and set the full-adaptive tag.

Thanks for the heads up on cookies, it put me on the right path, and if anything changes while I do my cleaning up of the code, I'll update this comment.
0 Kudos
kgoodwin
Visitor

Re: StreamStickyHttpRedirects for url redirect

I am having the opposite problem as above.  For my use case the behavior described above would have been the correct behavior, but I am seeing instead the opposite.  My scenario:

Roku makes manifest request (this is set as the content's URL.  StreamStickyHttpRedirects is set to [false].

GET http://server1/contents/1/master.m3u8 -> 302 Location: http://server2/contents/1/master.m3u8
GET http://server2/contents/1/master.m3u8 -> 200 Body
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=826103,RESOLUTION=858x480,CODECS="avc1.4d401e,mp4a.40.2"
index-f1-v1-a1.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1346519,RESOLUTION=1280x720,CODECS="avc1.4d401f,mp4a.40.2"
index-f2-v1-a1.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2202041,RESOLUTION=1920x1080,CODECS="avc1.4d4028,mp4a.40.2"
index-f3-v1-a1.m3u8



Roku makes request for bitrate-level index directly to redirected server rather than back to the original server as I would have expected given my stick redirects setting of false:

GET http://server2/contents/1/index-f1-v1-a1.m3u8

In this case server1 acts as a router, and each request needs to go there and be redirected.  Is there a way to accomplish this behavior short of using absolute URLs including the server in the m3u8 file?
0 Kudos