"NewManLiving" wrote:
I have experienced the same thing. For one thing, the isStatusMessage() returns more than just your run-of-the-mill
"startup progress", "start of play", "end of stream", "playback stopped". If you want some very useful information on failures just put an else at the bottom of all the documented GetMessages.
For example, if you send the name of a video which does not exist. You will get the correct HTTP error response of not found in the isStatusMessage "not documented but but does return something in GetMessage " event (as I have come to call it )
But in the isRequestFailed event you get something like format unsupported which is totally unrelated. You will find that some things are duplicated between the
two "systems" isStatusMessage and "all the other messages" as if someone could not decide which method to use or their is some type of transition going on from one format to the other and they just simlply forgot about it. What worked for me was trying to force every perceivable message and every error condition and then seeing what response I get from using all the messages plus the "other" or another way to put it : else if, else if "ELSE ... statement. As I said, The ELSE tells you some useful information.
Right. I guess I wasn't being clear.
I already do what you suggest above - it's why I posted in the first place:
In an if/else if/else block, I test all documented is*() function calls that all the roVideoPlayer related events support as documented in the SDK docs (in this case, the mystery ones I list in the first post are have a type(event) return value of "roVideoPlayerEvent"), and have a final else that catches instances that don't have a corresponding is*() function call.
For instances that hit the final else block (like the ones I'm asking about), I print the values of event.GetMessage(), event.GetInfo(), event.GetData(), event.GetIndex() and event.GetType() to the debug console. In the 3 type codes mentioned (33,10, and 0), GetMessage() comes back empty, and GetInfo() returns invalid - so there is no textual information to use to figure out what the event subtypes are.
I believe that the type codes combined with the fact they're roVideoPlayerEvents should be enough for the Roku support folks to track these mystery events down.
"NewManLiving" wrote:
With that and the roSystemLog component I think I built a pretty rugged videoplayer. But it takes time. You need to force just about everything to happen. And you must absolutely force IsUnderRun
to handle that properly. Just load a bunch of Netflix, hulu, movies, on your phone, laptop, pc, ipad, what-have-you and you will get plenty of anomalies to work over
Hmmmm.... Good idea - use of roSystemLog might help narrow things down. As I mentioned earlier, at least 2 of the 3 mystery events appear to be correlated to loading/rebuffering. I may give that a try and see if the mystery events correlate to log entries with additional info.
Nevertheless, it appears there are 3 undocumented roVideoPlayerEvent subtypes ( or at least 3 without corresponding documented is*() functions ), and that should be corrected in the SDK docs.
Cheers
