Forum Discussion

merthin's avatar
merthin
Visitor
11 years ago

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