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: 
merthin
Visitor

Alternatives to EnableLinkStatusEvent in older devices?

Hi All. I recently was implementing some support to detect when a Roku app lost connectivity
during playback and found that EnableLinkStatusEvent from roDeviceInfo does the work nicely.

Basically, if you look for failed request events from a roVideoPlayer and roDeviceInfoEvent
you can tell when is a good idea to exit an inform the user that there is something
preventing playback to continue.

According to the SDK [1] this was introduced in firmware 4.8.

What could be a way to check for this info in previous firmware?

thanks in advance.

[1] http://sdkdocs.roku.com/display/sdkdoc/ ... nasBoolean
0 Kudos
4 REPLIES 4
TheEndless
Channel Surfer

Re: Alternatives to EnableLinkStatusEvent in older devices?

"merthin" wrote:
Basically, if you look for failed request events from a roVideoPlayer and roDeviceInfoEvent
you can tell when is a good idea to exit an inform the user that there is something
preventing playback to continue.

The isRequestFailed video player event is available on legacy devices. If your code is already using that, it's not clear what more you're looking for. On isRequestFailed, you could try requesting a URL to see if it times out or fails as an indication of network issues.

You could also potentially listen for "http.error" events from the roSystemLog to see if you're getting a lot of timeouts.
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
merthin
Visitor

Re: Alternatives to EnableLinkStatusEvent in older devices?

"TheEndless" wrote:
"merthin" wrote:
Basically, if you look for failed request events from a roVideoPlayer and roDeviceInfoEvent
you can tell when is a good idea to exit an inform the user that there is something
preventing playback to continue.

The isRequestFailed video player event is available on legacy devices. If your code is already using that, it's not clear what more you're looking for. On isRequestFailed, you could try requesting a URL to see if it times out or fails as an indication of network issues.

You could also potentially listen for "http.error" events from the roSystemLog to see if you're getting a lot of timeouts.


I found that isRequestFailed will take a while to be fired after I unplug the device (I can get it faster by seeking forward), checking for
roDeviceInfoEvent gets fire faster in the other hand.

I was thinking on the roSystemLog and get like an heuristic working there but that might be an overkill.

Thanks for the comment. I'm starting to think that the legacy firmware will do better with a native UI instead of a custom one.
0 Kudos
RokuMarkn
Visitor

Re: Alternatives to EnableLinkStatusEvent in older devices?

It's true that you'll detect a network outage faster with the LinkStatusEvent than watching for video player errors, because the video player normally has a number of seconds of buffered data that it can continue to play even if the network is down. However the whole point of the buffer is to avoid playback interruption due to short network outages. In many cases a network error will be corrected before the buffer runs out, and the video will keep playing uninterrupted. But if you deliberately exit when you see a network error, your users will see more interruptions than if you hadn't done it.

--Mark
0 Kudos
merthin
Visitor

Re: Alternatives to EnableLinkStatusEvent in older devices?

Have you ever run in the situation in which isRequestFailed doesn't fire? I'm experiencing this if I wait for at least 1 minute to pull the ethernet cord, after the buffer is empty the messages the roVideoPlayer doesn't fire the event, if I do a seeking forward it does fire though.
0 Kudos