Developers

[axiomy]

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?

[RokuMarkn]

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

[axiomy]

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?

[TheEndless]

"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.

[lmarder]

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!

[sjb64]

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.

[TheEndless]

"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.

[sjb64]

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.

[kgoodwin]

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?