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: 
tifroz
Streaming Star

roVideoPlayer.SetContentList() bug in firmware 7.5.0?

My app lets users update their playlist during playback, changing the order etc...with every change in the playlist, the app executes something like [size=85]roVideoPlayer.SetContentList([thePlayListAsDefinedByTheUser])[/size]

Since firmware 7.5.0 this no longer works correctly: if playback is already in progress, playback will be interrupted and the user is now just staring at a blank screen.

To illustrate, in pseudo code:

roVideoPlayer.SetContentList([videoMedatadata1]) ' ok this works, video1 now playing
'....a little later, after the user takes action
roVideoPlayer.SetContentList([videoMedatadata1, videoMedatadata2 ]) ' Expected: video1 should keep playing (and video2 should start playing when video1 ends). Observed: video1 stops, the screen turns black




I only have a 7.5.0 device to experiment with at the moment, but I am pretty sure that the very same logic was working as expected with 7.2.0 - is anyone else experiencing the same? Any workaround?

(I sent an email with the same info to developer at roku dat com - but I was told on a different thread that they aren't terribly responsive so trying my luck here)
0 Kudos
3 REPLIES 3
EnTerr
Roku Guru

Re: roVideoPlayer.SetContentList() bug in firmware 7.5.0?

I wouldn't call this a bug - rather a "deficient design".

Out of curiosity, what happens if you mutate the list you set at first, w/o 2nd SetContentList()? Sounds the behavior will be undefined - i.e. either Roku will crash, or modifying the list will work, or changes will be ignored - or also possible, a random mix of all 🙂

I would advised you keep the lists to yourself and only set 1 clip to play at any one time and when done replace with another - except there is the pre-buffering advantage for the next clip. .AddContent() no good with you?
0 Kudos
tifroz
Streaming Star

Re: roVideoPlayer.SetContentList() bug in firmware 7.5.0?

Thanks for the response!

I guess one person's deficient API design is another's deeply flawed design 🙂 AddContent() only does half the job, because users can also remove a single item from the list. To support this use case and keep the benefit of pre-buffered video I have to maintain a mirror copy of the player's content playlist because the roVideoPlayer does not expose its contentItem list, maintain a mirror copy of the user's playlist & keep the two mirrors coordinated somehow (the as the user performs actions like remove an item, change order, the 2 playlists will get out of sync). Ugh.
0 Kudos
EnTerr
Roku Guru

Re: roVideoPlayer.SetContentList() bug in firmware 7.5.0?

"tifroz" wrote:
... keep the two mirrors coordinated somehow (the as the user performs actions like remove an item, change order, the 2 playlists will get out of sync). Ugh.

These seem to me like a good places to use .SetContentList(). I.e. maybe not on append but delete/re-order being "fair game" to interrupt current play. That shan't be too vexing on the user, i think.

What can i say, seems your use-case - simultaneously play and manipulate list - was never considered.
0 Kudos