Roku Developer Program

[migmigmig]

When trying to play a video url that redirects via code 307, the Roku box gives me unhappy errors:

ButtonPressed
showHomeScreen | msg = HTTP status 307 | index = 0
Video status: 0 0
showHomeScreen | msg = There was an error in the HTTP response. This could mean that malformed HTTP headers or an HTTP error code was returned. | index = -1
Video request failure: -1 0
showHomeScreen | msg = | index = 0
Screen closed

Whereas if I play a video url that redirects via code 302, it plays fine.

I assume this is a bug report? How would I go about making one of those officially?

mig

[migmigmig]

So I tried to see if I could detect the redirect sent, using the HTTP Async code example in the video player:

Function http_get_to_string_with_retry() as String
    timeout%         = 1500
    num_retries%     = 5

    str = ""
    while num_retries% > 0
'        print "httpget try " + itostr(num_retries%)
        if (m.Http.AsyncGetToString())
            event = wait(timeout%, m.Http.GetPort())
            if type(event) = "roUrlEvent"
                print event.GetResponseCode(); " ";
                print event.GetFailureReason()
                headers = event.GetResponseHeaders()
                printAA( headers )
                str = event.GetString()
                exit while        
            elseif event = invalid
                print "Invalid Event ";
                m.Http.AsyncCancel()
                REM reset the connection on timeouts
                m.Http = CreateURLTransferObject(m.Http.GetUrl())
                timeout% = 2 * timeout%
            else
                print "roUrlTransfer::AsyncGetToString(): unknown event"
            endif
        endif

        num_retries% = num_retries% - 1
        print "HTTP RETRY: " + itostr( num_retries% )
    end while
    
    return str
End Function

Unfortunately, for my Code307 url, this trick always returns an invalid event rather than an event with an error code (even when I make the timeout silly like 15s). So I can't even detect the 307 return and manually pull the redirected url. Grr, grr.

mig

[TheEndless]

I doubt it will make a difference, but have you tried a HEAD request? Per the HTTP spec, it should behave slightly differently than a GET (for backwards compatibility with 1.0 clients), so you might get different results.

The error without headers or content on non-successful requests (400, 401, 404, 500, etc) has been brought up before, and I thought Roku had acknowledged it as something they were going to fix, but it doesn't look like it's made it into 3.0 yet.

[migmigmig]

Thanks, looks like I can manually navigate the redirect via the Head call.

Function ResolveRedirect(str As String) As String
    http = CreateObject("roUrlTransfer")
    http.SetUrl( str )
    event = http.Head()
    headers = event.GetResponseHeaders()
    redirect = headers.location
    if ( redirect <> invalid AND redirect <> str )
      print "Old url: " str
      print "Redirect url: " redirect
      str = redirect                
    endif
    return str
End Function

[migmigmig]

This is still a bug for the Roku team, however, in terms of video url handling.

If a video url goes through a 302 redirect the box will resolve it correctly. If it goes through a 307 it will not resolve correctly and give an error that closes the screen. So now I have to *always* manually check for whether or not the url is redirected.

One thing I noticed was that I couldn't do the redirect "late" -- if I tried to resolve the redirect in the error handler, I couldn't prevent the box from closing the screen. It seems like the video screen visibly closes before you actually get the error, so all you can do is reopen the video window, which causes a visible glitch as it momentarily goes back to the details screen.

[TheEndless]

"migmigmig" wrote:
One thing I noticed was that I couldn't do the redirect "late" -- if I tried to resolve the redirect in the error handler, I couldn't prevent the box from closing the screen. It seems like the video screen visibly closes before you actually get the error, so all you can do is reopen the video window, which causes a visible glitch as it momentarily goes back to the details screen.

For what it's worth, I always put up a black image canvas before displaying the video screen, just to avoid flash backs like that. I've also found that 302 redirects lose any custom headers that you set via the ifHttpAgent interface, so I always do a HEAD check for 302s prior to setting the content of the video screen. They may have fixed that bug, but I haven't tested again since I implemented my workaround.

[RokuKevin]

migmigmig,

If you have a stream that uses a 307 redirect, please PM the link to me. I'll take a look at it.

Thanks,

--Kevin

[smlsr]

Kevin can you also look at the problem with most 30x results where if received you LOSE all headers (cookies, etc) and subsequent requests.

This breaks most redirects.

Shawn

[liran]

I had this bug too, trying to play a 307 redirect movie. I solved it manually, but it is not the wanted thing to do.

[Putois]

As for my Code307 url, this trick always returns an invalid event rather than an event with an error code (even when I make the timeout silly like 15s). So I can't even detect the 307 return and manually pull the redirected url. Grr, grr. buy cialis now